First test for the Sumo fork.

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
I just tested xmr-stak auto configuring for the new sumo algo, uses the old algo but uses 4mb per thread config that the new algo will use, and it looks like cpu mining after the cryponight forks will not be worth it unless your cpu's have a huge amount of L3.

I tried to run xmr-stak 2.3.0 mining sumo on my dual E5-2667 v3 ES pc with a RX Vega 64 FE and it errors out with:
Error CL_INVALID_KERNEL_ARGS when calling clEnqueueNDRangeKernel for kernel 0.

Thats odd because 2.3.0 mines monero without any errors so I still need to figure out whats going on.

So I did a quick test on a i5 8400 9mb L3 coffee lake 6 core, old sumo config was about ~270-290 H/s on four threads, new is ~150H/s on two threads.

Gpu's are affected also, GTX 1060 6gb mining the old sumo config was ~557 H/s, new sumo config ~402 H/s with the EXACT settings in the config file and running afterburner at the same EXACT settings.

Now this is one test and will try it out on other pc's/servers.

Monero mining on xmr-stak 2.3.0 is still auto configuring for the old algo, looking at the config file its the same as the old as far as the number of threads, and it mines about the same and it's supposed to auto configure to the new algo after the fork.

I foresee a massive drop in the network hashrate for both Monero and Sumo but whether or not its worthwhile is yet to be seen.
 
Last edited:

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
I just fixed xmr-stak on my dual E5-2667 v3/ RxVega64 FE pc, I just copied the first compiled version of xmr-stak for monero over to a new folder and copied the sumo specific files, cpu.txt, pool.txt, amd.txt and config.txt and that worked.

Ubuntu 16.04.3 64bit.

[2018-04-02 20:41:26] : Result accepted by the pool.
HASHRATE REPORT - CPU
| ID | 10s | 60s | 15m | ID | 10s | 60s | 15m |
| 0 | 39.6 | 39.6 | (na) | 1 | 40.9 | 41.0 | (na) |
| 2 | 45.9 | 46.1 | (na) | 3 | 45.6 | 45.6 | (na) |
| 4 | 46.4 | 46.1 | (na) | 5 | 46.9 | 46.6 | (na) |
| 6 | 41.2 | 41.3 | (na) | 7 | 41.2 | 41.3 | (na) |
| 8 | 39.6 | 39.6 | (na) | 9 | 39.5 | 39.5 | (na) |
| 10 | 42.5 | 42.4 | (na) | 11 | 46.4 | 46.3 | (na) |
| 12 | 42.3 | 44.9 | (na) | 13 | 46.1 | 45.9 | (na) |
| 14 | 46.2 | 46.3 | (na) | 15 | 40.9 | 40.8 | (na) |
| 16 | 40.8 | 40.9 | (na) | 17 | 39.5 | 39.5 | (na) |
Totals (CPU): 771.5 773.6 0.0 H/s
-----------------------------------------------------------------
HASHRATE REPORT - AMD
| ID | 10s | 60s | 15m | ID | 10s | 60s | 15m |
| 0 | 650.7 | 650.0 | (na) | 1 | 649.4 | 647.6 | (na) |
Totals (AMD): 1300.1 1297.6 0.0 H/s
-----------------------------------------------------------------
Totals (ALL): 2071.6 2071.2 0.0 H/s
Highest: 2098.8 H/s
-----------------------------------------------------------------


The Gpu is just about 50H/s less but the cpu's are about 575H/s less.

First thought of these quick tests is that the high end gpu's will not be affected much at all, the midrange will be affected more and the lowend gpu's are a question for now.

But cpu's will be affected the most.
 
Last edited:

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Another quick test:

i3 8100 6mb L3 coffee lake 4 core cpu
Power Color Red Devil RX 580 8 gb

Old config:
Cpu 3 threads at 200H/s
Rx580 693 H/s

New config:
Cpu 2 threads 144 H/s
Rx 580 671H/s
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Now I want to make this clear, I am not mining the new algo but mining the old algo with the new config which is 4 mb per thread instead of 2mb.

So this might not be exact but its good enough to get an idea what to expect.

