zlacker

[parent] [thread] 2 comments
1. nonran+(OP)[view] [source] 2025-01-13 08:49:05
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...

replies(1): >>mkl+ih
2. mkl+ih[view] [source] 2025-01-13 11:46:05
>>nonran+(OP)
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
ntpdate -q doesn't seem very consistent to me, even pointing it at a nearby server.

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);
      }
  }
Note that the sleep and second gettimeofday call take a little time (between 70 and 300 μs for me, but it depends what else is running), so the tick times reported won't be exactly on the second.
replies(1): >>nonran+VU3
◧◩
3. nonran+VU3[view] [source] [discussion] 2025-01-14 12:32:00
>>mkl+ih
Great detailed answer. I upvoted you.
[go to top]