[Dev] NeoScrypt GPU Miner - Public Beta Test
-
I don’t understand those pictures on background but hey whatever someone makes happy I m fine with it. I m just afraid that someone will enter my room when I m looking at new sgminer testings :)
Anyway here is someone for you all, I contacted Wolf0 on private but he never replied. Key to better performance(280x) is xintensity 3 or rawintensity 6144.
Have fun and remember:
FTC: 6gtMTcP8QLScgqyQivU4dj3becYVAKVuDc
im getting HW…
what i am missing?
-
im getting HW…
what i am missing?
When people post “Key to better performance(280x) is xintensity 3 or rawintensity 6144.” without the rest of the settings they are using, it’s useless as that won’t work properly without the rest of the settings it’s combined with.
I think that because of the variety of settings people are using to get the max out of their cards, that in order to use a recommendation like that, that you would need to use the entire list of settings that are used to get that speed.
-
When people post “Key to better performance(280x) is xintensity 3 or rawintensity 6144.” without the rest of the settings they are using, it’s useless as that won’t work properly without the rest of the settings it’s combined with.
I think that because of the variety of settings people are using to get the max out of their cards, that in order to use a recommendation like that, that you would need to use the entire list of settings that are used to get that speed.
If people are to post settings please post the entire config, one missing piece gives everyone an incomplete puzzle to solve. I am using either -w 64 or -w 112 with -i 13 and -g2 on everything. My highest 7970 is 305 KH/s, Highest 7950 245 KH/s, Highest 280x 290 KH/s, Highest r9 290 327 KH/s all with newest sgminer and wolf0s mod
-
Understanding how xintensity and rawintensity works is what you need. When you read about them you will see that most of the other settings are not so important because they are set automatically and determined by the values entered in xi and raw.
During all of this time in crypto I noticed one thing. People don’t want to help them in any other way than to prepare everything in *.zip file so they can only click on specific file. Yet they will send you PM to ask you how to unzip that archive.
-
I’m glad you can spend the time to be defensive about your post and still not explain anything. Heck looking at your posts you said you could hit 400KH/s on 280x and had a 310+ KH/s 280x pic with parts colored over to hide info. If you want to be a useful contributing member try harder, if not I can already see the troll in you. None of the core FTC guys ever have anything to hide from the community we put time in our work to help others regardless of where they are in learning cryptos.
-
I said only thing you need is to add --xintensity 3, increase worksize to 256 and you are done, leave other settings alone. And those are not settings for 400Kh/s, those are for 330Kh/s and you can safely lower your freq to reduce power consumption and not lose performance.
-
interesting…
-w 64 with -i 13 and -g2 on my 290’s gives me the same as I was getting with -w 96 with -i 13 and -g2 (299 to 300k)
-w 112 with -i 13 and -g2 on my 290’s gives me 308k, a ~3% increase
Same sg/wolf0 kernel.
Using the 14.7 driver. What driver are you using, and overclocked?
-
interesting…
-w 64 with -i 13 and -g2 on my 290’s gives me the same as I was getting with -w 96 with -i 13 and -g2 (299 to 300k)
-w 112 with -i 13 and -g2 on my 290’s gives me 308k, a ~3% increase
Same sg/wolf0 kernel.
Using the 14.7 driver. What driver are you using, and overclocked?
Yep that’s about what I found. Using 14.6 currently at 1125/1500 for clocks on my r9 290. My 2nd r9 290 cant run at those frequencies max is 1050/1350 ish :( so its been relegated to playing games and mining on the side. The difference may come from types of memory used in the 290s…sapphire really seems to make good GPUs and puts the best memory in them as they are always my fastest.
My fastest 7970 is one of the crazy fast final gen 7970 boost cards sapphire made. It runs stable at 1200/1800 and upwards of 310 KH/s. God I wish I had 30 of these…
-
I said only thing you need is to add --xintensity 3, increase worksize to 256 and you are done, leave other settings alone. And those are not settings for 400Kh/s, those are for 330Kh/s and you can safely lower your freq to reduce power consumption and not lose performance.
With which driver version?
-
With which driver version?
^ UP as I also cant confirm anything this guy used as settings, only HW errors.
-
Yep that’s about what I found. Using 14.6 currently at 1125/1500 for clocks on my r9 290. My 2nd r9 290 cant run at those frequencies max is 1050/1350 ish :( so its been relegated to playing games and mining on the side. The difference may come from types of memory used in the 290s…sapphire really seems to make good GPUs and puts the best memory in them as they are always my fastest.
Yeah, I’ve got 2 of the sapphire tri-x oc 290’s with hynix memory. The problem with mine, is that the fans are crap! One fan already fell off of one GPU and the other GPU the same fan is wobbling and about to fall off. Working through the RMA paperwork now to get them exchanged. In the meantime I’m being a little conservative on the clocking (1100/1450) to keep the temps in the low 80’s and keep the fans from running at 100%. Don’t want to cook them and have them void the warranty on me.
My 2 XFX 290x have elpida, and even clocked higher lag behind the sapphires for hashrate with the same settings. And I still haven’t found settings to make the 290x go any faster than the 290’s.
-
If you have time try walking up worksize by chunks of 8 or 16 starting at 32 and past -w 256 and see if there are any sweet spots. I am also guessing from recent screen shots that the r9 290 and 290x are not done being optimized. The last round covered the 7000 generation and got everyone on more modern clean code.
I remember trying to get my msi 7970 boosts to do more than 680 KH/s on scrypt and I ended up with an odd tc of 21105 but that was the only way to jump them to 740+ KH/s. It took me close to 2 months to find those settings but then I used them to come up with scrypt settings that were 30-40% more efficient with a slight under clock.
-
^ UP as I also cant confirm anything this guy used as settings, only HW errors.
same here, tried every driver version
only HW
getting best results so far using dlls from 14.201.1009( very little effect):
-
xIntensity works by being a shader multiplier for the thread intensity. It gives you finer control over thread intensity than just using regular Intensity settings of I1-20 which use a standard 2^x = thread intensity (where x is the intensity setting). You need to specify the number of shaders your card has in your config file to get this, or raw intensity to work properly because, again, xIntensity is a shader multiplier. I’ve used both xIntensity and rawintensity settings before, and let me just say that they are great features, but don’t expect a miraculous 100% increase in hash rate. Using these settings may or may not give you better hash rate, and to be honest, you will be spending a lot more time tweaking your config if you use xIntensity or rawintensity. rawintensity isn’t a multiplier. It’s a method of directly controlling the thread intensity. So going off of the traditional intensity 2^x = thread intensity (where x is intensity setting), you are simply entering the total number of thread intensity rather than using an equation or a shader multiplier. xIntensity and rawintensity settings also require extensive tweaking of the thread-concurrency as well, so traditional values of TC that worked while using standard intensity I1-20 will most likely require different TC settings for every single adjustment you make to xIntensity or rawintensity. So, HW errors are being caused because majsta hasn’t posted the number of shaders, nor have they posted the TC setting, which again is very important for using xIntensity and rawintensity. Here’s a good place to start for learning about xIntensity in particular:
https://github.com/sgminer-dev/sgminer/commit/7aeae40af22e6108aab8b68a229eea25a639d650
xIntensity Example: r9 280x has 2048 shaders
I15 = 2^15 = 32768 thread intensity
I16 = 2^16 = 65536 thread intensity
xIntensity setting 16 = 16 * 2048 = 32768 thread intensity
xIntensity setting 17 = 17 * 2048 = 34816 thread intensity
So using regular I1-20, there’s a huge, exponential jump in the number of thread intensity even at increment +1 (from I15-I16 it’s about a 2x increase in thread intensity). Using xIntensity, there’s a very small increase in thread intensity from xintensity16 to xintensity17, which again, may or may not give you better, or worse, hash rates.
-
xIntensity works by being a shader multiplier for the thread intensity. It gives you finer control over thread intensity than just using regular Intensity settings of I1-20 which use a standard 2^x = thread intensity (where x is the intensity setting). You need to specify the number of shaders your card has in your config file to get this, or raw intensity to work properly because, again, xIntensity is a shader multiplier. I’ve used both xIntensity and rawintensity settings before, and let me just say that they are great features, but don’t expect a miraculous 100% increase in hash rate. Using these settings may or may not give you better hash rate, and to be honest, you will be spending a lot more time tweaking your config if you use xIntensity or rawintensity. rawintensity isn’t a multiplier. It’s a method of directly controlling the thread intensity. So going off of the traditional intensity 2^x = thread intensity (where x is intensity setting), you are simply entering the total number of thread intensity rather than using an equation or a shader multiplier. xIntensity and rawintensity settings also require extensive tweaking of the thread-concurrency as well, so traditional values of TC that worked while using standard intensity I1-20 will most likely require different TC settings for every single adjustment you make to xIntensity or rawintensity. So, HW errors are being caused because majsta hasn’t posted the number of shaders, nor have they posted the TC setting, which again is very important for using xIntensity and rawintensity. Here’s a good place to start for learning about xIntensity in particular:
https://github.com/sgminer-dev/sgminer/commit/7aeae40af22e6108aab8b68a229eea25a639d650
xIntensity Example: r9 280x has 2048 shaders
I15 = 2^15 = 32768 thread intensity
I16 = 2^16 = 65536 thread intensity
xIntensity setting 16 = 16 * 2048 = 32768 thread intensity
xIntensity setting 17 = 17 * 2048 = 34816 thread intensity
So using regular I1-20, there’s a huge, exponential jump in the number of thread intensity even at increment +1 (from I15-I16 it’s about a 2x increase in thread intensity). Using xIntensity, there’s a very small increase in thread intensity from xintensity16 to xintensity17, which again, may or may not give you better, or worse, hash rates.
no new info for me…
still something i am missing, hw only what ever i do when using xi
xi nor working in any way for neo?? why?
-
no new info for me…
still something i am missing, hw only what ever i do when using xi
xi nor working in any way for neo?? why?
Both xintensity and rawintensity work properly under sgminer5-dev and with neoscrypt. I’ve used xintensity on my 290x with neoscrypt and it works fine, albeit with tiny less hash rate with the settings I used. It’s probably the thread concurrency you need to adjust here, and what magical TC is majsta using? I have no idea :(
Maybe try using thread-concurrency32768 or thread-concurrency16384. I know without entering TC while using xintensity in sgminer will cause HW errors and other weirdness.
-
Well, weird… I rebooted my rig, and the 3% gained from the 112 worksize turned into about a 5% loss in hashrate over the 96 settings, but running the 96 settings was right where it’s been at…
So, I decided to do the old driver swaparoo with all the OCL stuff posted here (and wipe the bin file during swaps)
With 13/96/2 and 1100/1450 the results are 290/290x hashrate:
The 13.9 gets 161k145k
The 14.2 gets 298/294k
The 14.4 gets 255/242k
The 14.6 (rc2) gets 298/294k
The 14.7 (rc1) gets 298/294k
Tried running the worksize 112 again after all that, and it shows the 3% gain again, and lower hashrate on the 290x.
-
PPL like I said there is nothing special in my settings, it works every time on anything I just need to setup --xintensity 3. I m using 14.6 RC2 drivers and all other settings are the same like for any other miner. Here is complete line.
sgminer.exe -k neoscrypt --lookup-gap 2 --xintensity 3 --worksize 256 -g 2 -o xxxx:xxxx -u x -p x --gpu-engine “1000,1000,1000” --thread-concurrency “8192,8192,8192” --gpu-memclock “1500,1500,1500”
One more thing, I published this 5 days ago on my local forum and there is about 20 miners who use this settings for last 5 days or so.
-
Both xintensity and rawintensity work properly under sgminer5-dev and with neoscrypt. I’ve used xintensity on my 290x with neoscrypt and it works fine, albeit with tiny less hash rate with the settings I used. It’s probably the thread concurrency you need to adjust here, and what magical TC is majsta using? I have no idea :(
miner compiled by wolf? 4.2.2 so called 5.xx??
im on win 7 64 bit . xi no use… i have no idea why
-
Well, weird… I rebooted my rig, and the 3% gained from the 112 worksize turned into about a 5% loss in hashrate over the 96 settings, but running the 96 settings was right where it’s been at…
So, I decided to do the old driver swaparoo with all the OCL stuff posted here (and wipe the bin file during swaps)
With 13/96/2 and 1100/1450 the results are 290/290x hashrate:
The 13.9 gets 161k145k
The 14.2 gets 298/294k
The 14.4 gets 255/242k
The 14.6 (rc2) gets 298/294k
The 14.7 (rc1) gets 298/294k
Tried running the worksize 112 again after all that, and it shows the 3% gain again, and lower hashrate on the 290x.
try my dllls from previous post and update your results??
edit: my best test
getting best results so far using dlls from 14.201.1009( very little effect):