It seems xmr-stak is auto-configuring for the new algo with the configuration of the threads before the fork, xmrig is supposed to auto configure as the monero fork happens so I can't do the same sort of quick test's with xmrig.

But it looks like just about every cpu will take a 50% hit in hash rate depending on L3 size and cores.
 

onsit

Member
Jan 5, 2018
98
26
18
29
From what I understand Sumo is doing their own algo implementation. Not Monero or Aeon. Their approach is to switch the algo once and hope it deters ASICs as opposed to 6month small tweaks.

Infact it's called cryptonight-heavy probably for that reaaon. With that 4mb scratch pad, it's going to knock out a lot of lower tier miners stuck on CPUs with 12mb or less of L3.

Do you have any power consumption numbers? If you are using a larger clump of L3 but less cores you are doing less CPU context switching.
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
From what I understand Sumo is doing their own algo implementation. Not Monero or Aeon. Their approach is to switch the algo once and hope it deters ASICs as opposed to 6month small tweaks.

Infact it's called cryptonight-heavy probably for that reaaon. With that 4mb scratch pad, it's going to knock out a lot of lower tier miners stuck on CPUs with 12mb or less of L3.

Do you have any power consumption numbers? If you are using a larger clump of L3 but less cores you are doing less CPU context switching.

I knew that sumo's new algo is different than Monero's new one, and I just compiled xmr-stak to run monero7 and it hashes about the same as monero does on xmrig. Much faster than Sumo.

I just not have seen any definite hashrate numbers yet and wanted to get an idea, and I really did not want to run my miners on the testnets.

And you have to take all of this with a grain of salt because we wont really know until the forks happen.

I have not even thought about power numbers right now, just trying to get them to work and see how they mine.

I have the same issue and the same error on my dual E5-2620 v1 server also running Ubuntu 16.04.3 but I am not able to fix it like I did on my main pc.

And I know that all of this "testing" may not have any bearing on what happens after the forks but i thought i'll give it a go.

Also xmr-stak is giving me grief on my Onda 6x P106-100 1060 box.
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Got the P106 gpu box working, I can't tell you how many times I have had a problem with Windows that just does not want to be fixed and then say WTH let me reboot it one more time and it ends up working.

Mining Sumo at about 600 H/s less on it with the new configuration.

Ok I have pc's mining Sumo with the new xmr-stak and one mining Sumo with xmrig.

I think i'll just keep them running and see what happens after the fork.

Fork supposed to be at block 116520, its at 116271 currently so it should be forked soon.
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Yep someone got some asics mining Sumo. In one week the difficulty is up to over twice what it was.

 

funkywizard

mmm.... bandwidth.
Jan 15, 2017
661
283
63
USA
ioflood.com
From what I understand Sumo is doing their own algo implementation. Not Monero or Aeon. Their approach is to switch the algo once and hope it deters ASICs as opposed to 6month small tweaks.

Infact it's called cryptonight-heavy probably for that reaaon. With that 4mb scratch pad, it's going to knock out a lot of lower tier miners stuck on CPUs with 12mb or less of L3.

Do you have any power consumption numbers? If you are using a larger clump of L3 but less cores you are doing less CPU context switching.
In addition to the higher scratchpad size, it lowers the number of rounds. They expect this will lead to a relatively similar amount of computational power required per hash. Simply changing your scratchpad to 4MB and keeping the old algo will not give you an accurate idea of the hashrate to expect.

Sumo says that their intention was to make GPUs more efficient at the expense of CPUs, which appears to be the case. Their stated purpose there was to discourage botnet mining. Additionally, changing the algo this way is also supposed to discourage ASICs in general, and eliminate the previous ASIC's in particular.

As I see it, having the smaller altcoins on a different algo than Monero is a smart move. At the current size, nobody will produce an ASIC for SUMO as it's too small a network for that to make sense. In fact, if you remove ETN and Monero, all the other cryptonote coins together are not worth making an ASIC for, even if they all decided to use the same algo as SUMO.

Monero switching their algo slightly every 6 months will discourage ASIC production. Even if it does not eliminate it, it does reduce the timeframe any ASICs will be useful. Monero is such a big coin now in terms of market cap, that if it's possible to make an ASIC, someone will do so. So their idea of making tweaks as needed seeems reasonable, compared to trying to come up with an impossible-to-ASIC algorithm.
 

