Come on people, please help me with this. How can I achieve 3.6 mh on x11 with 270x and what version of sgminer, driver, card config, etc.
I currently managed to get 2.9 and 4.3 on 270x and 280x
Thank you.
Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 152. (Read 877859 times)
October 09, 2014, 06:53:36 AM
October 09, 2014, 06:12:43 AM
Not impossible - if you know C, call CreateProcess() with CREATE_NO_WINDOW flag.
Just call WinMain.No, he wants to launch SG with no window.
October 09, 2014, 01:37:33 AM
I have no idea why, but it works fine. Thanks
weird..
Maybe cause of "True"?
Code:
CreateObject("Wscript.Shell").Run "F:\miner.bat", 0, True
Quote
CreateObject("Wscript.Shell").Run """" & WScript.Arguments(0) & """", 0, False
Quote
bWaitOnReturn
Optional. Boolean value indicating whether the script should wait for the program to finish executing before continuing to the next statement in your script. If set to true, script execution halts until the program finishes, and Run returns any error code returned by the program. If set to false (the default), the Run method returns immediately after starting the program, automatically returning 0 (not to be interpreted as an error code).
http://msdn.microsoft.com/en-us/library/d5fk67ky(v=vs.84).aspx Optional. Boolean value indicating whether the script should wait for the program to finish executing before continuing to the next statement in your script. If set to true, script execution halts until the program finishes, and Run returns any error code returned by the program. If set to false (the default), the Run method returns immediately after starting the program, automatically returning 0 (not to be interpreted as an error code).
October 08, 2014, 08:37:23 PM
Can someone explain why sgminer automatically forces a terminal window to be open?
I really hate having the terminal open while I'm using the pc, so I was using the following vbs script to hide cgminer:
It works perfectly fine with cgminer and runs the .bat file without issue, and without a CMD window, but whenever I try using it with sgminer it will force open a CMD window. The above vbs script will open the sgminer bat file without issue, and sgminer will run without issue, but it will sit there in a CMD window.
Any way to get this to work similar to cgminer, without a CMD window?
I really hate having the terminal open while I'm using the pc, so I was using the following vbs script to hide cgminer:
Code:
CreateObject("Wscript.Shell").Run "F:\miner.bat", 0, True
It works perfectly fine with cgminer and runs the .bat file without issue, and without a CMD window, but whenever I try using it with sgminer it will force open a CMD window. The above vbs script will open the sgminer bat file without issue, and sgminer will run without issue, but it will sit there in a CMD window.
Any way to get this to work similar to cgminer, without a CMD window?
Scheduled Tasks: start on logon -> inv.cmd:
Quote
wscript.exe "C:\Coins\invisible.vbs" "C:\Coins\start_miner_bg.cmd"
exit
-> invisible.vbs:exit
Quote
CreateObject("Wscript.Shell").Run """" & WScript.Arguments(0) & """", 0, False
+ start_miner_bg.cmd:Quote
@echo off
cd "C:\Coins\sgminer-5.0-daily-20140712-15-win32\"
6950_7950_Powercolor_Stock-p8h6v_BG.cmd
+ 6950_7950_Powercolor_Stock-p8h6v_BG.cmd:cd "C:\Coins\sgminer-5.0-daily-20140712-15-win32\"
6950_7950_Powercolor_Stock-p8h6v_BG.cmd
Quote
@echo off
....date crap...
sgminer -c 6950_7950_Powercolor_Stock-p8h6v_multi_BG.conf 2>c:\log\sgminer_%ldt%_bg.log
exit
....date crap...
sgminer -c 6950_7950_Powercolor_Stock-p8h6v_multi_BG.conf 2>c:\log\sgminer_%ldt%_bg.log
exit
Works for me on Win7.
Thanks, turned out what I needed to do was get rid of the bat file and run sgminer.exe direct through the vbs script, with a config file.
I have no idea why, but it works fine. Thanks
October 02, 2014, 07:31:56 AM
Can also confirm lost 2 MH/s total mining X11 combined with my 3x R9 270s and my 1x R9 280X on 14.9 drivers
All right, then I'm sure I fucked up my test somehow.
Did you delete the old .bin's from whatever drivers you had before, and had new ones generated for 14.9 drivers?
Of course I did. I'm gonna re-do the test now, though. 14.6 vs. 14.9 on both my X11 kernels.
Ooookay... this is odd. The hashrate changed - so it seems the driver did as well. Further, I fetched the date on fglrx each time before starting (14.6 being May 29 2014 and 14.9 being Sept 2 2014) so it DID change. As for the bin files, yes, I removed them; I double-checked. Anyway, Savage, this is what I've got, columns are GPU/clocks/mine/stock, rows are obviously GPUs.
Code:
Running driver version 14.6:
270X - 1155/1500 - 3.64 - 2.80
290X - 1045/1600 - 7.96 - 4.86
7950 - 1155/1500 - 5.03 - 4.01
280X - 1155/1500 - 5.77 - 4.54
Running driver version 14.9:
270X - 1155/1500 - 3.64 - 2.80
290X - 1045/1600 - 7.98 - 4.95
7950 - 1155/1500 - 5.03 - 4.05
280X - 1155/1500 - 5.75 - 4.60
changes are too small: probably just compiler variance.
compiling the same .cl file with the same settings may result in different hashrates (I believe a 2% range is common).
the file size changes too.
it doesn't happen with all the kernels but I'm sure it does on x11 as well as on my groestl, for example.
EDIT: so long for those fine optimizations which result in 1% improvement and you think it's good... and it's nothing instead ;-)
I don't understand your last comment. If you're saying my optimizations get 1% improvement, then you're reading the table wrong, because the third COLUMN is my kernel's hashrate, the fourth is the stock kernel's hashrate with the same GPU, driver, and clocks.
Example: On driver version 14.9, my 290X achieved a hashrate of 7.98MH/s with my kernel, and 4.95MH/s with the kernel that is on SGMiner's master branch right now. The clocks were the same for both runs, 1045/1600.
sorry, I didn't mean that.
I was just saying that to me and other developers I know, it often happened that an optimization which led to a 1% improvement, or even more, in the end turned out to be just that variance, so not an optimization at all. It probably happened to you as well.
Yeah, definitely has happened to me. But you have to be very careful with dismissing potential optimizations that only increase speed by a small amount - I've done optimizations that will increase speed only under certain circumstances - and not modify it otherwise.
October 08, 2014, 04:25:44 PM
If the prices were increase is good tho. 
,but didn't knew it was so fast..
,but didn't knew it was so fast.. October 08, 2014, 03:50:45 PM
Wolf0, you could set your kernels mining with some constant percent for you. This would guarantee you profit from those who are using your work. Just an idea...
I've said it before, they get reverse engineered. Not to mention - it'd actually harm the community. If I increase hashrate 30%, diff goes up 30% in under a day. You make the same amount, except you're now paying me a fee - so you're making less.
Not if u rent out the rig (30% - fee)
Wouldn't rig renting be just as impacted? When you make hashrate effectively cheaper, then people sell it for less.
I think u see it to big, just check some renting rigs and check the hashrates of 7950/280x/290x..a lot don't even get high hashrates. It doesn't mean that every miner will know ur +30% minersoftware if u spread it. Not all miners are reading this topic/site. I am not saying u should just spread ur software.
The last time there was a major speed increase for x11 it took miners 2 days to notice and rental prices to increased accordingly.
October 08, 2014, 03:42:55 PM
Wolf0, you could set your kernels mining with some constant percent for you. This would guarantee you profit from those who are using your work. Just an idea...
I've said it before, they get reverse engineered. Not to mention - it'd actually harm the community. If I increase hashrate 30%, diff goes up 30% in under a day. You make the same amount, except you're now paying me a fee - so you're making less.
Not if u rent out the rig (30% - fee)
Wouldn't rig renting be just as impacted? When you make hashrate effectively cheaper, then people sell it for less.
I think u see it to big, just check some renting rigs and check the hashrates of 7950/280x/290x..a lot don't even get high hashrates. It doesn't mean that every miner will know ur +30% minersoftware if u spread it. Not all miners are reading this topic/site. I am not saying u should just spread ur software.
October 08, 2014, 12:49:30 PM
Can someone explain why sgminer automatically forces a terminal window to be open?
I really hate having the terminal open while I'm using the pc, so I was using the following vbs script to hide cgminer:
It works perfectly fine with cgminer and runs the .bat file without issue, and without a CMD window, but whenever I try using it with sgminer it will force open a CMD window. The above vbs script will open the sgminer bat file without issue, and sgminer will run without issue, but it will sit there in a CMD window.
Any way to get this to work similar to cgminer, without a CMD window?
I really hate having the terminal open while I'm using the pc, so I was using the following vbs script to hide cgminer:
Code:
CreateObject("Wscript.Shell").Run "F:\miner.bat", 0, True
It works perfectly fine with cgminer and runs the .bat file without issue, and without a CMD window, but whenever I try using it with sgminer it will force open a CMD window. The above vbs script will open the sgminer bat file without issue, and sgminer will run without issue, but it will sit there in a CMD window.
Any way to get this to work similar to cgminer, without a CMD window?
Scheduled Tasks: start on logon -> inv.cmd:
Quote
wscript.exe "C:\Coins\invisible.vbs" "C:\Coins\start_miner_bg.cmd"
exit
-> invisible.vbs:exit
Quote
CreateObject("Wscript.Shell").Run """" & WScript.Arguments(0) & """", 0, False
+ start_miner_bg.cmd:Quote
@echo off
cd "C:\Coins\sgminer-5.0-daily-20140712-15-win32\"
6950_7950_Powercolor_Stock-p8h6v_BG.cmd
+ 6950_7950_Powercolor_Stock-p8h6v_BG.cmd:cd "C:\Coins\sgminer-5.0-daily-20140712-15-win32\"
6950_7950_Powercolor_Stock-p8h6v_BG.cmd
Quote
@echo off
....date crap...
sgminer -c 6950_7950_Powercolor_Stock-p8h6v_multi_BG.conf 2>c:\log\sgminer_%ldt%_bg.log
exit
....date crap...
sgminer -c 6950_7950_Powercolor_Stock-p8h6v_multi_BG.conf 2>c:\log\sgminer_%ldt%_bg.log
exit
Works for me on Win7.
October 02, 2014, 06:10:26 AM
Can also confirm lost 2 MH/s total mining X11 combined with my 3x R9 270s and my 1x R9 280X on 14.9 drivers
All right, then I'm sure I fucked up my test somehow.
Did you delete the old .bin's from whatever drivers you had before, and had new ones generated for 14.9 drivers?
Of course I did. I'm gonna re-do the test now, though. 14.6 vs. 14.9 on both my X11 kernels.
Ooookay... this is odd. The hashrate changed - so it seems the driver did as well. Further, I fetched the date on fglrx each time before starting (14.6 being May 29 2014 and 14.9 being Sept 2 2014) so it DID change. As for the bin files, yes, I removed them; I double-checked. Anyway, Savage, this is what I've got, columns are GPU/clocks/mine/stock, rows are obviously GPUs.
Code:
Running driver version 14.6:
270X - 1155/1500 - 3.64 - 2.80
290X - 1045/1600 - 7.96 - 4.86
7950 - 1155/1500 - 5.03 - 4.01
280X - 1155/1500 - 5.77 - 4.54
Running driver version 14.9:
270X - 1155/1500 - 3.64 - 2.80
290X - 1045/1600 - 7.98 - 4.95
7950 - 1155/1500 - 5.03 - 4.05
280X - 1155/1500 - 5.75 - 4.60
changes are too small: probably just compiler variance.
compiling the same .cl file with the same settings may result in different hashrates (I believe a 2% range is common).
the file size changes too.
it doesn't happen with all the kernels but I'm sure it does on x11 as well as on my groestl, for example.
EDIT: so long for those fine optimizations which result in 1% improvement and you think it's good... and it's nothing instead ;-)
I don't understand your last comment. If you're saying my optimizations get 1% improvement, then you're reading the table wrong, because the third COLUMN is my kernel's hashrate, the fourth is the stock kernel's hashrate with the same GPU, driver, and clocks.
Example: On driver version 14.9, my 290X achieved a hashrate of 7.98MH/s with my kernel, and 4.95MH/s with the kernel that is on SGMiner's master branch right now. The clocks were the same for both runs, 1045/1600.
October 08, 2014, 12:27:56 PM
Not impossible - if you know C, call CreateProcess() with CREATE_NO_WINDOW flag.
Just call WinMain. October 08, 2014, 09:21:18 AM
Wolf0, you could set your kernels mining with some constant percent for you. This would guarantee you profit from those who are using your work. Just an idea...
I've said it before, they get reverse engineered. Not to mention - it'd actually harm the community. If I increase hashrate 30%, diff goes up 30% in under a day. You make the same amount, except you're now paying me a fee - so you're making less.
Not if u rent out the rig (30% - fee)
October 08, 2014, 06:17:40 AM
Any way to get this to work similar to cgminer, without a CMD window?
There's no way. When Windows starts the application it looks into it and sees it's a console application. It pops up a console. This is the correct behavior.Yes, it would be possible to modify it so there would be a sgminer-noconsole and yes, it's also possible to modify it so it spawns a console only on request but most people isn't interested in moving the miner that way.
October 02, 2014, 03:59:25 AM
Can also confirm lost 2 MH/s total mining X11 combined with my 3x R9 270s and my 1x R9 280X on 14.9 drivers
All right, then I'm sure I fucked up my test somehow.
Did you delete the old .bin's from whatever drivers you had before, and had new ones generated for 14.9 drivers?
Of course I did. I'm gonna re-do the test now, though. 14.6 vs. 14.9 on both my X11 kernels.
Ooookay... this is odd. The hashrate changed - so it seems the driver did as well. Further, I fetched the date on fglrx each time before starting (14.6 being May 29 2014 and 14.9 being Sept 2 2014) so it DID change. As for the bin files, yes, I removed them; I double-checked. Anyway, Savage, this is what I've got, columns are GPU/clocks/mine/stock, rows are obviously GPUs.
Code:
Running driver version 14.6:
270X - 1155/1500 - 3.64 - 2.80
290X - 1045/1600 - 7.96 - 4.86
7950 - 1155/1500 - 5.03 - 4.01
280X - 1155/1500 - 5.77 - 4.54
Running driver version 14.9:
270X - 1155/1500 - 3.64 - 2.80
290X - 1045/1600 - 7.98 - 4.95
7950 - 1155/1500 - 5.03 - 4.05
280X - 1155/1500 - 5.75 - 4.60
October 08, 2014, 05:09:14 AM
Can someone explain why sgminer automatically forces a terminal window to be open?
I really hate having the terminal open while I'm using the pc, so I was using the following vbs script to hide cgminer:
It works perfectly fine with cgminer and runs the .bat file without issue, and without a CMD window, but whenever I try using it with sgminer it will force open a CMD window. The above vbs script will open the sgminer bat file without issue, and sgminer will run without issue, but it will sit there in a CMD window.
Any way to get this to work similar to cgminer, without a CMD window?
I really hate having the terminal open while I'm using the pc, so I was using the following vbs script to hide cgminer:
Code:
CreateObject("Wscript.Shell").Run "F:\miner.bat", 0, True
It works perfectly fine with cgminer and runs the .bat file without issue, and without a CMD window, but whenever I try using it with sgminer it will force open a CMD window. The above vbs script will open the sgminer bat file without issue, and sgminer will run without issue, but it will sit there in a CMD window.
Any way to get this to work similar to cgminer, without a CMD window?
October 08, 2014, 05:00:25 AM
Wolf0, you could set your kernels mining with some constant percent for you. This would guarantee you profit from those who are using your work. Just an idea...
I've said it before, they get reverse engineered. Not to mention - it'd actually harm the community. If I increase hashrate 30%, diff goes up 30% in under a day. You make the same amount, except you're now paying me a fee - so you're making less.
This makes sence , you have a point...
October 01, 2014, 08:16:17 PM
Can also confirm lost 2 MH/s total mining X11 combined with my 3x R9 270s and my 1x R9 280X on 14.9 drivers
All right, then I'm sure I fucked up my test somehow.
October 07, 2014, 10:25:41 PM
Wolf0, you could set your kernels mining with some constant percent for you. This would guarantee you profit from those who are using your work. Just an idea...
October 07, 2014, 04:39:11 PM
Wolf0,
Why don't you consider sell your kernel to 200 peoples (?? other number) at same time.
I mean, you set a price and when all buyers have payed, they will receive the kernel at same time - send a mail with a link.
Just an idea for you to make some money and the community can take advantage of your work - maybe someone make other improvements. (sorry my poor english
)
Why don't you consider sell your kernel to 200 peoples (?? other number) at same time.
I mean, you set a price and when all buyers have payed, they will receive the kernel at same time - send a mail with a link.
Just an idea for you to make some money and the community can take advantage of your work - maybe someone make other improvements. (sorry my poor english
)
October 07, 2014, 03:35:54 PM
all that stuff about advanced code is fishermen's talk,
what beats me why so drastic fall of performance with 14.9
on badman's mod with public kernels
what beats me why so drastic fall of performance with 14.9
on badman's mod with public kernels
Probably AMD changed something small in the compiler - not sure if the one doing AMD IL -> ISA is on the card or not, but if it's the driver (and I think it is) even a small change could make that mess slow to a crawl.
yep, but what...
even scrypt is damn slow, 450 vs 650 with same gpu settings,
pallas groestl is 7.5 after 17.5 with 14.7, great
I've tried tweaking it for 14.9 and I was able to improve it a bit but far from 14.6/14.7 speed.
Jump to: