Subnet Management - ejbmu (Application)

This topic is intended to capture Subnet Management activities over time for the ejbmu subnet, providing a place to ask questions and make observations about the management of this subnet.

At the time of creating this topic the current subnet configuration is as follows:

Expand
{
  "version": 44951,
  "records": [
    {
      "key": "subnet_record_ejbmu-grnam-gk6ol-6irwa-htwoj-7ihfl-goimw-hlnvh-abms4-47v2e-zqe",
      "version": 44951,
      "value": {
        "membership": [
          "cekdc-hmzri-3u3or-ei7ip-su7ck-3xt6e-zsse2-tgakq-rolmv-6crkh-hqe",
          "bhrbv-chf2l-tjjcj-mqryf-7z7ww-z6xi3-su7hl-idbfo-nnfpu-u6aju-nae",
          "xhha5-oe4lp-ij2xv-gqhfe-pjavc-lwazu-y2wcm-rsvqw-hpvso-ksn7c-fqe",
          "llwjk-sgobf-vxycz-muu34-oyozz-lkxak-pzc67-ek4pt-kqmfh-b2b6k-3qe",
          "7ucvx-t6mxf-viej7-ils7i-k3aco-tqzsg-6cy3o-cakgs-zifaj-kiduk-cae",
          "b3ml3-v62hu-gdyb5-2raax-b33g2-nav6y-i5d3n-carmz-tosee-rbhk3-lqe",
          "5w4eg-mb4ih-bwfmd-332ta-krtlf-y5igk-r3lzd-l3bze-34553-3opqh-mae",
          "aae7j-zvepi-ypdnp-4a6fg-durhx-37r2u-d4e5u-z67va-dsen2-rnusw-pqe",
          "oxa4d-pajkk-n7fto-dyfxr-z34x3-7zebw-zdqbq-qxzxp-qg7vk-nhcnx-fae",
          "in4qi-poj7g-j5gvw-34xys-4cf6k-uki3d-exjzf-th4cu-c5my6-sdht2-cae",
          "kmez2-lipof-3kjdn-nt35r-ai7oy-gvxxb-5hkv4-lk5ci-vtjya-hpd6w-wqe",
          "t3d5h-mcdqm-lt7jk-b7nk2-nkxfi-dl4ew-pn776-olxjd-eyott-3hpjb-iae",
          "bayvy-p36kq-krz3d-o5lay-rxx3w-h35pc-235tv-mmhfe-b674r-xwfnq-mae"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 2097152,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 1000,
        "initial_notary_delay_millis": 600,
        "replica_version_id": "b0ade55f7e8999e2842fe3f49df163ba224b71a2",
        "dkg_interval_length": 499,
        "start_as_nns": false,
        "subnet_type": "verified_application",
        "features": {
          "canister_sandboxing": false,
          "http_requests": true,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [],
        "ssh_backup_access": [],
        "ecdsa_config": null,
        "chain_key_config": null
      }
    }
  ]
}

Proposal 132217

This proposal sets the notarisation delay of the subnet to 300ms, down from 600ms. The change will increase the block rate of the subnet, aimed to reduce latency of update calls.

This is 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

Here are the current metrics for this subnet. A question I’ll be asking on the Subnet Management General thread (see reference below this post) is why this update is being rolled out to so many subnets at once, each with different finalisation rate and transaction profiles (e.g. peaks and troughs, whereas the canary subnet was always steady, even prior to the update). I’m wondering if this limits the representativeness of the results on that canary subnet.

DFINITY will submit a proposal today to reduce the notarization delay on the subnet, ejbmu , similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread ).

Thanks @dsharifi. Was this post intended for another subnet? (the notarisation delay has already been recently updated on ejbmu)


Update: I’ve reviewed the subnet metrics, re-reviewed the prior proposal, and also confirmed the current config of the subnet using IC-Admin. Having confirmed that this subnet already has a notarization delay of 300ms I’ve rejected the proposal (not that it would matter if this executed). As you would expect, and as pointed out by @Sat in the WaterNeuron DAO, these operations are idempotent :slight_smile:

Thanks for spotting this @Lorimer. As you point out, this proposal is an error as it already has a 300ms notarisation deal. You can vote to reject it.

1 Like