TdS uptime should be from the start of the stage

[mvines]

Currently uptime for a validator is just reported over the last epoch (I think!). Perhaps we report multiple uptimes: last epoch, last N epochs, from the start of the stage?

We probably need to discuss how the implementation of this looks like, and ideally it could be computed directly from a ledger too (for offline analysis)

[sbhargava]

@chris-remus and @mvines to work w/ @sunnygleason on open questions.

[sbhargava]

@sunnygleason did you get everything you need to do this?

[cfl0ws]

I opened #425 about defining uptime, per the 50% requirement in the TdS Participation Agreement. The definition probably requires input from @ericlwilliams and Dominic. We're coordinating that discussion in 5.1 of the FAQ.

[sunnygleason]

A couple (minor?) details I noticed:

• credits are significantly less in initial epochs, is this downtime-related or by design? (do we need to compensate for this?)
• I'm not seeing data for epoch #1

[sunnygleason]

(un-assigning myself -- if the solution is as easy as (1) compensating for scaling rewards in early epochs and (2) computing over all epochs, I can implement that anytime!)

[CriesofCarrots]

@sunnygleason , the slots_in_epoch values don't look right to me. Epochs double in length until they reach DEFAULT_SLOTS_PER_EPOCH (currently set to 8192 here https://github.com/solana-labs/solana/blob/51ac05b3cf7cc323dfde7351cdb9110fd4ff1361/sdk/src/clock.rs#L12), so the epochs we're looking at in that SS are likely slots_in_epoch: 2048, 1024, 512, 256, 128

Do slots_in_epoch come from the cluster for each epoch? Or is that a constant set somewhere?

[sunnygleason]

@CriesofCarrots great catch - I had forgotten about that!

What's the best way to proceed - update the RPC call to include slots_in_epoch?

[sunnygleason]

looking at this further - it appears that there is an EpochSchedule:

https://github.com/solana-labs/solana/blob/master/sdk/src/epoch_schedule.rs#L44

Would it be a good idea to expose this via RPC like getEpochSchedule()?

[mvines]

🎉 https://docs.solana.com/book/v/master/api-reference/jsonrpc-api#getleaderschedule

[CriesofCarrots]

I don't think that's quite what Sunny is looking for. @sunnygleason , we can get the EpochSchedule by getting the account data of the sysvar account, like we're doing here: https://github.com/solana-labs/solana/blob/7e6e7e8406318292b02591520fbe2cac7339090f/cli/src/vote.rs#L281 Of course, we'd need to implement the pattern to deserialize it.

Here's what the EpochSchedule looks like for edge.testnet.solana.com:

EpochSchedule { slots_per_epoch: 8192, leader_schedule_slot_offset: 8192, warmup: true, first_normal_epoch: 8, first_normal_slot: 8160 }

I assume you've figured out how to calculate the slots in the warmup epochs from that data...?

[sunnygleason]

this is live at http://edge.explorer.solana.com/tour-de-sol?force=true

Note: mouse over the uptime to see additional details - if you have inspiration for exposing the multiple uptime values, let me know!

[sunnygleason]

Uptime details view:

[cfl0ws]

@sunnygleason Can you please help me understand how the ranking is calculated? From what I can see above, the ranking appears to be based on Most Rewards Collected, if I'm interpreting the credits correctly.

If that's the case, we should probably change the name from "Top Validator Ranking" to "Most Rewards Collected, since that is one of the three quantitative rewards categories -

• Confirmation latency
• Most rewards collected
• Hightest availability

Also, interpreting the stats you posted above -

Is a question that is commonly asked by validators during the dry runs. We've added the explanation to the FAQ.