Skip to content
This repository has been archived by the owner on Feb 3, 2023. It is now read-only.

Sim2h - RRDHT "R-Value" Stub Calculation #1798

Merged
merged 9 commits into from Oct 31, 2019
Merged

Sim2h - RRDHT "R-Value" Stub Calculation #1798

merged 9 commits into from Oct 31, 2019

Conversation

neonphog
Copy link
Contributor

@neonphog neonphog commented Oct 23, 2019

PR summary

Adds rrdht "R-Value" calculation for storage arc radius to sim2h in a stub manner

  • the calculation is performed, but just gives a warning if the recommended radius < ARC_RADIUS_MAX
  • we have no uptime data for clients, so uptime is assumed to be 1/2 in all cases

testing/benchmarking notes

( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )

followups

( any new tickets/concerns that were discovered or created during this work but aren't in scope for review here )

changelog

Please check one of the following, relating to the CHANGELOG-UNRELEASED.md

  • this is a code change that effects some consumer (e.g. zome developers) of holochain core so it is added to the CHANGELOG-UNRELEASED.md (linked above), with the format - summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)
  • this is not a code change, or doesn't effect anyone outside holochain core development

@neonphog neonphog added the WIP work in progress label Oct 23, 2019
@neonphog neonphog changed the title WIP: Sim2h RRDHT Sim2h - RRDHT "R-Value" Stub Calculation Oct 29, 2019
@neonphog neonphog added NEEDS REVIEW This PR requires peer code review and removed WIP work in progress labels Oct 29, 2019
@neonphog neonphog marked this pull request as ready for review October 29, 2019 21:02
Copy link
Collaborator

@lucksus lucksus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see this coming together!
I do think though the r-value should be per space, no?

num_ticks: u32,
num_ticks: u64,
/// sim2h currently uses the same radius for all connections
rrdht_arc_radius: u32,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think this is the wrong place for this variable to be. The sim2h server can server many spaces, and each space will have a different aggregated arc radius, no?

for (_k, c_state) in self.connection_states.read().iter() {
match c_state {
ConnectionState::Limbo(_) => (),
ConnectionState::Joined(_, _, dht_data) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we are neglecting the space that agent is in and assuming all agents to be in the space, right? I think we should calculate r-values per space.

Copy link
Member

@zippy zippy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think lucksus is right. Also, we probably what to do something other than recalc every 20seconds i.e. rather much less recalc after significant changes, but that's fine for a followup. Maybe just change to a function should_recalc() to encapsulate the semantics?

@neonphog neonphog removed the NEEDS REVIEW This PR requires peer code review label Oct 30, 2019
@neonphog neonphog requested a review from lucksus October 30, 2019 20:54
Copy link
Collaborator

@lucksus lucksus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, looks good!
I wonder if we should add tests on this level too (=unit testing sim2h) as this code does not result in a change of behavior and thus can't be picked up by our current set of tests. But totally ok to merge this as it is and add tests with the next PR that actually applies the sharding.

Note that we most likely won't see any effect of that in our current app-spec as we only have up to 3 nodes there. The new stress tests can be run with any N, but for performance and cost reasons, CI is set to 10. So in order to test rrDHT sharding I think it would be good to cover a good part of it with unit tests here - and then also add specific stress tests where the number of nodes and the target R-value are set in a way that the sharding code actually gets hit.

@neonphog neonphog merged commit b94b0ed into develop Oct 31, 2019
@neonphog neonphog deleted the sim2h-rrdht branch October 31, 2019 16:02
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants