Since there might be some lingering subtle misconceptions…
Computer clocks always drift, but it shouldn’t be by very much. If your computer were on 24h 7d, ntp clock adjustments should be humanly undetectable. (ntp questions: slewing versus jumping the time - Stack Overflow – “ntp doesn’t want to jump your clock, because discontinuous time jumps are Bad. It wants to adjust your clock gradually – very gradually. It’s very conservative: by default, it won’t slew your clock by more than xx parts per million (ppm).”)
But I’ve observed in Linux that, if the computer is asleep for several hours, then, a few minutes after waking, the clock may jump by a few hundred ms.
Both sclang and scsynth are running loops independently to update their timebase from the system clock, every 20 seconds. These loops are not guaranteed to be synchronized.
So the sequence in #5353 is:
- Wake from sleep. Local system clock has drifted by a noticeable amount.
- You launch SC and boot the server, and start playing stuff. sclang and scsynth have determined their timebase according to the (wrong) local time.
- A few minutes later, NTP says “whooooaaaa, that’s way off” and jumps the clock instead of slewing.
- sclang and scsynth pick up this change at different times because the
syncOSCOffsetWithTimeOfDay() loops aren’t (and can’t be) synchronized. This means there is a short period where sclang and scsynth disagree what time it is. This is when you can get late messages.
If you start SC after NTP jumped the clock, then you shouldn’t see the issue at all. But it isn’t always feasible in a live situation to say “I need to wait xx minutes for the system clock to sync up.”
Disabling ntp in startup.scd should prevent the above step 3.
Think about the mechanism here… SC sends a message now with a timestamp to say “do the thing at xx time.” The server receives the message, and it’s either early enough that the message could execute on time, or it isn’t. That is, the only way to know if it’s late is to send the message. Also, scsynth needs to execute the messages it receives. Suppose, for example, a Group-new message
/g_new is received late, and there were some hypothetical switch to disable the evaluation of late messages. Now, every future message depending on that group will fail. So you don’t want the server to discard late messages.
As noted above, we can’t always assume that sclang and scsynth agree on system time. Again, because of ntp’s slewing algorithm, normally disagreement should be extremely small, but wake-from-sleep disrupts that. So there is no 100% reliable way for sclang to predict lateness.
Does it have to be the SC machine that is reporting the correct time? Could be a phone, syncing to the mobile data network. (FWIW, “went over by 15 minutes”… with NTP, we’re talking about fractions of a second. If you’re relying on the computer to tell you when to end your set and your computer clock is 15 minutes off, this… isn’t an NTP issue.)