[Beowulf] IEEE 1588 (PTP) - a better cluster clock?

[Andrew Shewmaker]

On 7/25/07, Patrick Ohly <patrick.ohly at intel.com> wrote:

> Thanks for pointing that out. In general BTime looks similar in spirit
> to PTP; let me point out similarities and differences below.

I thought so too.

> PTPd at some point also had a kernel patch to obtain time stamps for
> packets, but replaced that with the SO_TIMESTAMP + loop back device
> mechanism to simplify the installation.

I noticed that in PTPd's docs, but it sounds to me like it's patch is for a
different purpose.  The btime_info module searches for the following
kernel symbols and exports the assocated data via /proc

    "time_state", "tickadj", "time_offset", "time_next_adjust",
"time_adjust", "time_adj",
    "time_freq", "pps_freq", "tick_nsec", "wall_jiffies",
"xtime_lock", "getnstimeofday"

Here's a comment from btime.c explaining what Josip is doing with those
values:

Kernel second_overflow() peels a portion of pending offset and computes
adjustments to be applied at each tick over the next second.  However, this
is done by shifting the pending offset by SHIFT_HZ, which isn't exact because
2^SHIFT_HZ != HZ (usually).  Moreover, adjustments are (currently) applied
in such a way that 2^10 approximates NSEC_PER_USEC.  Although
some compensation is applied in typical cases (HZ=100 or 250 or 1000), this
isn't exact either. Therefore, the actual clock offset change will be
different than
what's given to normal adjtimex(), and the offset reported by normal adjtimex()
will be similarly affected.

Accurate microseconds are reported by adjtimex() only when BTIME_INFO is
requested and/or singleshot mode is used.  Normal frequencies and offsets
must undergo corrections as done below, because BTime is a lot more sensitive
to such details than NTP.

The correction factors here reverse the ones in btime_stamp_get() which starts
with raw kernel variables. This function takes true offsets and drifts
and adjusts
raw kernel variables.

> > BTW, BTime adaptively estimates the probability of receiving timestamps without
> > extra delays; but it currently requires a fixed timing noise estimate.
>
> Is this something that has to be specified when installing/starting
> BTime?

It is hard coded in BTime.  I'll point Josip to the paper, and hopefully he'll
have time to join this discussion directly.

-- 
Andrew Shewmaker