You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Transiter scheduler makes an attempt to spread out feed updates for the same system. The current approach is to add a random delay between 0 and 5 seconds because the first update for a feed. After that, feed updates happen every 5 seconds exactly. On average this results in feed updates for the same system being spread out/offset from one another.
I think we can do better though. Instead of starting randomly, we could just spread the feed update start times out uniformly. E.g., if the system has 4 realtime feeds we start the first feed at 0s, the second feed at 1.25s, the third one at 2.5s, and so on. In general if the system has N realtime feeds, we start the i th feed at (period) * i/N.
The even more advanced version of this would be to factor in how long each feed update takes. I.e., for the NYC subway the 123456 takes 400ms during the day but the G feed takes only 100ms. So we should assign a wider interval for the 123456. But this may be hard to do in practice.
Thought of this while reviewing #110, in particular the part around racing updates
The text was updated successfully, but these errors were encountered:
The Transiter scheduler makes an attempt to spread out feed updates for the same system. The current approach is to add a random delay between 0 and 5 seconds because the first update for a feed. After that, feed updates happen every 5 seconds exactly. On average this results in feed updates for the same system being spread out/offset from one another.
I think we can do better though. Instead of starting randomly, we could just spread the feed update start times out uniformly. E.g., if the system has 4 realtime feeds we start the first feed at 0s, the second feed at 1.25s, the third one at 2.5s, and so on. In general if the system has N realtime feeds, we start the i th feed at (period) * i/N.
The even more advanced version of this would be to factor in how long each feed update takes. I.e., for the NYC subway the 123456 takes 400ms during the day but the G feed takes only 100ms. So we should assign a wider interval for the 123456. But this may be hard to do in practice.
Thought of this while reviewing #110, in particular the part around racing updates
The text was updated successfully, but these errors were encountered: