1/10/2025 at 8:27:29 AM
Nice descriptive article. I've done this on purpose too to debug remote filesystem syncs and cryptography problems where machines are out of sync. My GPS wall clock is handy for adjusting NTP, but the time it takes to scan my eyes from the wall back to the monitor.. you really do need two stacked like she did. So I now figured to use transparrent terminals each logged into a different host and lay them over one another running "watch -n1 date".Would have been nice to have some more network, code and command line examples. You need to set up a local ntpd and need to point your local master at that temporarily. A better utility to write would be "timediff -s1 -s2" that takes two time servers and shows the offset. I bet there's a way to do that in one line. Anyone?
by nonrandomstring
1/12/2025 at 10:01:05 PM
> watch -n1 dateUm, that's a pretty inaccurate way to notice an offset in the millisecond range, isn't it?
by fishstock25
1/12/2025 at 11:30:34 PM
That doesn't even show ms. Add something like +%s%N (ns) to the options if you want finer resolution.by nonrandomstring
1/13/2025 at 1:11:42 AM
The problem is using watch you have no control* over when in each second it's getting the time, so it could be nearly a second late (e.g. it's getting the time once per second, but happens to be doing it when it's a few milliseconds away from ticking over to the next second).* Okay, you have a little control in that you can press enter, or otherwise set it running, at a particular moment.
by mkl
1/13/2025 at 6:01:51 AM
So don't have any delay: while true; do date +%s%N; doneby Izkata
1/13/2025 at 7:43:21 AM
There's still a delay with that, as date takes time to run. You need a program that gets the current time, waits an appropriate amount, prints, and repeats. It'll still be slightly off unless you can measure the printing and flow control accurately.I have a program I use in shell scripting called sleepuntil that does something like this, but it doesn't try to be millisecond-accurate.
by mkl
1/13/2025 at 8:49:05 AM
The problem that I noticed is if you open two terms on different hosts (say by ssh) and run watch commands then, regardless of resolution, they'll be out of sync. There's no hard tick event common to both kernels. And as someone already said, you introduce sampling effects.So I figured you need a time "diff", a single command that updates from both timeservers and then presents the offset in a single operation. So (I just researched this again and) there's three answers here [0], using ntpdate and something I've never seen before called clockdiff.
[0] https://stackoverflow.com/questions/2296981/how-can-i-work-o...
by nonrandomstring
1/13/2025 at 11:46:05 AM
Right, as I said, watch is the wrong tool here. The event in common is the synchronised clocks, or an NTP server.To see the NTP offsets of a machine you can run something like:
ntpq -pn
To see the clocks ticking visually you can do something like the following and run it on each machine (assuming they have the same ping).
#include <time.h>
#include <sys/time.h>
#include <stdio.h>
void main() {
struct timeval tv;
struct timespec ts;
ts.tv_sec = 0;
while(1) {
gettimeofday(&tv, NULL);
ts.tv_nsec = 1000000000 - 1000*tv.tv_usec; //number of nanoseconds left in the current second
nanosleep(&ts, &ts);
gettimeofday(&tv, NULL);
printf("%lu.%06lu\n", (unsigned long) tv.tv_sec, (unsigned long) tv.tv_usec);
}
}
by mkl
1/14/2025 at 12:32:00 PM
Great detailed answer. I upvoted you.by nonrandomstring