This is dependent on how hash rate
is timed on the mining software. The transit time between submitting to a proxy
/ pool and getting the next batch will result in a zig zag pattern for total
hashrate. Hashrate is never flat.
Sorry, this is totally incorrect. The mining software should be reporting
your TRUE hashrate, which will be extremely consistent if mining optimally. The
reported hashrate on the pool is going to fluctuate because it's an estimate
based on the number of shares submitted at a certain difficulty level. The
calculation is pretty simple and naive, which is why it's so inaccurate:
sum(valid_shares_diff[]) / duration
Example: ~1300H/s fixed diff of 40k with target of 30 seconds, over 1 hour:
(40000 * 120) / 3600 = ~1333H/s
Real world example: the 15 minute hashrate is within 0.2 H/s of the immediate
rate on each core:
https://astr.al/u/c3734b70_399x184.png
On top of the nonce range issue, a 1000ms round trip is completely unheard of.
Even 56Kbps dialup can do better than that. If you're mining on a 1 second
delay, you should probably consider fixing that before anything else.
Xmrig for example will report on a
5sec interval, if you happen to take 1 second to round trip to your proxy / pool
your hashrate will be 0 for that second - resulting in a lower 5sec
average.
That isn't really a good way to describe how it works. A standalone single rig
has very little chance to exhaust the given nonce range. Block time is 120
seconds and the nonce is 32 bits. With stak at least, the upper 10 bits are
reserved for flags (thread ID and other fields), leaving you with 22 bits of
nonce. Using my 1300H/s example again:
nonce_space / hashrate = nonce_lifetime
e.g. (2**22) / 1300 = 3226 seconds, or in other words: 53.7 minutes per job
before you request additional work. Even with your example of 10 KH/s would
require 7 minutes to exhaust the nonce space - and that'd have to be 10KH/s per
thread as each thread is given its own nonce range to work on.
Your workers ability to do work is completely based on being able to talk over
stratum. Hence why it's better to tailor your own difficulty so you spend more
time hashing, and not round tripping to your upstream. A 10KH/s machine hashing
at 1000 difficulty will have a lower hash rate due to latency and frequency,
than a difficulty of 30000.
The only time it's suitable to use a fixed difficulty is when you're connecting
to a braindead stratum server, like the NiceHash one. Any pool running
nodejs-pool (i.e. not node-cryptonight-pool) will have vardiff working as it
should, and for the ideal payment you should be using vardiff.