Hypothetical question: Let’s say I have 4 vnodes already up and running all behind one router on same local network with vnode1 pending in 37 epochs, vnode2 pending in 21 epochs, vnode3 pending in 18 epochs and vnode4 currently in committee for 1 more epoch. I am ready to stake a new vnode #5. I would like to as close as possible time the new vnode#5 such that it IS NOT IN COMMITTEE when any of the other vnodes are in committee to avoid a concentrated use of bandwidth while in committee from my local network via single router to internet. Given the additional 25 epochs to wait in the “wait finishsync” state prior to entering “pending” state, I am not sure of the best way to calculate when I should stake this next new vnode5. I simply intend to prevent as much as is possible one of my vnodes from being in committee at the same time as another of my vnodes to avoid concentrated use of bandwidth. Any suggestions on the best way to do this? Should I just wait, let’s say, 5 to 10 epochs after last node completes committee process (and earns)–then start the staking of the new vnode?
The Timing of Staking a new Vnode?
Not sure if I understand correctly. But you cannot time your nodes because of the build-in randomness in the selection. You’re going to get slippage between them because the number of epochs pending will not be the same. For instance, right now I have two nodes that were in committee at the same time. The one in shard 2 got 53 epochs pending and one in shard 5 got 55 epochs.
If it is just for the first full sync? What you can do is copy node data from one node to the other or download the bootstrap found on this forum.
https://we.incognito.org/t/node-operator-bootstrapping-introduction-guide/14239
@fredlee I understand that I cannot time exactly because more nodes are entering or leaving the network and this changes the number of pending epochs as you indicated. I was just wondering if even with that randomness there was a rough rule of thumb regarding how to keep nodes earning at separate times most of the time at least. You are probably right, eventually some of my nodes will be in committee at same time, but presumably I could still reduce the number of times this happens (maybe). I will bootstrap my next node, but that isn’t going the change the ~25 epoch in “wait finishsync”+ 50-55 (assuming no steep increases in the number of network additional nodes starting up) epoch wait in “pending”.
If your only concern is data usage and throughput on your router then you should fine now that Staking Flow was implemented and the amount of data needed to download is now very low.
You could time your node by planning out how many epoches the new node will wait and calculating where your other nodes are in the selection process. However, as @fredlee mentioned randomness will end up changing this no matter what.