Multi-Client Hashrate

[kralverde]

is sorted containers used at all?

[kralverde]

what is the point of the timed dict? couldnt you just indefinitely save each miner's hashrate and add those up? why does it need to expire

[Seal-Clubber]

Everytime the eth_submithahsrate call gets made it adds the clientid and hashrate into the dict, if you recconect a miner it will use a new client id and report the same hashrate as before which will cause it to add both hashes into the total. If you know of a better way to record submited hashrate or an alternate way of distinguishing between rigs do let me know.

[Seal-Clubber]

is sorted containers used at all?

When I tried to add the sha256 hash of the expiringdict it didnt like that sortedcontainer was not specified with a version number even tho I tried putting both hashes under the dict one, in linux I dont think you need the sortedcontainers to be listed.

[kralverde]

Everytime the eth_submithahsrate call gets made it adds the clientid and hashrate into the dict, if you recconect a miner it will use a new client id and report the same hashrate as before which will cause it to add both hashes into the total. If you know of a better way to record submited hashrate or an alternate way of distinguishing between rigs do let me know.

Could you add a callback to https://github.com/kralverde/ravencoin-stratum-proxy/blob/bd383d7c1c468fcbc395898db6302630cc045db6/stratum-converter.py#L145

If you don't know the id at run time, you could have a standard global default dict of [id -> 0], add an id variable to the session object, on first hashrate report set id of id variable and set default dict [id -> hashrate]. In the connection_lost just pop it from the default dict. I don't think we need to worry about async safeness for a ui property like this.

[Seal-Clubber]

Hashrates based on session object id. #17