avoid hash rate drop during dev pool mining

[psychocrypt]

Since the dev pool is sometimes using another POW than the user pool the
hash date can strongly increase or decrease.
In a case of a hash rate drop a monitoring software could trigger a
wrong miner restart.

• use the hash rate calculated during the user pool mining to
  interpulate the number of hashes during the dev pool mining so that the
  statistics stay constant.

[Spudz76]

Why not just have a totally separate set of stat buckets for each pool and switch which set is pushed or read from depending on what pool is active. Smoothing/caulking just hides the problem where just keeping the data separate to begin with is more sensible. Plus once donate phase is over the stats should jump back to exactly what they were before the detour, not be skewed by unrelated events.

[psychocrypt]

Because it is unimportant for the user howmuch hash rate he had on the dev pool. Meta miner would also have problems to interprete the data right. Since we are not supporting coin hopping stats per pool will make the hash rate report longer and more complex.

[Spudz76]

Meta miner will kill off xmr-stak anyway as soon as it doesn't see traffic through its proxy?

[Spudz76]

Also it doesn't even read the output except for the speed collection phases. Normal operation only watches the work it has passed in via proxy and makes a rate from that (its own).

[psychocrypt]

If they messure it by it's own we can not avoid that the traffic goes not to there proxy (thats the nature of the dev fee) But some messure the hashrate over json api.

[Spudz76]

Then it should just repeat whatever the last known user pool data was (freeze time but still replay the report) then simply continue after donate phase (and subtract all time used for connect and donate and reconnect from total-time for stats).

Meta-miner is set by default at 300s for no traffic so it may just wait for resume. But if xmr-stak hangs up the user pool socket it will assume failure and kill immediately. So having both sockets open (simulcast) instead of full jumping (channel switch) would work and also solve whatever that other complaint was about the couple seconds of wasted time for the connection. Bring up the donate pool connection async, and then jump off the user pool @ accepted event directly onto the other job (already connected logged in and got a dev job assignment) with ms lag time then hop back (and hangup dev pool, but never hangup user pool).

And say I'm mining pico @ 2200H/s and have my proxy-supervisor (not meta-miner) set to kill if it drops below 2000H/s ... then dev pool kicks in doing some slow ass algo @ 200H/s - bam killed. Unless you replay the original rates until real mining continues (no smoothing, so no rate dip)