This topic is intended to capture Subnet Management activities over time for the x33ed subnet, providing a place to ask questions and make observations about the management of this subnet.
DFINITY will submit an NNS proposal today to reduce the notarization delay on the SNS subnet, x33ed, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread ).
2 Likes
Voted to adopt proposal 133467 .
The summary and the payload containing the subnet_id and initial_notary_delay_millis value of 300 are correct. As this has been discussed here before, so moving from 1000 to 300 is safe for subnets with more than 13 nodes as well.
2 Likes
Voted to adopt proposal 133467. The proposal changes the notarization delay of the x33ed subnet (SNS subnet) from 1000ms to 300ms. Both summary and payload are correct.
2 Likes
Proposal 133467
Increases the block rate of the SNS subnet, setting the notorisation delay to 300ms, which is consistent with other recent config updates of this sort. The config payload is consistent with the proposal summary.
Looks good, I’ve voted to adopt.
1 Like
Voted to adopt proposal 133467. This proposal reduces the notarisation delay of subnet x33ed from 1000ms to 300ms, with the intention of improving network latency. The same change has already been made to most of the other subnets, with the reasoning behind it and the testing described here. Proposal payload matches and reasoning is sound.
Voted to adopt proposal 134176, as the reasoning is sound and the description matches the payload. This proposal replaces 5 healthy nodes, all of which appear as “Active” on the IC dashboard. The proposed change improves decentralisation with respect to node provider, data centre owner and country and brings the target topology parameters to within the requirements.
1 Like
Voted to adopt proposal #134176.
The proposal replaces 5 healthy Active status nodes in order to improve decentralization in regards to targets set for node_provider , data_center_owner and Country.
Given the fact that x33ed subnet is an `Application(SNS)’ type with 34 nodes it is a great change.
1 Like
Proposal 134176
TLDR: Awesome proposal! I’ll be adopting this. It brings the SNS subnet inline with the IC Target Topology, by reducing the max number of nodes per country from 5 to 3, and max number of nodes per node provider and owner from 2 to 1. Nice one @sat!
The max number of nodes per continent shoots up from 11 to 15, but continent isn’t a formal part of the IC Target Topology, so this seems like a sensible trade-off.
Motivation:
- replacing node xfozx-vhnrh-27riw-k6amn-pj4vh-t7qx3-bydxt-p6lv4-7ppyd-432fg-wae to optimize network topology
- replacing node tyv4e-thhn5-svu3d-jvx3v-2hajh-st6i3-ytdnx-waozw-hwxut-jxajr-mae to optimize network topology
- replacing node kq3sv-bziyq-im66o-5jrzn-6uexa-gyj3b-n7z2x-nvdqh-ffxhn-dfrh6-wqe to optimize network topology
- replacing node 6bp3h-ds5qd-6o7ae-6nmnu-brwpj-2c5iw-yjfnk-4drxh-vxa2o-qcchx-6qe to optimize network topology
- replacing node qkhl7-fonek-gpter-opkuq-eoypr-tsvtj-xw4r5-oe7hn-cuaev-6ggik-qae to optimize network topology
5 removed nodes replaced with nodes in Estonia, Slovenia, Sri Lanka, France and Romania.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 7985.507 km | 18505.029 km |
| PROPOSED | 0 km | 6980.364 km (-12.6%) | 18505.029 km |
This proposal slightly reduces decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical reduction in localised disaster resilience). 
Subnet characteristic counts →
| Continents | Countries | Data Centers | Owners | Node Providers | Node Operator | |
|---|---|---|---|---|---|---|
| EXISTING | 5 | 21 | 34 | 32 | 33 | 34 |
| PROPOSED | 5 | 25 (+16%) | 34 | 34 (+5.9%) | 34 (+2.9%) | 34 |
This proposal significantly improves decentralisation in terms of jurisdiction diversity, as well as diversity of node providers and owners 
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
| Continent | Country | Data Center | Owner | Node Provider | Node Operator | |
|---|---|---|---|---|---|---|
| EXISTING | 11 | 5 | 1 | 2 | 2 | 1 |
| PROPOSED | 15 (+36.36%) | 3 (-40%) | 1 | 1 (-50%) | 1 (-50%) | 1 |
  |
|
|
See here for acceptable limits → Motion 132136
The above subnet information is illustrated below, followed by a node reference table:
Map Description
- Red marker represents a removed node (transparent center for overlap visibility)
- Green marker represents an added node
- Blue marker represents an unchanged node
- Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)
- Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)
Table
Known Neurons to follow if you're too busy to keep on top of things like this
If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.
Another good neuron to follow is Synapse (follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
3 Likes
Voted to adopt proposal 134176. The proposal replaces two nodes from subnet x33ed:
Removed Nodes: xfozx, tyv4e, kq3sv, 6bp3h and qkhl7.
Added Nodes: yyjdt, jfryc, qpt6h, oobdg and r7few.
The proposal was verified using the DRE tool to verify the metrics stated. All nodes replaced are healthy but this replacements improve the network topology on the data_center_owner and country metrics.
Voted to adopt proposal 134287. The proposal seeks to remove a cordoned node from the subnet and specifies that the associated data centre is being offboarded “after 48 months”. Decentralisation parameters are arguably improved with respect to country (US 3 → 2 & AU 1 → 2). The necessary context is provided by this forum post and associated discussion. For future proposals of this type I recommend that the background context be included in the proposal text for ease of verification.
I’ve voted to reject proposal 134287. It makes claims that I see no clear way of verifying, and supporting statements regarding the ownership of the data centre are inconsistent with records held in the IC registry. The proposal was announced here.
Voted to adopt proposal 134287. This proposal is part of a sequence of steps to remove cordoned nodes from subnets as the associated data centeres are being offboarded after 48 months of their respective DC contracts that are still private and were signed up before the Genesis. There is a great and detailed explanation of this changes in this forum post and the forum thread it is in. In the wiki there is a series of Steps for Gen-1 Node onboarding after 48 months that need to be followed in order for the nodes to continue earning rewards which starts by making a forum post in the following thread. As we can verify no one as come forward with nodes from the DCs in this proposals so I don’t see any issues with the removal of this nodes.
1 Like
Voted to adopt proposal 134401.
This proposal replaces node yikms which appears in the dashboard as “Status: Active”, for the purpose of examining the stability of another node operator’s nodes. As shown in the proposal, community-approved decentralisation parameters are unchanged and remain within the requirements of the target topology.
Adopted the proposal, more info here
Proposal 134401
Vote: ADOPT
The proposal replaces one node from subnet x33ed:
Removed Node: yikms: Dashboard Status Active
Added Node: ct3c3: Dashboard Status Awaiting
The proposal was verified using the DRE tool to verify the metrics stated.
The nodes are not from the same NP which raises the question that hasn’t been addressed before, if it should be allowed to replace this node for the sake of gaining insights of another one as this affects the Node Provider remuneration. I would like to hear you opinions on this and will refrain from voting for now @ZackDS @timk11 @Lorimer.
Edited:
Thanks for the clarification @timk11 and @bjoernek. I expected as much since in the wiki it only refers mostly to geo localtion and gen of the nodes and other parameters other than them being in a subnet but wanted to clear any doubts. With this we also got this additional information that should be examined in this type of proposals since it affects the remuneration. Although unlikely to happen still requires a quick check.
Clearly the NP that is getting is node removed as some nodes active in some subnets meaning he isn’t affected by this change. My vote is to adopt.
1 Like
Thanks @LaCosta for raising this point. By my understanding, nodes that are unassigned still receive full rewards under the current system and the implementation of performance-based node rewards is an ongoing discussion as per this thread, yet to be implemented. The consensus seems to be that a node provider should continue to receive full rewards so long as their assigned nodes are working well, meaning that node providers shouldn’t be financially disadvantaged by these sorts of proposals. Please correct me if I’ve misunderstood anything.
2 Likes
This is correct.
This is a fair summary. The only point I would like to add:
- Every node provider should have at least one node assigned so that performance for assigned nodes can be evaluated.
- In case that all nodes from a node provider are unassigned then these nodes would be subject to a penalty of 80% (potentially with an exception for very small node providers with less than 4 nodes).
5 Likes
Thanks for highlighting this requirement @bjoernek.
@ZackDS raised an astute point regarding a similar proposal →
It seems like there’s an assumption that an NP’s nodes will all be correlated in terms of their performance (drawing insights from one about the others). Wouldn’t there be much greater correlation between nodes within the same DC and/or node operator? Presumably all DCs and node operators must also have at least one node assigned for the same reason?
1 Like