onsit

Member
Jan 5, 2018
98
26
18
29
In addition to the higher scratchpad size, it lowers the number of rounds. They expect this will lead to a relatively similar amount of computational power required per hash. Simply changing your scratchpad to 4MB and keeping the old algo will not give you an accurate idea of the hashrate to expect.

Sumo says that their intention was to make GPUs more efficient at the expense of CPUs, which appears to be the case. Their stated purpose there was to discourage botnet mining. Additionally, changing the algo this way is also supposed to discourage ASICs in general, and eliminate the previous ASIC's in particular.

As I see it, having the smaller altcoins on a different algo than Monero is a smart move. At the current size, nobody will produce an ASIC for SUMO as it's too small a network for that to make sense. In fact, if you remove ETN and Monero, all the other cryptonote coins together are not worth making an ASIC for, even if they all decided to use the same algo as SUMO.

Monero switching their algo slightly every 6 months will discourage ASIC production. Even if it does not eliminate it, it does reduce the timeframe any ASICs will be useful. Monero is such a big coin now in terms of market cap, that if it's possible to make an ASIC, someone will do so. So their idea of making tweaks as needed seeems reasonable, compared to trying to come up with an impossible-to-ASIC algorithm.
At the same time, a few coins are stating they will remain PoW unchanged. Such as KRB - which also seems to have an active developer - they were the first implement changes to combat pulse mining.

I think at some point while ASICs ruin mining for the average joe. It does strengthen the network by allowing much larger buffer size to protect against 51% attacks with rented hash (even though ASICs are part of this attack vector too).

I could see alt coins being more stable if they have dedicated ASIC miners working through the emissions model - as opposed to some guy turning on his I3 processor at work and doing basically nothing for the network as a whole. The value proposal for almost all shit-crypto-note coins is that they plan to do something "special" with left over nonce bits. For them to leverage that extra space for whatever they want to do, they will need a robust mining network.
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Sumo forked today and it looks like a new version of xmr-stak is out with an amd opengl bug fix, giving that a go on my dual E5-2620 V1 RX 580 server.

EDIT: The latest version , 2.4.2, fixed the error I was having.
 
Last edited:

onsit

Member
Jan 5, 2018
98
26
18
29
Wow... hashrate really is 50%. on an open compute E5-2660. Used to get ~850 or so.

Code:
root@oc-node01:/usr/local/bin# ./xmrig -c config.json
 * VERSIONS:     XMRig/2.6.0-beta1 libuv/1.8.0 gcc/7.1.0
 * HUGE PAGES:   available, enabled
 * CPU:          Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz (1) x64 AES-NI
 * CPU L2/L3:    2.0 MB/20.0 MB
 * THREADS:      8, cryptonight-heavy, av=1, donate=5%
 * POOL #1:      sumopool.sonofatech.com:5555
 * COMMANDS:     hashrate, pause, resume
[2018-04-04 21:25:14] use pool sumopool.sonofatech.com:5555 104.131.137.114
[2018-04-04 21:25:14] new job from sumopool.sonofatech.com:5555 diff 20000
[2018-04-04 21:25:22] speed 2.5s/60s/15m 379.4 n/a n/a H/s max: n/a H/s
[2018-04-04 21:25:23] speed 2.5s/60s/15m 379.4 n/a n/a H/s max: 379.4 H/s
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Wow... hashrate really is 50%. on an open compute E5-2660. Used to get ~850 or so.

Code:
root@oc-node01:/usr/local/bin# ./xmrig -c config.json
 * VERSIONS:     XMRig/2.6.0-beta1 libuv/1.8.0 gcc/7.1.0
 * HUGE PAGES:   available, enabled
 * CPU:          Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz (1) x64 AES-NI
 * CPU L2/L3:    2.0 MB/20.0 MB
 * THREADS:      8, cryptonight-heavy, av=1, donate=5%
 * POOL #1:      sumopool.sonofatech.com:5555
 * COMMANDS:     hashrate, pause, resume
