Vardif needs better explanation, and to show progress in the UI, until Vardiff kicks in, users are reporting 'stats are off" type of issues.

[pavlenex]

There's a lot of confusion until proper varrdif gets adjusted. Users are reporting "stats are off"

We need to ensure UI properly elaborates how adjustment is working and educate user around it

The UI shows nominal_hashrate, not measured hashrate. Nominal_hashrate is derived from the difficulty assigned to the miner, not from actually counting submitted shares.

1. Miner connects → translator opens an SV2 channel with some initial nominal hashrate (e.g. 100 TH/s based on initial difficulty)
2. UI polls every 3 seconds and immediately shows that 100 TH/s
3. Vardiff hasn't run yet it only fires every X seconds
4. After 60s, vardiff measures shares submitted, realizes actual hashrate is ~46 TH/s, adjusts difficulty down
   nominal_hashrate finally corrects to ~46 TH/s
5. UI catches up within the next 3s poll
6. So in the worst case a user sees the wrong hashrate for X after connect, and possibly several minutes if shares are sparse (BitAxe scenario).

[pavlenex]

From user:

I personally like setting slightly higher diffs as it reduces useless strain on the pool (as I understand it). But users of my pool were confused because they thought lower amounts of shares are a bad thing. From experience, ppl expect a diff of around 1000 for 1TH Bitaxes and 2100 for 5TH miners like NerdQaxe++

[pavlenex]

Some interesting discussion here #47 (comment)

[plebhash]

Some interesting discussion here #47 (comment)

I guess I'll migrate those discussions here, since it feels like the right place (instead of opening a new issue)

below is what I originally raised there:

---

I think we should also change this page:

ultimately, whatever value the user inputs here ends up as tproxy's min_individual_miner_hashrate config parameter, while we're labeling it as "total expected hashrate"

this leads to a misleading vardiff UX... let's analyze a few scenarios:

---

scenario A

the user has 10 workers of 1 TH/s each

in order for tProxy to be launched correctly, min_individual_miner_hashrate must be set with 1 TH/s

but this UI induces the user to set 10 TH/s

so for every bitaxe they connect, the dashboard will initially show as 10 TH/s (which is wrong), and then gradually converge to 1 TH/s

---

scenario B

user has 3 workers of different hashrates:

• 500 GH/s
• 5 TH/s
• 100 TH/s

in order for tProxy to be launched correctly, min_individual_miner_hashrate must be set with 500 GH/s

but the current UI induces the user to set 105.5 TH/s

so for every worker they connect, the dashboard will initially show as 105.5 TH/s (which is wrong), and they gradually converge to the correct hashrates (at different speeds, the biggest the difference, the slower it will be)

[plebhash]

in response to the comments above, @GitGab19 said:

I think this also depends on the channel aggregation.

Currently the UI configures tProxy in NON aggregated mode, so it opens 1 channel per Sv1 client connected. So in the current scenario you're correct, and we should ask users to insert the lowest hashrate device it's gonna be connected to the tool.

The other option we have is to change the UI to configure tProxy in aggregated mode, but this introduces other newer UX challanges, and I would do it later.

Still, even in the current NON aggregated mode, it's better to have the total amount of hashrate inserted by the user, than starting tProxy with the default value.

TLDR: I'm not sure we really need to change this page, but we should make it clear that it might make time to see the first share, while speeding up the vardiff updates as you stated in stratum-mining/sv2-apps#396 (comment)

[plebhash]

about @GitGab19 response above, I must confess I didn't fully understand everything... more specifically:

I think this also depends on the channel aggregation.
...
The other option we have is to change the UI to configure tProxy in aggregated mode, but this introduces other newer UX challanges, and I would do it later.

how/why would aggregated mode change the semantics of min_individual_miner_hashrate?

aggregated vs non-aggregated only changes how OpenExtendedMiningChannel.nominal_hashrate, which is not really relevant for the discussions here.

AFAIU we're trying to figure out how the UI can display accurate hashrate measurements of each individual Sv1 worker, and in that context, aggregated vs non-aggregated is irrelevant?

it's better to have the total amount of hashrate inserted by the user, than starting tProxy with the default value.

what default value are you referring to?

if you mean min_individual_miner_hashrate=10_000_000_000_000.0, I def agree with you, because it wouldn't make sense to assume everyone has 10TH/s workers

but also that's not really what I was proposing?

my proposal is that the UI should induce users to input the min individual worker hashrate, as opposed to total hashrate