TESTFRAME

[Hal Murray]

esr at thyrsus.com said:
> It would certainly simplify some ugly code if we knew that kernel receive
> timestamps are both standardized and actually implemented all across our
> target range. 

There are socket options SO_TIMESTAMP, SO_TIMESTAMPNS, SO_TIMESTAMPING and 
SCM_ variants.  They add a time stamp to the recv path.  I haven't tracked 
down the details.  Google found a kernel doc page with some info.

Google found one comment about it not being POSIX.  It is available on Linux, 
FreeBSD, and NetBSD.  (Or at least it's in /usr/include/.  I haven't actually 
verified that it works.  Things may be different on older (or newer) versions 
than the boxes I checked.  YMMV...)

There is also SO_BINTIME.  It's defined on FreeBSD but not Linux or NetBSD.
  http://lists.ntp.org/pipermail/hackers/2007-October/003321.html
Looks like a candidate for cleanup.

There is a comment in pylib/configure.py where it doesn't set 
ENABLE_SIGNALED_IO
so I think any of my comments about using a signal to get the time stamp are 
bogus and/or way out of date.  ntp_io has a paragraph describing grabbing 
info from a SIGIO handler.  It's in a if defined(SYS_WINNT)

There is also a USE_PACKET_TIMESTAMP.  It's set in ntp_io.c if one of 3 ways 
to get time stamps is defined.

----------

> Sounds simple, yes? Actually, no.  One headachy detail is that the simulated
> select has to interrupt correctly in the presence of simulated timer
> signals. And the timers themselves have to be emulated.

I was wrong on thinking the big select used a timeout.  There is a timer and 
a signal handler that sets a flag...  The main loop checks that flag.

I think you can intercept that by recording an event when the main loop 
notices the flag and then on replay, when the select finds that line, the 
replay logic can set the flag and return EINTR or whatever.

-- 
These are my opinions.  I hate spam.