Topic: Genesis Mining Presents: SGMiner-GM - now with Zawawa's GG! [Updated 17/01/2017] - page 24. (Read 140431 times)

A clean 5.5.4 build would be nice.  It looks like someone just tarred up the whole repo including source and object files after doing a build.

If you reduce the intensity level, that will reduce the HW errors. But the hash rate will also reduce a bit.

Thanks to ElioVP my 390 seems to be doing 28.8 stock but still a lot of HW errors...This is only on ethash algorithm.
P.S. zawawa -> https://bitcointalksearch.org/topic/gateless-gate-sharp-138-30mhs-ethash-on-rx-480-1716584 <- has optimized mrb's silentarmy kernel. Development is still in progress, I see Wolf0 already knows about the that. It will be very nice if you update the equihash kernel.

Have the same issue.
Btw It's really cool to see GPU fans and speed.
Really useful feature.
Especially when you can manage it.

There's something really odd... I've tested xmr, equihash and ethash+ethash-genoil.
XMR gives almost 800H/s on R9 390 which is good enough.
Equihash gives 90S/s which is also good for sa v5.
So nothing odd for both algos but when I switch to ethash I see 65Mh/s on r9 390 and no pool errors but on the pool worker is not appearing, tried ethash-genoil - 35Mh/s and still not appearing worker on pool...
Is there something wrong with ethash algo? I've used eth.conf posted on the first page...
Thank you.

I think it is not their priority. They need to make the miner stable first. Then they will optimise it to match the performance.

latest sgminer-gm gets as a little as 100h/s per R9 NANO on equihash.. Genesis guys, any idea how have you got to overcome a big gap between sgminer-gm/equihash and optiminer/CM?..

I'm now using Ubuntu 16.04 which has finally gotten stable enough for mining.  Last night I updated the the latest AMDGPUPRO linux drivers which were just released 2 days ago and it got rid of most of those "hardware errors" being reported by the mining software

With the latest Linux driver I saw a small increase in hashrate as well and the variance I was seeing on the pool side has drastically reduced since upgrading the drivers.  I am still running the previous release of sgminer-gm and have not tried out the current version.  I will try it on one of my rigs today but the previous release has been very stable for me.

Thank you all for your hard work on this code.  I still have not had a chance to look through all the code but since you have reformatted it to make it more human readable I suspect I will enjoy the process.  I'm old school tho, I will kill a tree to print the entire code base so I can write and scribble ideas all over it

Oh I'm running Linux kernel 4.4.0-53 right now also if anyone wanted more details on my configuration.

Current performance with my system customization:
GPU's Per Rig: 6 X RX470 8GB
Ram: 8GB
CPU: Pentium (2 cores, no hyper-threading)
VBIOS: Customized with hex editor
Power Supply: 1000 Watt Platinum
Motherboard Bios: Customized with hex editor
ETHASH Total: 175.8 Mh/S
System Wattage (From Wall): 548 Watts/h
Single GPU Hashrate: 29.3 Mh/s

I have no clue how many weeks I put into getting all these customization's completed to achieve this performance level but once I had one rig configured it was easy to do the others.

Can sgminer-gm mine to nicehash xmr pool? Or is nicehash still not playing "nice" with their xnonce rubbish...

RUN IT WITH THE HELP COMMAND--

Running SGminer with "-h" will list the supported command-line options.  I usually run a miner with "miner -h > help.txt" so that I have a text reference file.

I think that optimization is the next goal.  Currently, the implementation of SGminer-GM incorporates CryptoNight, Dagger-Hashimoto, and Equihash algorithms, alongside classic algorithms.  Equihash in this miner is currently based on SilentArmy v4 code, and requires updating.  The miner is working well, and needs to be tuned.

Please correct me if I am wrong, but the current implementation will allow for an auto-switching configuration profile to select the best algorithm out of all the implemented algorithms.  That is a BIG deal for AMD cards.

Hang tight, coders gotta code.       --scryptr

Thank you! Seems slower than Claymore, any modifiers that are used in the startup string like intensity or such?

For ETH use this :

setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100

sgminer -k ethash (or ethash-genoil)    -o eth-eu1.nanopool.org:9999 -u wallet# -p z   

pause

Hello,

Can someone provide me with a proper launch bat file. I must be doing something wrong, I tried to mine at nanopool to my wallet but it will not connect to pool.

sgminer -o eth-eu1.nanopool.org:9999 -u wallet# -p z

Yes, a lot of people get worked up over seeing a new measurement, in this case hardware errors. It really doesn't matter that much (unless you are getting loads of them) what matters is what the pool is showing. Shares submitted and accepted are what is paying your bills in the end. The local readings are useful for making minor adjustments to your settings, but they offer only an approximation of reality. As you alluded to, Claymore's miner may very well generate HW errors as well, but since these are not specifically displayed no one really cares.

Think of it much like your car speedometer (love car analogies). While you use your speedometer to adjust your speed while driving, it is probably not 100% accurate. If you think you are driving 58 in a 55 zone you may not feel uneasy passing that cop hiding out in the bushes. However if his radar says you were actually going 62 you might get a ticket. It won't mean much to him if your speedometer (hashrate) reading differs from his "official" reading, and he is really not going to be influenced one way or another if your check engine light (HW errors) happens to be on. Much the same way that pools don't really give a rats arse about your miner's displayed hash-rate or any HW errors. While these readings can be useful to adjust your miner's performance, what the pool cares about is how many submitted and accepted shares you contribute. If you can, run both miners with the same settings at a pool for equal amounts of time and compare these results. This is where the rubber meets the road so to speak.

Too many, IMHO I've was unable to experiment yesterday-today, and left sgminer working with the 1100/1375 frequencies. After 19h of mining I have: accepteds - 405, HW - 288. So, nearly 50% of work is lost.
If I understanding correctly the process, the miner is working on a share, and if there is a HW error during calculation, all of the work on that share is lost, and the miner should begin from scratch. Taking into account, that calculation of one share takes a few minutes, we are loosing more than half of effectiveness

BTW, Claymore's miner has the parameters "--cl-global-work", "--cl-local-work". What are the corresponding sgminer parameters? I suspect, that --cl-local-work <=> --worksize in sgminer?..

about 25-30 per hour

sense this miner shows whats really going on with the GPU over Clay more once this is back up to speed, I plan to use this miner to mine Zec till then I'm in the dark with the hardware errors and it make me wonder just how many CM causes at the high speeds it does . 

bouc
Thank you for info.

How many HW errors you get exactly? (for example during 1 hour of mining?)

hi,
for my 280x, i'm using :
worksize 192
xintensity 1024
gpu-threads 1
gpu freq 1100
mem freq 1350

with this intensity, i got low hw errors, if I push the intensity, I win little more, but more hw errors... then

Hi to community.
Please, help me to find out a some answers about ETH mining. My GPUs are PowerColor 7970 3Gb OC + MSI 7970 Lightning BE :

1. Is there anybody, who mining with 7970? What are your GPU/Mem clocks?
2. What are your Intensity / xIntensity /raw Intensity values?
3. Are you able to deal with HW errors? I feel, that there is something with the gpu/mem clocks + intensity values, but still can't find the correct ones and my HW errors are almost twice as accepteds...

Will be gratefull for help.