[LinuxPPS] Timestamps with LinuxPPS

[Bernhard Schiffner]

On Thursday, 18. March 2010 22:17:36 you wrote:
> On Thu, 2010-03-18 at 20:21 +0100, Bernhard Schiffner wrote:
> > On Thursday, 18. March 2010 19:05:10 john stultz wrote:
> > > On Thu, 2010-03-18 at 11:47 +0100, Bernhard Schiffner wrote:
> > > > almost a year ago was a little discussion in LinuxPPS about making
> > > > the /dev/pps* readable, returning a timestamp.
> > > > There was a patch (and still is) doing so but the thread stoped
> > > > because of other priorities.
> > > > (IIRC I sent you some private e-mail on this topic.)
> > > 
> > > So, not remembering here, what would this provide that clock_gettime()
> > > does not?
> > 
> > These timestamps are recorded when an interrupt is proceeded. The value
> > stays until the next event occurs,  clock_gettime() increases.
> 
> So these are timestamps on the system? Or a timestamp from the pps?
Example:
the CD line of a serial input changes its level,
an interrupt is (immediately) generated by the UART 16550,
the CPU registers this interrupt,
an ISR (interrupt service routine) is called
the ISR redirects to the serial driver,
inside the serial driver is a (by ldisk switchable) pice of code doing 
getnstimeofday().

This is one core functionality of LinuxPPS.
The other is providing this information to userspace as RFC 2783 requests.

There is code for use in drivers for /dev/ttyS, /dev/lpt. It's easily 
applicable to GPIO-pins of non-X86 CPU's.

 > Forgive my unfamiliarity here, since while I've been interested in what
> pps setups allow for, I've been unable to setup such a system myself
> from off the shelf parts without pulling out a soldering gun (as sadly,
> most gps units even with NMEA serial output don't provide the pps
> signal).
Use the right one ;-)

> So while I'm aware this stuff is being worked on, its only in the
> periphery of my attention, so I'm not familiar with the existing
> standards.
> 
> > ntpd (as the main pps consumer) adjusts clocks to fit such a timestamp to
> > the systems full second as close as possible.
> 
> So my understanding is that ntpd takes the pps signal generated by the
> interrupt via the pps driver, calls gettimeofday to timestamp the event,
> and then and feeds the offset back to the kernel through adjtimex.
Only a little bit wrong in detail.
The pps driver does the getnstimeofday(), ntpd processes this value.
The pps-code does its best to be as close as possible (measured by CPU-
instructions) to the ISR. Only this make the  necessary precision possible.
ntpd is userspace and later in the chain. 

Notabene:
PPS provides the timesstamp _only_. 
Date and time are provided by other means.
(In case of using a GPS-receiver  these are NMEA-data on the RxD pin of the 
serial port, passing the same serial driver but with an other codepath.)
 
> But I'm suspecting from your mail this is not quite right. More below.
> 
> > This is the most common use. But "irregular" events should be able to get
> > (and report!) timestamps too.
> 
> irregular events? Could you explain more about what those might be?
You are free to provide a signal to be timestamped everytime you want. 
PPS is intentionally every second and a subset thereof.

> 
> > > > A recent discussion showed that users want to have a "normal" read()
> > > > and something to use with select() in addition to the RFC2783
> > > > functionality.
> > > > 
> > > > http://ml.enneenne.com/pipermail/linuxpps/2010-March/003647.html
> > > > 
> > > > My question to you:
> > > > Do you know something how others (parts in the kernel, operating
> > > > systems ...) handle these problems?
> > > > (Format of timestamps, mechanisms to trigger select()  etc.)
> > > > 
> > > > Examples:
> > > > http://publib.boulder.ibm.com/infocenter/radhelp/v6r0m1/index.jsp?top
> > > > ic=/ com.ibm.etools.egl.doc/topics/reglasm0901.html doesn't mention
> > > > the ns-part (only -S / ms).
> > > > 
> > > > man date reveals the +%N format for nanoseconds
> > > > 
> > > > The recent patch adds the slope triggering the timestamp and a
> > > > counter for
> > > > 
> > > > each slope:
> > > >        assert 577917 1236209879.010016955
> > > >        
> > > >         clear 577917 1236209879.011017749
> > > 
> > > I'm not sure I'm following you from just the links above. I might need
> > > some additional context and background.
> > 
> > What do you think makes a timestamp a timestamp?
> > The answer LinuxPPS  implementing RFC2783 gives is:
> > 1.) an incremental number,
> > 2.) the slope,
> 
> Clarify what you mean by slope here?
In case of the serial driver an ISR is called everytime the CD-pin changes 
low->high and high->low.
PPS registers the slope.  ntpd's pps-driver has a configuration bit, which 
slope to use.
 
> > 3.) the reported time (with best available resolution, ns these days).
> > 
> > Rodolfo provides this by sysfs (linux-specific) already. Georges patch
> > intends to do the same with the character device  /dev/pps* (more
> > visible). But before you start an implementation, it is good practice to
> > inform yourself about applicable standards and things others do .
> > IMHO there is noone else doing this. But I don't know exactly. This
> > caused the question to you.
> 
> I'm glad your spending some time thinking this interface out. From my
> limited experience trying to get ntp to work with NMEA interface from a
> gps unit, the setup seemed to rely upon lots of magic ip addresses,
> which makes me suspicious that its not been well thought out.
> 
> So again, sorry to walk this out in such painful detail, but I'm really
> a noobie with the pps bits.
> 
> Is what your proposing more along the lines of the kernel providing the
> timestamp on the interrupt, and then providing that offset out via
> the /dev/pps interface? Maybe in the format:
> 	<interrupt count> <system time at interrupt>
Exactly.
 
> And is there a link somewhere to how this differs from the pps sysfs
> interface?
The intention differs in no way,  values don't differ.
In sysfs the slope is part of the path where you pick up the information.
cat /sys/class/pps/*/{assert,clear}/*
The intended output from /dev/pps integrates this information.

> thanks
> -john

I'll try to create patches to speak about.
(This can take longer.)

Thanks so far!


Bernhard