Hash-rate reporting


#1

Block explorer http://www.aeknow.org/ claims a hashrate of 4.43 M Sols/s,
which is obviously bogus, as a 1080Ti finds a solution roughly every 10 seconds, and there are nowhere near 44 million GPUs mining AE.
The proper hash-rate unit is Graphs Per Second.

How many GPUs are estimated to be mining AE? I thought it was on the order of 100K?!


#2

The data are directly spidered from the three big pools:beepool, f2pool and uupool.

The miner software such as HSPminer considers each caculation as a sol, that is 4-5sols /sec for 1080ti.

There is a different caculation between beepool and f2pool. I asked Jungle of beepool and confirmed the difference, that is, beepool’s hashrate=miner’s *10, and aeknow.org fixed the difference.


#3

The estimation of ~100K 1080ti’s hashrate is reasonable.

There are some AMD cards too.


#4

So, no bogus, just difference~high efficiency miner software defined the mining unit.


#5

I notice this too, but since the software does not report or state solutions found per unit of time, the people creating the miners for their pools are using whatever measures they want.

This is why it is not as easy, but definitively not lies!


#6

With the current difficulty the miners is doing ~7K solutions/second (where by solution I mean finding a 42-cycle) so the “hash-rate” is 350K Graphs/second.


#7

Can i just calculate the number of Graphic Card by dividing the difficulty through 7?


#8

Currently the difficulty is 2000K as reported by aeknow.org this is the number of solutions needed to solve the puzzle. On average we need three minutes to solve it, i.e. 180s. Thus 11.1K solutions/sec. 50 42 graphs per solution gives 555 465K Graphs/second. A card can make 4-7 graphs per second, not sure about the latest numbers there, so 100K cards give or take…

So a rough estimate is the difficulty divided by 20?!


#9

Should be 42 graphs per solution, assuming solvers at fidelity 1.
For lower fidelity, it will be 42/fidelity graphs per solution.


#10

It was a while since I read the paper, but wasn’t the probability to find a solution 2.2% (i.e. more like 45.5 graphs per solution)? Or did the default parameters change perhaps :thinking:

But still the same ballpark applies…


#11

You can watch either of my GrinCon presentations to see a proof that the expected number of L-cycles in a large random bipartite graph tends to 1/L. This proof is missing from the old paper.


#12

Thanks! That explains why I didn’t remember it :wink: