2 socal
It is no use to run multiple threads on one gpu. You should better play with -I (intensity) parameter. But note, if you will set intensity to high your gpu driver may crash or go to the p-state with low clocks. So you will need restart you gpu to run normal clocks. Using gpu-z to control current clocks and nvidia inspector to restart you driver is good choice.
|
|
|
I tried changing 320 to 256 in shavite ... no good (( I have manual set intensity in batch files e.g. - I 19.3 tuned once some time ago ... hope it doesn't interfere performance of new builds ...
|
|
|
Try to reduce the launchbound in Shabal from 320 to 256. If you have time revert some of the change sets to find the one that slows down.
There are to many changes for me to test (( Did you mean shavite to change TPB from 320 to 256? (ccminer-windows\x11\cuda_x11_shavite512.cu)
|
|
|
comparing v43 vs. v44 for my gtx750(non-ti) (windows binaries from github) x15: 1966 vs 1976 x13: 2272 vs 2270 x11: 2886 vs 2883 quark: 5700 vs 5660 qubit: 4418 vs 4419 (with drops) lyra: 882 vs 881
So, only x15 gain for me
|
|
|
1.5.43 - really beautiful! Great work, SP! You should better stay in Thai
|
|
|
You were right! I missed it! Now my own build is doing well, 4378khs in Qubit
|
|
|
damn, I can't understand why your R40 binary is 20khs faster in Qubit then my custom R39 based built. Your R40 didn't work on GTX750 1gb on default (out of memory error) so I use it with "-i 19.3" option.
And it is 20khs faster then both your own built R39 binary and my custom build. As I see on GitHub there were no changes in Qubit between R39 and R40 except for different launch config that is overridden by -i option.
|
|
|
Hello yaamp, all coins in all protocols looks like immature for last two hours. What happends? Jiri
again (((
|
|
|
Commit "Bether default throughput qubit(+30khash 750ti)" gives error
"Cuda error in func 'x11_simd512_cpu_init' at line 634 : out of memory."
on my poor gtx750 non-ti with only 1gb memory
Will try to lower "int intensity = 256 * 256 * 14;"
I tried 256 * 256 * 12 - it crashes driver when monitor attached and works but slow without monitor. 256 * 256 * 10 gives me 2-4 khs benefit compares to default 1U << 19 (256 * 256 * 8) from previous version
So I went to try -i command line parameter and figured out that for my card -i 19.3 is max for qubit (681472 cuda threads)
|
|
|
For 1ghs in lyra2 coinwarz shows now $189.84. I put 3 ghs in calculator yesterday Ok, with such hashrate it is not so profitable. Moreover, if you switch extra 1ghs to the net the diff will rise and profit will go to zero as vertcoin has very small money volume. Total vertcoin hashrate is only about 2.5ghs
|
|
|
It is not profitable as u said. I'm tried it. I gettin 1660 kh/s with 1 machine. 1660*532.480 kh/s = $12,418.66. Damn in yesterday it was 126$. WTF with that coinwarz?
I didn't understand your math What is 532.480 in your formula? 1660 for modern 32-core machine is not good. Maybe it is memory bandwidth bounded or not optimal miner.
|
|
|
My old 2 core cpu does 160 khashes on lyra2re (vertcoin) If your's is 32*640 times faster you will get more then $500 based on coinwarz calculator. But i think you will easily ruin it too Thank you for your post, vertcoin renewed? I mined vert's in july of 2014. But there was n-scrypt algo. Tomorrow I will try and send you PM with results, If it really makes 500$ per day I will give you 20 vps'es next day + 20 vps'es in monday-saturday. For ~6 hrs each day. I have no idea what cpus you have and what rates you'll get with your miner. The best cpu-miner i found for lyra is cpuminer-multi 1.0.9 by Tanguy Pruvot (tpruvot@github) - windows mingw64 build ... but maybe there is faster thing somewhere
|
|
|
My old 2 core cpu does 160 khashes on lyra2re (vertcoin) If your's is 32*640 times faster you will get more then $500 based on coinwarz calculator. But i think you will easily ruin it too
|
|
|
The cuda_x11_aes.cu is excluded from the project file, so if you change it it will not build unless you save echo or shavite or take a full build. To messure you can use Fresh, because this has fewer chained hashing algos.
I checked a VS build log after rollback. cuda_x11_aes.cu was #included in 2 other .cu files that were rebuilt by VS. So I think I made it right.
|
|
|
Trying to add support for legacy cards is going to be a waste of time,
It is, without any 'if' ...
|
|
|
For both R38 and R39, 750 Ti get error "Cuda error in func 'x11_xim512_cpu_init' at line 634 : out of memory." when running x11 in HamsterPool. No such error with x11 in YAAMP.
hmmm, 750 without Ti works fine on hamster. Maybe you should try to play with --diff parameter.
|
|
|
new build 39 GTX 750 1480core/1567mem testing with --cpu-priority 5 on yaamp: rates in khs qubit: ~4350 quark: ~5650 fresh: ~3450 x11: 2859 x13: 2248 x14: 2214 x15: 1937 lyra2: 862 sha256 : 193950 (didn't wait for yay's ) keccak on NiceHash: 150mhs
|
|
|
|