Subnet Management - General Discussion

Governance NNS proposal discussions
, ,
21

Answered in the other thread Subnet Management - o3ow2 (Application) - #6 by sat

1 Like
22

Thanks @sat . That’s very helpful documentation indeed. Lots to think about there, and I think I finally got my head around the Nakomoto coefficient! One particular question - Should it be coded in that if a node replacement option would worsen one of the parameters, such as giving an existing node provider a second node in a subnet, then that option should be discarded? Or would this go against other principles involved in this process?

1 Like
23

@timk11 in some cases, such as when replacing unhealthy nodes, we may need to reduce decentralization. But if there is no other choice … then we need to do it.

2 Likes
24

New ‘Change Subnet Membership’ proposals have been raised:

  • uzr34 (currently unclear why certain unassigned nodes haven’t been used)
  • pzp6e (looks good, adopted :+1:)
  • tdb26 (looks good, adopted :+1:)
  • 5kdm2 (looks good, adopted :+1:)
  • mpubz (looks good, adopted :+1:)

@Sat, can I ask what’s stopping you from announcing these proposals on the forum and providing a link in the proposal summary to the forum discussion? I’m aware this will become a formal requirement in September (NNS proposal discussions - Governance / NNS proposal discussions - Internet Computer Developer Forum (dfinity.org)), but it seems like something that would be easy enough to start doing now wouldn’t it?

Most voters currently won’t know where to look when they see one of these proposals in the NNS dapp. Do you have any objections to providing a link to the forum?

3 Likes
25

New ‘Change Subnet Membership’ proposals have been raised:

  • uzr34 looks great, brings this subnet inline with IC target topology limits - adopted :+1:
  • tdb26 looks great, brings this subnet closer to IC target topology limits - adopted :+1:
2 Likes
26

There are 5 new subnet config update proposals that have been raised.

These are the same subnet config update that was applied to the canary subnet last week, which has held a steady and impressive block rate since. More context is available here → Reducing End to End latencies on the Internet Computer

@dsharifi, I expect there’s not a reason to be concerned, but I prefer to ask than to assume. My main thought when I was reviewing the metrics on each of these subnets is that they have very different tx/s and finalisation rate profiles to the canary subnet that this config update has so fair been trailed on. This makes we wonder how representative the results on the canary subnet can be considered. Is there a rush to roll this update out (why roll out to 5 very different subnets in one fell swoop)?

27

The metrics for the canary subnet look very good, and we are confident with rolling out the changes to a new batch of subnets with varying amounts of load. We chose to group subnets in batches with different amounts of load to get a more diverse set of metrics from production on how the subnets behave in production. If there were any regressions, we will discover it much earlier by rolling out to a diverse set of subnets. This is why you correctly found the subnet 6pbhf with many more TX/s than fuqsr both being updated at the same time.

1 Like
28

Thanks @dsharifi, I’m glad to see all 5 of those subnets doing well post-update.

While I voted to adopt the first 3 subnets listed above, I voted to reject the last two (the two that were least similar to the canary subnet, with significantly more load and canisters).

My main reason for rejecting was that there was no commentary on these specific proposals from DFINITY (as far as I could see). Only the original announcement, which didn’t relate to any specific proposal, and which didn’t provide any information about the strategy for how this would be rolled out and the testing that’s been performed to inform that strategy (and/or each specific proposal). It’s very difficult (or impossible) to cast an informed vote without information like this. While this sort of information cannot be directly verified, it can be used to cross-reference with other sources of information to gain confidence that everything adds up and seems reasonable.

I had numerous questions about these sorts of details, but didn’t receive an answer until after DFINITY had already voted and the proposal outcomes had been decided.

Would you consider making a few adjustments for the next batch of config updates?

  • Please consider providing a reason for why a particular subnet has been chosen for the config deployment (instead of the numerous other subnets that could have been chosen). It would be great if this could also include some details regarding the testing that’s been conducted to inform this decision, and/or the metrics that have been gathered. Without this information you’re asking voters to cast an uninformed vote.

  • Please consider declaring the subnet that the proposal relates to in the proposal title (much like the two ‘Change Subnet Membership’ proposals below. Hopefully you can see the difference this makes in navigating the proposals effectively :slight_smile:

    image
    image769×405 29.7 KB

  • Please consider linking to forum discussion for that particular subnet and/or proposal. (e.g. fuqsr). ‘Change Subnet Membership’ proposals have started doing this recently. Note that the formal URL field doesn’t show up on mobile devices when viewing the proposal in the NNS dapp. The more contextual info / references that can be provided in the proposal summary the better :slight_smile:

  • Please keep doing the fantastic work that you and the rest of the team are doing to make the IC better and better :rocket: These performance improvements are very exciting!

1 Like
29

Hi @Lorimer

I appreciate the thorough feedback! We’ll keep it in mind for the upcoming proposals to update more subnets.

As I mentioned in another thread, we are proposing a gradual rollout of the notarization delay changes, using batches of subnets with varying amounts of load. This is why you correctly observed that subnet 6pbhf with a higher load profile than the canary subnet was proposed by us to be updated.

We have done extensive performance tests with testnets to verify that all these subnets can handle the change, where we have simulated high loads, packet loss between nodes, faulty nodes, etc.

1 Like
30

Thank you @dsharifi :blush:

I suspect my question over here may come across as niave, but I’m still somewhat confused by those metrics. Would you be able to comment when you get a chance?

31

Latest notorisation delay proposal →

32

New proposal for the signing key subnet → Subnet Management - pzp6e (Fiduciary) - Governance / NNS proposal discussions - Internet Computer Developer Forum (dfinity.org)

33 
// In general, the round limit should be close to
// `message_limit + 2B * (1 / finalization_rate)` which ensures that
// 1) execution does not slow down finalization.
// 2) execution does not waste the time available per round.
const MAX_INSTRUCTIONS_PER_ROUND: NumInstructions = NumInstructions::new(7 * B);

@Manu, @dsharifi does MAX_INSTRUCTIONS_PER_ROUND need revisiting now that the finalisation rate is being significantly increased on more and more subnets? I’m sure this has already been considered. It would be interesting to hear some commentary :slight_smile: Thanks :pray: