bee icon indicating copy to clipboard operation
bee copied to clipboard

Delay in First SOC Upload After Node Startup

Open nugaon opened this issue 1 year ago • 1 comments

Context

  • Bee version: 2.2

Summary

After starting the node, the first Single Owner Chunk (SOC) upload takes an unusually long time. It appears that there might be a lock causing this delay, particularly around a specific debug log entry.

Expected behavior

The SOC upload should occur promptly after the node starts without significant delays.

Actual behavior

The first SOC upload after node startup is delayed significantly. The suspected cause is a lock around the following log entry:

"time"="2024-10-10 14:54:36.734229" "level"="debug" "logger"="node/salud" "msg"="computed" "avg_dur"=0.001058165 "pDur"=0.001001986 "pConns"=1 "network_radius"=0 "neighborhood_radius"=0 "batch_commitment"=191889408

Steps to reproduce

  1. Start the node with the usual configuration.
  2. Attempt to upload a SOC immediately after the node becomes operational.
  3. Observe the delay in the upload and check the node's log for the debug entry mentioned above.

Possible solution

Investigate the locking mechanism around the log entry point to determine if it is necessary or if it can be optimized to allow faster processing. This might involve reviewing the synchronization strategy around the shared resources involved in the SOC upload process.

nugaon avatar Oct 11 '24 10:10 nugaon

Can you provide the config you start the node with? Also how much delay are you experiencing? This might be related to your warmup time

acha-bill avatar Oct 15 '24 11:10 acha-bill

Empirically speaking, it seems that SOC download is also disabled during the first 5 minutes (warmup period).

Cafe137 avatar Oct 25 '24 08:10 Cafe137

N.B The network radius is required to push out chunks.

The radius is recalculated at a fixed interval of 5 minutes, with each recalculation depending on the node’s active peer connections. Without connected peers, the radius calculation is postponed.

The recalculation process is as follows:

sleep(warmupTime)

for {
  r = checkRadius()
  if r {
    setRadius (r)
  }
  sleep(5m)
}

If warmupTime is set to 0, checkRadius will execute immediately—likely before peering is fully established—resulting in an uncalculated radius. The function will then wait until the next 5-minute interval to reattempt radius calculation, at which point it can successfully compute the radius based on its connected peers.

Until the initial radius is set, all operations that require it will "wait," causing a delay in the first upload after node startup.

Setting warmupTime to approximately 10 seconds (or the minimum time needed for peering to establish) will address this issue.

acha-bill avatar Oct 30 '24 06:10 acha-bill