Closed GitGab19 closed 1 month ago
Can I take this up
Hey @GitGab19 , Please correct me if I'm wrong. To measure the latency for this particular setup, we will have two proxies: one between TP and JDC, and another between JDC and the Pool. For the first proxy, we will start the assessment when we receive a setNewPrevhash message from TP to JDC and end it once we receive a SetCustomMiningJobSuccess message from the Pool to JDC.
I would make it a bit different:
What do you think @Shourya742 ?
I would make it a bit different:
- the first proxy is right
the second one I think it should be put between translator and downstreams
- and in this proxy I would look for the new mining.notify sent to downstreams (so that we end the measurement exactly when the new job is sent to the miner)
What do you think @Shourya742 ?
Oh yes, I completely overlooked the downstream availability. It makes sense to point out the mining notify.
You can take the sv1-custom-proxy which counts the share as an example for that. Or maybe we should try to integrate things together (?)
You can take the sv1-custom-proxy which counts the share as an example for that. Or maybe we should try to integrate things together (?)
Yes, sure. I have raised a PR for this. Please review and suggest any changes.
Closed by @Shourya742 in https://github.com/GitGab19/benchmarking-tool/pull/1
As defined in the requirements document here we need to measure how much time is needed to get a new fresh job related to a new prev hash from the pool (this is the case in which a new block is found and this is of course in the case of configuration A).
The approach that I had in mind was to leverage the library that I used to build the current sv2-custom-proxy to build specific proxies to do that. But I'm completely open to any other way and suggestions about this.