Topic: [ANN] ccminer 2.3 - opensource - GPL (tpruvot) - page 104. (Read 500193 times)

Ah it happens good you got it to work !

You're doing a million things, CCMiner for 1 and YiiMP are both awesome, just wanted to say thank you.

Sorry to laugh but I do stuff like that all the time.

Once I forgot to add the -a to the bat file from copy and pasting and took me a minute (well hour) to figure out why the miner started but no hashing.

It wasn't a dns issue it was a stupidity issue. I cut and pasted the url and picked up a trailing slash.
I just kept pasting the same erroneous url over and over again.

what dns servers are you using ?

i use it like this stratum+tcp://mine.gpu4u.eu:xxxx and it work nicely.

You're saying use mine.gpu4u.eu. I say it doesn't work, not even now when yiimp is back up.

What am I missing?

i guess you didnt read what i just explained... well the only good news is the DNS update is now faster (10/15mn)... but still require a manual edit of the zone

8.8.8.8 is a google public dns server

well, im tired with ISP problems, all the day wasted on papers and customer service / tech problems

Annoying, maybe, but weird is what I had.

Nothing working for me on yiimp yet. mine.gpu4u.eu has never worked for me.

indeed it can.. on "heavy" algos like whirlpool

guys... i cut yiimp for a few minutes... remember to use mine.gpu4u.eu for a faster DNS update... (that could involve a double down time for the default firmware auto upgrade)

damn, ive only weird problems to resolve this week... sigh

I thoink there are two dimensions to this. You are mentioning boradcasting the precalc to multiple threads. That makes a big
difference on GPU due to it having 1000s of threads. On the CPU with only a few threads that part of it doesn't help much.
The big gain on CPU is not recalculating with the same input over and over until new work arives.

I'll look over some GPU code for clues.

It makes a significant difference on CPU as well. Whirlpool +15% by precalculating the first 64 bits, even when every thread
calculates its own.

Usually it's not worth doing on cpu.
It's very useful, and valid for most algos, on gpu miners, as part of the hash is precalculated on cpu, then sent to thousands of gpu threads.
How much speedup you can get (if any), depends on how many redundant gpu instructions you can save.

This is an open question to all devs.

What's the deal with midstate? Some hash functions alway hash some bits to the same constant value and
don't have to be repeated each time the're called.

I've seen it mostly on blake functions but it also works on whirlpool (I'm working on it).

I've tried using the technique on some other algos that use blake but it hasn't worked.

I'd like to propagate the technique to all applicable algos but don't know which ones are applicable.
Other than dumping debug data to analyze the hash results is there an easier way to identify algos
that could benefit?

Those are interesting ideas indeed. My main problem atm is "fast" algo switching, since you don't have a way to kill/shutdown "nicely" the miner through API since it only allow RO stuff, you can't "remote control" the miner from it, and often you have to reboot the rig for some algo's to work properly (i have especially this issue with lbry) making the switch quite lenghty even with a very fast OS booting. Having something that would switch algos on the go would be incredible for sure. That's an issue i encountered especially with ccminer, it doesn't like to be killed, sometimes it make your GPU's not working anymore or degraded, only a reboot make it good again, and that make monitoring & stuff pretty complex. I dabble quite a bit in scripting, but im in no way a dev, so any "easier" toolbox is always welcomed

As for the failover, what about a variant of ccminer that support "config" files, kinda like sg-miner, with the ability to host multiple configs entry for the specified algo, this way when a algo-config fail (pool not connecting or something) it could switch to the next configuration for the specified algo, that would cancel out any issue you would have with any forked version that support one or a few algo.

Such system could also expand to something like controlled API config switch or config section switch, and so on.

I dunno how doable this could be, just giving out ideas.


Oh i couldn't agree more, their network is very good in both hardware and software, but their box are really PoS, same for user/customer interface, if that was improved it could be gold.

My opinion on the matter is the miner is not the best place to implement failover. Say it gets implemented
for ccminer. Who's fork? What about specialist vesrions that only support one algo? How to coordinate
multiple miners?

An external script is a better choice.
The failover manager needs access to the pools APIs, perfect for PHP. Also a miner impplemented manager would
have to be reimplemented for every miner, not all use the same minerd core. A miner inegrated manager would
also be limited to managing the algos it supports. It's better if the manager can support multiple miner programs
and more algos.

One place an integrated manager might be better is with pool supported failover where the same port and stratum
connection can be maintained to reduce the downtime of sutting down the running miner, starting the new miner
and establishing a new stratim connection. But the difference is only a matter of a couple of seconds.

With the manager monitoring pool health (assuming a working API means the stratums are running) the failover and
recovery cann be nearly as responsiveness as a built in manager.

One miner feature that would help is the ability to mantain multiple stratum connections, with only one actuvely mining
at a time. An external manager could use the miner API to signal the manager wihich algo to mine at any given time.

but they are very fast to create new ones :p at least one "hotfix" per version

I know ..nvidia takes time to fix a bug.
I had a FERMI GTX480 in linux and Windows there were random segfaults or bluescreens caused by the GPU.

2,8 years later they fixed it in driver - due to a wrong reading of the BIOS/FB the drivers caused wrong register calls :-D

Its not this problem, the card clock was correct, just the value reported by nvml is broken (nvapi/afterburner one was correct at the same time) :

https://devtalk.nvidia.com/default/topic/992477/linux/bug-378-xx-nvml-nvidia-smi-core-clock-is-wrong-on-pascal-devices/

Time is a variable, they generally fix my bug reports 2 years after

the last clocking issue was a driver bug..due to if PASCAL PGU detected the driver was in debug mode.
It's already fixed..and your fix isn't needed at all :-D

well if you ignore this problem, the connection is faster and more reactive than my previous numericable fiber. Like the pascal pstates, the recent hardware can have some issues :p

i didnt even felt a connection slow down while a china botnet (2500 miners) was slowing down the DCR pool... Chyn' Flood

-_- livebox for the win, good luck man... gonna need it....