3

From what I understand it is the probability that a milestone is selected as a tip?

If this value was a bit higher, would it make the nodes sync faster?

Here are the places in code which I mean:

    conf.put(DefaultConfSettings.P_SEND_MILESTONE.name(), "0.02");

L95 &

private Hash getRandomTipPointer() throws Exception {
        Hash tip = rnd.nextDouble() < P_SEND_MILESTONE? milestone.latestMilestone: tipsViewModel.getRandomSolidTipHash();
        return tip == null ? Hash.NULL_HASH: tip;
    }

L450 Source

This relates to the development of Nelson. I am trying to find out whether relatively frequent peer switching could lead to milestone lags.

Here is an idea, which might explain some lagging behind the latest milestone:

Since the milestones are sent randomly in less than 2% of all cases, it might take time for a node to send/receive a milestone. When running Nelson, certain time is lost to connect/disconnect peers, which maybe decreases a little the probability to receive a milestone.

Now, what if this IRI config value was changed when running Nelson to 0.05, for example, instead of 0.02? The Nelson nodes would reference the milestone more often and get in sync faster?

Is it worth trying?

3

What does P_SEND_MILESTONE config do?

P_SEND_MILESTONE is used when a neighbor requests a random tip L420, w.h.p a random tip will be sent back, but in a small probability a milestone will be sent as a response. this was added to support older IRI versions while syncing IIRC.

However, milestones are propagated in two main ways (P_SEND_MILESTONE being a third & minor way):

  1. TipRequesterThread - which broadcasts the latest milestone to all neighbors every 5 seconds.
  2. processReceivedData - like any new transaction, when received, it is broadcast to all the neighbors.

This relates to the development of Nelson. I am trying to find out whether relatively frequent peer switching could lead to milestone lags.

If this value was a bit higher, would it make the nodes sync faster? no, as milestones are re-sent every 5 sec.

to clarify, do you mean that the latestMilestone is lagging, or the latestSolidSubtangleMilestone?

if the former, then yes, this might help. but this is a rare event on normal nodes & should be investigated if so.

if the latter, then no, fast propagation of milestones doesn't promise that a subtangle would be solid - that is an issue related to fetching all the missing transactions which are referenced by a milestone, or could be an issue in recognizing that this has happen.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.