Measure time to get a new job (based on a new prev hash) from the JDC

stratum-mining / benchmarking-tool

Benchmarking tool to measure Stratum V2 and Stratum (V1) protocol performances in different contexts

Other

9 stars 6 forks source link

Measure time to get a new job (based on a new prev hash) from the JDC #11

Closed GitGab19 closed 1 month ago

GitGab19 commented 1 month ago

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.

Shourya742 commented 1 month ago

Can I take this up

Shourya742 commented 1 month ago

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.

GitGab19 commented 1 month ago

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 ?

Shourya742 commented 1 month ago

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.

GitGab19 commented 1 month ago

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 (?)

Shourya742 commented 1 month ago

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.

GitGab19 commented 1 month ago

Closed by @Shourya742 in https://github.com/GitGab19/benchmarking-tool/pull/1