[Dev] NeoScrypt GPU Miner - Public Beta Test
-
Sorry for being imprecise. I am interested in the about last 1000 lines of the log, when the miner aborts on its own after running for 3-5 hours.
Please add those lines to the tickets on github.
-
Well that’s interesting. I’ve been running since yesterday with the -TDP options and it hasn’t frozen once… Still going. I wonder what showing verbose output has to do with it? I’ll keep you updated.
-
Yes I also can’t run the 3.7.6x (only get HW errors) but 3.7.5 is fine.
I’m running windows 7 64bit with AMD HD7800 deries card, can’t find the receiept with the exact moel on it at the moment, what are you running.
-
No still only HW errors for me on 3.7.6 unfortunately
I will be offline for the next 6 days after tonight, so won’t be able to provide any otehr feedback until most likely next weekend
-
Deleted the bin file, but mine is called neoscrypt140909Pitcairngtc256w256l4
Also tried replacing the cl file with my version from when I compiled 3.7.5, but it made no difference
-
Got a set of 7950’s running great at 75Kh/s. Seems that with these GPU’s the lower the -w value the better. GPU 3 is an R9 290 which I’ve only gotten to hash around 78Kh/s so far (-w 24, --thread-concurrency 9856 to prevent failing on launch) Still trying to figure out some optimal settings for it. With all 4 gpu’s running I’m hashing 303Kh/s @ 750 watts.
Here’s what I’m using:
cgminer.exe --neoscrypt -I 13 -w 32
Some screenshots…
http://i.imgur.com/vkDMpht.jpg
-
I was always under the impression that the 280X had comparable performance with the regular 290 - which in the case of your results would be true. As far as power consumption, I’ve had great luck with MSI Afterburner undervolting my 290’s to save power. If you haven’t tried it yet, I highly recommend playing with it to see if you can find a good stable lower voltage. I run my Hynix ram 290’s with -62 for the voltage. It really depends on which type of memory you have in yours. I haven’t had very good luck with Elpida ram and undervolting.
-
Maybe try going back to an older CC version. My 2 rigs have 13.11 and 13.12 respectively - however, I am running Win 7 64-bit, not Windows 8.1. Uninstall 14.4, then run theDDU software in safe mode to make sure you’ve cleaned up all the old crap. Install one of the older CC versions and for troubleshooting purposes you should also reset any OC tweaks you may have configured. You should also take a look at the .bin file that cgminer is creating and look at the “tc” setting. Sometimes having a thread-concurrency setting that is too high or low can cause a ton of HW errors. That’s my best guess anyway.
-
Bring the work back up to 24 now that you’re on 13.12 - I bet you’ll start hashing in the upper 70’s. On an entirely different note, my 290 rig seems to perform exactly the same with lower gpu clock and memory speeds. I’m using MSI Afterburner to underclock and undervolt everything. 947 clock, 1250 mem, and -100 core voltage. Dropped power consumption quite a bit while not affecting the hash rate at all.
-
my amd driver crashes when using -w 24 -I 12…
radeon 7990, driver 13.something, although getting nearly 140 khs
-
Currently getting about 80 kh/s with 3.7.6b, cl file from 3.7.5, *.bin generated with drivers 13.12. And currently running on 14.9
Sapphire 280x with settings
cgminer.exe --neoscrypt -I 13 -w 32 --thread-concurrency 8192
definitely something wrong with the *.cl file from 3.7.6b, no accepted shares unless i lower intensity to 6 but then no performance.
link to my files working on 280x
https://mega.co.nz/#!YFli0LQR!7RjxmzHq1b0Vo0Afr107gNq51rIx1GXSxQOTYfw9_Z8
-
nope… the miner freezes here after a while :(
it starts off well and after five minutes this is what i get
or
what should i do?
-
nope… the miner freezes here after a while :(
it starts off well and after five minutes this is what i get
or
what should i do?
I’ve been having the same problems with freezing. I use the -T option and it keeps running with -w 256 -I 11 --gpu-threads 2. We’ve been discussing options here https://github.com/vehre/neo-gpuminer/issues/3
-
thanks! Looks good for now… Lets see for how long it goes :)
148 khs, WU 10…
EDIT: been working stable for a couple of hours now! I am not entirely sure but I think the p2pool…de is paying extra pxc for finding a block :)
-
-T -w 48 -I 13 works best for me so far… i wish I knew that -T option months ago :D
-
as i see this is only change between them???:
- (get_global_id(0)% CONCURRENT_THREADS)];
- (get_global_id(0)% WORKGROUPSIZE)];
Correct, this is the only change direct change in the kernel. May be I have missed something in the miner corelating with this.
Advice: when you use config-file for running the miner, then please remove the “thread-concurrency” : N from the config-file, if N is smaller then the worksize!
-
(opt_neoscrypt|| opt_scrypt)? 84: sizeof(work->data), true))) {
have no idea how it compares to setting of my miner but i get most stable and fast hash with value -w 84
That line of code has certainly nothing to do with the worksize. The line you have copied there, is taking care about correct communication when solo mining.
-
So just to wrap it up:
-w should be the preferred worksize of the GPU. This is usually a value evenly divideable by 64 and I haven’t found a GPU yet, where this value is beneath 256. That is why cgminer chooses 256 as the default for worksize.
The HW errors occuring with 3.7.6x are most likely due to me failing to ensure, that the thread-concurrency had a value equal to or greater than the worksize. I am currently working on a version where I get rid of the thread-concurrency completely and make use of the worksize only. Thread concurrency is of no use in neoscrypt and makes sense in scrypt only (at least to me).
My current setting on an Nvidia Geforce 218 is:
-w 512
The thread-concurrency is implicitly set to 512 currently. My intensity is set to default (dynamic).
I don’t use configuration files, but only command-line settings. When you use configuration files, make a backup and set worksize back to 256 or 512 depending on what your gpu prefers (removing the line completely makes cgminer select the devices preferred value). Next make sure thread-concurrency is set to worksize or a greater value (again removing the line, make cgminer use a reasonable default value). Setting thread concurrency to a value significantly greater than the worksize wastes memory only.
-
Considering cgminer is dead for GPU mining on newer versions, will this be added to sgminer instead in the future? I think having a common ground like that would help everyone instead of many different forks.
-
Considering cgminer is dead for GPU mining on newer versions, will this be added to sgminer instead in the future? I think having a common ground like that would help everyone instead of many different forks.
Would also love to see NeoScrypt ported to sgminer. Sgminer is much less trouble to setup, less failure.
