timestuff, was Re: performance, was Re: [LinuxPPS] patch report

[gnu not unix]

In message <200607171527.k6HFR25a004617 at ring.wraith.sf.ca.us> you write:

>>How do you think the code performs?
>>Tips, hints, suggestions?

(...)
>One thing that I have noticed, is that the ppm drift of the
>motherboard RTXO on the unit I switched from 2.4.20-NANO
>(PPSKit) to 2.6/linuxpps, has gone from 70ppm to 50ppm.

>This is very interesting and I am trying to understand the
>change. The old kernel ran at 100hz tick rate and the new
>kernel is setup for 250hz tick. I recall Dave Mills has

The plots for the 2.6.17/linuxpps kernel have settled down
a bit now, and there are some interesting things visible.

The "offset" plot shows a distinct "microsecond wiggle."

This I can understand since the kernel is not a "NANO" kernel,
yet, although there is some heavy lifting going on to get
things such as high precision event timers and posix timers
in place. 

>said the kernel code design shouldn't be changed, as it
>is part of the software PLL, and I think that he suspects 
>the linux kernel mongers of Not Paying Attention. 

After looking at the code and some mailing list traffic,
they're busy as an anthill (grin). There is the phrase
"religious wars" mentioned in this regards as well (cough).

An interesting thread:

http://www.gatago.com/linux/kernel/6122455.html

The other item I've noticed in the plots, is that the shape
of the frequency plot (plots the current value for ntp.drift)
is inverted compared to the 2.4.x/PPSkit code. That is, when
the temperature varies, the curve for linuxpps is opposite that 
of the curve for PPSkit plots.

The ntpd seems stable, though, so far. 

One final data point: the old setup on the 2.4.x/PPSkit
host was with a fan cooled PII/266. The 2.6.17/linuxpps
is using a passively cooled PII/400. The motherboard is
still the Tyan Tsunami S1830. The server has two functions,
it is the DNS master for the local domain, and it runs the
ntpd code. I have added a sound card to support the WWV
driver in this host under 2.6 as well.

We are still in a hot spell here in California, too.
My non-airconditioned lab has been much warmer than usual,
and that is reflected in the jaggedness and variability
of the plots of the other hosts.

I note that PPSkit hardpps() does 

  time_status |= STA_PPSSIGNAL;

Should we do something similar in linuxpps_event()? 

Also, the timestamp in linuxpps_event occurs *after*
a couple of "if" tests. I'm a bit skeptical about that,
and I'm thinking of moving the gettimeofday to before
the two if tests. No harm in doing it there, after all.
I do exactly that in the shm parallel port pps driver
code, just grab a timestamp and ignore it if needs be.

../Steven
cut'n 'n paste'n...