I'm showing that some of the newer builds don't pay respect to pool priority when it comes to rentals.
If you have your rental pool specified as pool priority 0, even if work is served to it, the miner won't flip back up to it. I didn't have this problem using the build from 07-02-2014 (unversioned, it was ystarnaud's personal wrap)
Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 204. (Read 877859 times)
July 07, 2014, 04:39:52 AM
July 06, 2014, 10:37:43 PM
hi,badman74,thanks for your work.
on my 1g memory (or above) 5xxx and 6xxx cards ,the bitblockold algorithm works fine,but 512m cards can't run,it says not enough graphic memorys.
I tried to decrease TC or increase LG,can't work neither.
seems that parameter "--thread-concurrency" and "--lookup-gap" don't play a part in new version sgminer no longer?
Is there any other new sgminer builds that can let that parameter "--thread-concurrency" works again to decrease the memory occupancy in order to let my 512m cards run the x15 algo？
don't know about that but i leave the TC out completly and let the kernel build with what is availableon my 1g memory (or above) 5xxx and 6xxx cards ,the bitblockold algorithm works fine,but 512m cards can't run,it says not enough graphic memorys.
I tried to decrease TC or increase LG,can't work neither.
seems that parameter "--thread-concurrency" and "--lookup-gap" don't play a part in new version sgminer no longer?
Is there any other new sgminer builds that can let that parameter "--thread-concurrency" works again to decrease the memory occupancy in order to let my 512m cards run the x15 algo？
In the practical, place the parameter "--thread-concurrency" into the BAT files , the sgminer can still run,but the "--thread-concurrency" parameter can't take effect actually
according to the filename of the *.bin fies built by the new sgminer, I just find the gpu model、worksize and the hamsi_big number but TC information, not like the previous version..
so ,I guess . could it have the new version sgminer cancelled the TC manual operation surpport?
July 06, 2014, 10:15:54 PM
hi,badman74,thanks for your work.
on my 1g memory (or above) 5xxx and 6xxx cards ,the bitblockold algorithm works fine,but 512m cards can't run,it says not enough graphic memorys.
I tried to decrease TC or increase LG,can't work neither.
seems that parameter "--thread-concurrency" and "--lookup-gap" don't play a part in new version sgminer no longer?
Is there any other new sgminer builds that can let that parameter "--thread-concurrency" works again to decrease the memory occupancy in order to let my 512m cards run the x15 algo？
don't know about that but i leave the TC out completely and let the kernel build with what is availableon my 1g memory (or above) 5xxx and 6xxx cards ,the bitblockold algorithm works fine,but 512m cards can't run,it says not enough graphic memorys.
I tried to decrease TC or increase LG,can't work neither.
seems that parameter "--thread-concurrency" and "--lookup-gap" don't play a part in new version sgminer no longer?
Is there any other new sgminer builds that can let that parameter "--thread-concurrency" works again to decrease the memory occupancy in order to let my 512m cards run the x15 algo？
also try lowering work size
July 06, 2014, 09:58:50 PM
dark8011: lookup-gap is only used with Scrypt. I think thread-concurrency also is only used with Scrypt, but in any case it is not used to calculate buffer size for non-Scrypt. I think your cards unfortunately just do not have enough VRAM for these algorithms. The only thing you can try is set gpu-threads to 1 if you don't already have that. Other than that I don't think there's much you can do.
For developers: Perhaps X11/X13... buffer size can be lowered? I remember that some miners had a formula to calculate it, while we use hardcoded values in sgminer 5.0.
For developers: Perhaps X11/X13... buffer size can be lowered? I remember that some miners had a formula to calculate it, while we use hardcoded values in sgminer 5.0.
July 06, 2014, 08:17:37 PM
hi,badman74,thanks for your work.
on my 1g memory (or above) 5xxx and 6xxx cards ,the bitblockold algorithm works fine,but 512m cards can't run,it says not enough graphic memorys.
I tried to decrease TC or increase LG,can't work neither.
seems that parameter "--thread-concurrency" and "--lookup-gap" don't play a part in new version sgminer no longer?
Is there any other new sgminer builds that can let that parameter "--thread-concurrency" works again to decrease the memory occupancy in order to let my 512m cards run the x15 algo？
on my 1g memory (or above) 5xxx and 6xxx cards ,the bitblockold algorithm works fine,but 512m cards can't run,it says not enough graphic memorys.
I tried to decrease TC or increase LG,can't work neither.
seems that parameter "--thread-concurrency" and "--lookup-gap" don't play a part in new version sgminer no longer?
Is there any other new sgminer builds that can let that parameter "--thread-concurrency" works again to decrease the memory occupancy in order to let my 512m cards run the x15 algo？
July 06, 2014, 08:10:14 PM
I'm testing that 7-6-2014 build and going to let my pools flip the algos normally as if I wasn't monitoring it. I'll report back.
So far, algo flips between x11 and x13 ok.
So far, algo flips between x11 and x13 ok.
Code:
[7/6/2014 6:53:24 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4337 to stratum+tcp://stratum.nicehash.com:4336
[7/6/2014 6:55:04 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4336 to stratum+tcp://stratum.nicehash.com:4337
[7/6/2014 7:40:36 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4337 to stratum+tcp://stratum.nicehash.com:4336
[7/6/2014 7:43:47 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4336 to stratum+tcp://stratum.nicehash.com:4337
[7/6/2014 7:54:20 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4337 to stratum+tcp://stratum.nicehash.com:4336
[7/6/2014 7:56:10 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4336 to stratum+tcp://stratum.nicehash.com:4337
[7/6/2014 8:06:23 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4337 to stratum+tcp://stratum.nicehash.com:4336
[7/6/2014 8:08:33 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4336 to stratum+tcp://stratum.nicehash.com:4337
Code:
[7/6/2014 6:41:56 PM] Total hashrate is below X13 minimum threshold 25% (2.398 Mh/s); but am inside the miner's startup grace period (Elapsed:16 sec;GracePeriod:3 min) so did not attempt to restart yet, but I will if the condition exists after the grace period expires.
[7/6/2014 6:53:00 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4337 to stratum+tcp://stratum.nicehash.com:4336
[7/6/2014 6:56:31 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4336 to stratum+tcp://stratum.nicehash.com:4337
[7/6/2014 8:06:09 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4337 to stratum+tcp://stratum.nicehash.com:4336
[7/6/2014 8:07:39 PM] Pool changed from stratum+tcp://stratum.nicehash.com:4336 to stratum+tcp://stratum.nicehash.com:4337
July 06, 2014, 07:06:24 PM
I can't get it to work at all on X11 and X13:
AMD 14.6
HD5XXX
Older miner works fine on both algos mentioned above.
the newest build only seems to work for me if there is only 1 algo, and no profiles in the configAMD 14.6
HD5XXX
Older miner works fine on both algos mentioned above.
i believe it is being looked into
the version in my sig should work, it is the last build i did before it started messing up on me
July 06, 2014, 06:34:52 PM
I can't get it to work at all on X11 and X13:
AMD 14.6
HD5XXX
Older miner works fine on both algos mentioned above.
AMD 14.6
HD5XXX
Older miner works fine on both algos mentioned above.
July 06, 2014, 02:54:42 PM
@badman74, mine's hashing just fine on this 4.2.2-265-g363f you just dropped off for us the morning of the 6th. Tested only x11 right now, not necessarily a day full of algo flips, but it gets right through building bins and goes to pools in order now. I'm on 14.6rc2 drivers as well, and I'm using old-style .conf's (no include "profiles.conf," I specify algo-settings per pool for CGWatcher, as posted a page or two ago in the thread).
hmm i finally got it to work with a single pool in the conf and no profiles but if i add pools with a different algo or ad profiles it just closes on memust be something about my computer i guess...
check the issues to see what it is doing to me
https://github.com/sgminer-dev/sgminer/issues/327
I been mining on it for 4 hours now and not one issue.
July 06, 2014, 01:19:40 PM
@badman74, mine's hashing just fine on this 4.2.2-265-g363f you just dropped off for us the morning of the 6th. Tested only x11 right now, not necessarily a day full of algo flips, but it gets right through building bins and goes to pools in order now. I'm on 14.6rc2 drivers as well, and I'm using old-style .conf's (no include "profiles.conf," I specify algo-settings per pool for CGWatcher, as posted a page or two ago in the thread).
hmm i finally got it to work with a single pool in the conf and no profiles but if i add pools with a different algo or ad profiles it just closes on memust be something about my computer i guess...
check the issues to see what it is doing to me
https://github.com/sgminer-dev/sgminer/issues/327
July 06, 2014, 11:19:21 AM
July 06, 2014, 10:56:50 AM
@badman74, mine's hashing just fine on this 4.2.2-265-g363f you just dropped off for us the morning of the 6th. Tested only x11 right now, not necessarily a day full of algo flips, but it gets right through building bins and goes to pools in order now. I'm on 14.6rc2 drivers as well, and I'm using old-style .conf's (no include "profiles.conf," I specify algo-settings per pool for CGWatcher, as posted a page or two ago in the thread).
hmm i finally got it to work with a single pool in the conf and no profiles but if i add pools with a different algo or ad profiles it just closes on memust be something about my computer i guess...
check the issues to see what it is doing to me
https://github.com/sgminer-dev/sgminer/issues/327
July 06, 2014, 10:47:59 AM
@badman74, mine's hashing just fine on this 4.2.2-265-g363f you just dropped off for us the morning of the 6th. Tested only x11 right now, not necessarily a day full of algo flips, but it gets right through building bins and goes to pools in order now. I'm on 14.6rc2 drivers as well, and I'm using old-style .conf's (no include "profiles.conf," I specify algo-settings per pool for CGWatcher, as posted a page or two ago in the thread).
July 06, 2014, 10:18:02 AM
@badman74, do you find your Windows binaries build from 7-4-2014 to cross hash on the wrong pool?
It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
the ones i built on 7/14 do not work for me at all, so i had to roll the binaries back to 7/3.It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
but 7/3 version has been working perfectly for me.
i don't know if it is my computer or my build
i would appreciate it if someone would test and see if this works for them
https://mega.co.nz/#!SBo1RJbR!rA0EvI1bHpxdToHxCN8YDZRwH_-dovp0oal29dAcuEw
Its working at least on my end...the only thing I moved from my original to yours is my .bat and .conf.... and then I always do the AMD files that I do by default.
Edit.... running x11.... so the dark algo on 2x 270x's
July 06, 2014, 10:17:04 AM
guys, how does these Xnn switching algs compare to scrypt switching in a sense of BTC/day/MH, I mean with GPU having 1 MH scrypt, it is about 0.0007 BTC / day, what would be with Xnn algs?
July 06, 2014, 09:18:52 AM
@badman74, do you find your Windows binaries build from 7-4-2014 to cross hash on the wrong pool?
It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
the ones i built on 7/14 do not work for me at all, so i had to roll the binaries back to 7/3.It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
but 7/3 version has been working perfectly for me.
i don't know if it is my computer or my build
i would appreciate it if someone would test and see if this works for them
https://mega.co.nz/#!SBo1RJbR!rA0EvI1bHpxdToHxCN8YDZRwH_-dovp0oal29dAcuEw
July 06, 2014, 08:49:45 AM
That was the ticket, Badman! Thank you so much.
Seeing some pretty large gains now that I have the new build up and running. Went from 1.4MH/s per card to just over 2MH/s per card! 1.2 MH/s improvement overall! I am very stoked
. Now I'm wondering if there may still be room for improvement 
Anyone else running R9 270s out there? And if so what kind of rates are you getting?
Seeing some pretty large gains now that I have the new build up and running. Went from 1.4MH/s per card to just over 2MH/s per card! 1.2 MH/s improvement overall! I am very stoked
. Now I'm wondering if there may still be room for improvement Anyone else running R9 270s out there? And if so what kind of rates are you getting?
4 x R9 270X's here getting:
Scrypt - 1.7 MH/s
nScrypt - 800 kH/s
x11 - 10.2 mH/s
x13 - 7.5 mH/s
x15 - 6.4 mH/s
nist5 - 30.8 mH/s
Keccak - 900 mH/s
Divide numbers above by 4 to get individual card speeds
what are you getting ?
Getting 2mH/s per card so 4mH/s in total. By your numbers it sounds like I may be able to improve a few hundred kH/s. What TC / Intensity settings are you using? Looks like it's time to tweak some more
{
"name" : "x11",
"algorithm" : "darkcoin-mod",
"xintensity" : "300",
"gpu-threads" : "1",
"gpu-powertune" : "20",
"worksize": "256",
"gpu-engine": "1160,1160,1160,1160",
"gpu-memclock": "1250,1250,1250,1250",
"thread-concurrency" : "8193"
}
July 06, 2014, 08:42:32 AM
@badman74, do you find your Windows binaries build from 7-4-2014 to cross hash on the wrong pool?
It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
the ones i built on 7/14 do not work for me at all, so i had to roll the binaries back to 7/3.It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
but 7/3 version has been working perfectly for me.
July 06, 2014, 05:11:58 AM
July 06, 2014, 04:36:09 AM
@badman74, do you find your Windows binaries build from 7-4-2014 to cross hash on the wrong pool?
It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
It's hit or miss whether it picks the right pool, and then if it hashes with a different algo, it produces HW errors I haven't seen since an incorrectly configured scrypt-jane miner.
I tested the jansson builds for troky prior to final push to repo too, never saw this shit going on.
Jump to: