[ANN] ccminer 2.3 - opensource - GPL (tpruvot)

[Epsylon3]

what is Power8 ? did you try -msse in CFLAGS ?

[joblo]

Power is IBM mainframe architecture.

fatal error: emmintrin.h: No such file or directory.

This is the header file for Intel intrinsics, not likely to exist on Power.
You need to find the Power intrinsics and convert all intrinsic usage
in the miner to Power, just like has to be done with assembly code.

[SlarkBoy]

what is Power8 ? did you try -msse in CFLAGS ?

lscpu

Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                128
On-line CPU(s) list:   0-127
Thread(s) per core:    8
Core(s) per socket:    8
Socket(s):             2
NUMA node(s):          2
Model:                 1.0 (pvr 004c 0100)
Model name:            POWER8NVL (raw), altivec supported
CPU max MHz:           4023.0000
CPU min MHz:           2061.0000
L1d cache:             64K
L1i cache:             32K
L2 cache:              512K
L3 cache:              8192K
NUMA node0 CPU(s):     0-63
NUMA node1 CPU(s):     64-127

Code:

/usr/local/cuda/bin/nvcc -gencode=arch=compute_60,code=\"sm_60,compute_60\" -I/usr/local/cuda/include -I. -O3 -msse -lineno -Xcompiler -Wall  -D_FORCE_INLINES  --ptxas-options="-v" --maxrregcount=128 -o cuda_myriadgroestl.o -c cuda_myriadgroestl.cu
/usr/local/cuda/bin/nvcc -gencode=arch=compute_60,code=\"sm_60,compute_60\" -I/usr/local/cuda/include -I. -O3 -msse -lineno -Xcompiler -Wall  -D_FORCE_INLINES  --ptxas-options="-v" --maxrregcount=128 -o cuda_checkhash.o -c cuda_checkhash.cu
nvcc fatal   : 'sse': expected a number
Makefile:2242: recipe for target 'cuda_groestlcoin.o' failed
make[2]: *** [cuda_groestlcoin.o] Error 1
make[2]: *** Waiting for unfinished jobs....
nvcc fatal   : 'sse': expected a number
Makefile:2242: recipe for target 'cuda_checkhash.o' failed
make[2]: *** [cuda_checkhash.o] Error 1
nvcc fatal   : 'sse': expected a number
Makefile:2242: recipe for target 'cuda_myriadgroestl.o' failed
make[2]: *** [cuda_myriadgroestl.o] Error 1
mv -f .deps/ccminer-crc32.Tpo .deps/ccminer-crc32.Po
mv -f .deps/ccminer-sysinfos.Tpo .deps/ccminer-sysinfos.Po
mv -f .deps/ccminer-groestlcoin.Tpo .deps/ccminer-groestlcoin.Po
mv -f .deps/ccminer-fuguecoin.Tpo .deps/ccminer-fuguecoin.Po
mv -f .deps/ccminer-myriadgroestl.Tpo .deps/ccminer-myriadgroestl.Po
mv -f .deps/ccminer-bench.Tpo .deps/ccminer-bench.Po
mv -f .deps/ccminer-hefty1.Tpo .deps/ccminer-hefty1.Po
mv -f .deps/ccminer-pools.Tpo .deps/ccminer-pools.Po
mv -f .deps/ccminer-stats.Tpo .deps/ccminer-stats.Po
mv -f .deps/ccminer-hashlog.Tpo .deps/ccminer-hashlog.Po
mv -f .deps/ccminer-cuda.Tpo .deps/ccminer-cuda.Po
mv -f .deps/ccminer-bignum.Tpo .deps/ccminer-bignum.Po
mv -f .deps/ccminer-nvml.Tpo .deps/ccminer-nvml.Po
mv -f .deps/ccminer-api.Tpo .deps/ccminer-api.Po
mv -f .deps/ccminer-util.Tpo .deps/ccminer-util.Po
mv -f .deps/ccminer-ccminer.Tpo .deps/ccminer-ccminer.Po
make[2]: Leaving directory '/root/ccminer'
Makefile:1788: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/root/ccminer'
Makefile:582: recipe for target 'all' failed
make: *** [all] Error 2

another error.

Power is IBM mainframe architecture.

fatal error: emmintrin.h: No such file or directory.

This is the header file for Intel intrinsics, not likely to exist on Power.
You need to find the Power intrinsics and convert all intrinsic usage
in the miner to Power, just like has to be done with assembly code.

ooooooooooh my god. i'm quit.

[Epsylon3]

yep sorry, will not be able to help you about that :p

[Al_WaySlate]

First of all > NICE!!!


Second of All > Mac support plz......and a shit ton of it...Can't compile or use as usual...

Hope I can try it one time, in the near ...maybe very distant future,...with cuda 8.0 would be awesome...



Keep up the great work, you certainly are making a lot of peeps happy!!!

[m1n1ngP4d4w4n]

Hello,

Seems that the pool is down this morning, any ETA when it'll be back ?  

edit : NVM seems to be back

[Epsylon3]

Its not, read the last page... Sigh this month will be very long

[m1n1ngP4d4w4n]

Its not, read the last page... Sigh this month will be very long

It's again this static IP issue mentionned in the last page ? i tried the alternative DNS as a fallback in my scripts but both weren't responding at the time. I will add non-yiimp coins as an added fallback then.

[Epsylon3]

look like my domain name (ccminer.org) DNS system was updated and im now able to set the TTL. It may be faster to update the next time...

That will happen again, because i don't have the static IP i should have... and the IPv6 neither. But its a temporary problem for this month... I'm calling them to try to reduce this delay, in the waiting FIFO of the tech service..

But even if they fix it, it will require a last IP change :p

[m1n1ngP4d4w4n]

look like my domain name (ccminer.org) DNS system was updated and im now able to set the TTL. It may be faster to update the next time...

That will happen again, because i don't have the static IP i should have... and the IPv6 neither. But its a temporary problem for this month... I'm calling them to try to reduce this delay, in the waiting FIFO of the tech service..

But even if they fix it, it will require a last IP change :p

Nice to know

Do you think it'll be possible to add failover as a feature of ccminer ?

From my testing the ccminer.org dns still not work, but the minegpu does. I will add it as main one in the meantime

Another matter, i noticed that with the lbry algo, sometimes when i do algo switching it doesn't take in account all my graphic cards, like threads are stuck, when i start the miner it say "starting 6 miners threads", but only 4 cards are hashing, and after a few minutes somtimes the others gpu kick-in, but sometimes they don't. and the weird thing is that when i press "ctrl+c" to cut out the miner, the threads unlock (i see them in the console log), i usually have to reboot the rig for it to work well, and it does that only with lbry. Do you have an idea that could fix this sort of things or maybe it's a bug ? I tried on my side to reset drivers with nvidia inspector, add a monitoring that will ask ccminer how many cards it see, but everything seems to be normal.

Cheers

[Epsylon3]

Ok, the tech asked me to reset the device to the initial config, an option switch seems to have locked the ipv6 settings... I will do that in the afternoon. Will do a tweet...

[m1n1ngP4d4w4n]

Ok, the tech asked me to reset the device to the initial config, an option switch seems to have locked the ipv6 settings... I will do that in the afternoon. Will do a tweet...

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

[Epsylon3]

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

[ioglnx]

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

[Epsylon3]

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

[ioglnx]

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

[Epsylon3]

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

[joblo]

Do you think it'll be possible to add failover as a feature of ccminer ?

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.

[m1n1ngP4d4w4n]

Do you think it'll be possible to add failover as a feature of ccminer ?

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?
<snip>
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.

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.

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

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.

[joblo]

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?