[2018-04-04 21:25:14] use pool sumopool.sonofatech.com:5555 104.131.137.114
[2018-04-04 21:25:14] new job from sumopool.sonofatech.com:5555 diff 20000
[2018-04-04 21:25:22] speed 2.5s/60s/15m 379.4 n/a n/a H/s max: n/a H/s
[2018-04-04 21:25:23] speed 2.5s/60s/15m 379.4 n/a n/a H/s max: 379.4 H/s

Yep, looks like sumo is really only a gpu minable coin now.

I will fire up my open compute miners right before monero forks, it should mine almost the same as before.
 

onsit

Member
Jan 5, 2018
98
26
18
29
Yep, looks like sumo is really only a gpu minable coin now.

I will fire up my open compute miners right before monero forks, it should mine almost the same as before.
No change in power usage either, in my supermicro's dual node.

2x E5-2450L = 300 H/s @ 140 watts

So that's 600 H/s @ 280 Watts, which used to be 1300 H/s @ 280 watts.
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Oh my.... network difficulty has tanked! :D

Was 34,924,602,381 and now its 545,815,405 .... WOW
 

onsit

Member
Jan 5, 2018
98
26
18
29
Oh my.... network difficulty has tanked! :D

Was 34,924,602,381 and now its 545,815,405 .... WOW
Not all pools are up to date with forks. Give sumo.fairpool.cloud a try - they seem to be at the proper block height.

Wow... My 7x RX550 rig is doing so poorly too.

Code:
HASHRATE REPORT - AMD
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |  188.6 |  188.4 |   (na) |  1 |  188.5 |  189.0 |   (na) |
|  2 |  188.5 |  189.0 |   (na) |  3 |  189.4 |  189.2 |   (na) |
|  4 |  189.2 |  189.2 |   (na) |  5 |  189.2 |  189.1 |   (na) |
|  6 |  188.8 |  188.7 |   (na) |
Totals (AMD):  1322.1 1322.7    0.0 H/s
-----------------------------------------------------------------
Totals (ALL):   1322.1 1322.7    0.0 H/s
Highest:  1323.0 H/s
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
Not all pools are up to date with forks. Give sumo.fairpool.cloud a try - they seem to be at the proper block height.

Wow... My 7x RX550 rig is doing so poorly too.

Code:
HASHRATE REPORT - AMD
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |  188.6 |  188.4 |   (na) |  1 |  188.5 |  189.0 |   (na) |
|  2 |  188.5 |  189.0 |   (na) |  3 |  189.4 |  189.2 |   (na) |
|  4 |  189.2 |  189.2 |   (na) |  5 |  189.2 |  189.1 |   (na) |
|  6 |  188.8 |  188.7 |   (na) |
Totals (AMD):  1322.1 1322.7    0.0 H/s
-----------------------------------------------------------------
Totals (ALL):   1322.1 1322.7    0.0 H/s
Highest:  1323.0 H/s

Fairpool is the pool I have been using, my Rx 580's are about 50 h/s lower each and the gtx 1060's are about 100h/s each.
 

onsit

Member
Jan 5, 2018
98
26
18
29
Fairpool is the pool I have been using, my Rx 580's are about 50 h/s lower each and the gtx 1060's are about 100h/s each.
That's a shame. My RX550 are performing 50% unfortunately. I used to get ~450-500 per RX550 2GB - but I can now see the limitations they run into being the lower memory variant.

Most I can squeeze out after tweaking is ~1650 H/s for 7x RX550.

Granted, I think I might spin up all my miners and just do sumo while the diff is low. Even if it is 50% less hash, difficulty is SUPER low.
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
That's a shame. My RX550 are performing 50% unfortunately. I used to get ~450-500 per RX550 2GB - but I can now see the limitations they run into being the lower memory variant.

Most I can squeeze out after tweaking is ~1650 H/s for 7x RX550.

Granted, I think I might spin up all my miners and just do sumo while the diff is low. Even if it is 50% less hash, difficulty is SUPER low.

It's super low and starting to go up, so I am pointing everything at it that I can.

That plus everyone else is mining it at a lowered hash rate too.
 

Klee

Well-Known Member
Jun 2, 2016
1,285
393
83
My open compute servers:

2660v1 x2 443 H/s
2665v1 x2 449 H/s

Now for some reason the RX Vega is hashing at half of what it was.