Is system clock in sync (NTP)?

[plgauthier]

s.isSystemClockSynced == true?

I’m wondering how could SC know if the system clock is or is not in sync.

The linux command timedatectl show -p NTPSynchronized
returns NTPSynchronized=yes

How could I retrieve that (yes|no) in some boolean in SC ?

Also :
The linux command ntpstat returns 0 if clock is synchronised. *ntpstat* returns 1 if clock is not synchronised. (but I do not run ntpd and would much prefer stay with systemd options)

Context : Raspberry Pi have no RTCs. I have the routine (as in habit) to sync it with local wifi in regular venues or just cellphone data sharing otherwise… But last show, head buried in code (and performance), I forgot to sync and went over by 15 minutes on my setlist. Unacceptable.

[plgauthier]

Is this the best I can do ?

Pipe(“timedatectl show -p NTPSynchronized”, “r”).getLine.findRegexpAt(“y|(?:)”, 16)[1].asBoolean;

inb4: .close I know.

or even :

Pipe(“timedatectl show -p NTPSynchronized”, “r”).getLine == “NTPSynchronized=yes”;

[jamshark70]

See also Linux timing instability · Issue #5353 · supercollider/supercollider · GitHub – ntp can cause timing glitches, at least in Linux. For this reason, I’ve just added a block of code to my startup.scd to disable ntp while running SC.

hjh

[plgauthier]

Wow, #5353 looks like a nightmare. I do get late warnings from time to time resulting in a bunch of synths all at once. (Btw, is there a way to tell SC not to play events if late by x seconds?) But never more than a very disgraceful sounding glitch getting back to normal after. I guess if my confidence ever gets broken I’ll disable NTP at SC boot like your code suggest. But I do need to know the “correct” time. I could then just Sync NTP, then disable it. Thank you @jamshark70 for this sound warning.

[jamshark70]

@plgauthier

Wow, #5353 looks like a nightmare.

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:

1. Wake from sleep. Local system clock has drifted by a noticeable amount.
2. You launch SC and boot the server, and start playing stuff. sclang and scsynth have determined their timebase according to the (wrong) local time.
3. A few minutes later, NTP says “whooooaaaa, that’s way off” and jumps the clock instead of slewing.
4. 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.

@plgauthier

Btw, is there a way to tell SC not to play events if late by x seconds?

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.

@plgauthier

But I do need to know the “correct” time.

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.)

hjh

[Spacechild1]

@jamshark70

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.

Small, but important correction: scsynth only uses a resync thread in its CoreAudio backend; the portaudio and jack backend sample the current NTP time in every audio callback and feed it into a time DLL filter. Now, if there is a sudden jump in time, the resync thread will simply correct the time the next time it runs, but the time DLL filter just gets confused and may take a long time to recover. (I think the portaudio and jack backends could/should check for unreasonable time deltas and reset the DLL accordingly.)