[ntp:hackers] Of Linux and jitter
David L. Mills
mills at udel.edu
Tue Oct 19 16:08:31 PDT 2004
Albert segfaulted well into the protocol dance with the debug trace
turned on. With the debug trace turned off, iit faulted within a couple
seconds. I have not concluded anything about the serial port code, just
that it has gotten far worse in recent Solaris versions and not in other
systems. And, I don't think it is the radio; I have tried different
radios on different Sun boxes and the radios all look the same.
I don't know what to think about the worsening nature of Sun I/O. First
it was the audio codec/mixer jitter, which went from 20 microseconds to
ten milliseconds, not the serial port, which went from 100 microseconds
to a second and a half. I cannot gaurantee the jitter is not some silly
aspect of the code which something in recent Solaris has exposed, but
from all evidence it sure looks like something in the kernel. A
1.5-second popcorn spike is just not credible.
mayer at gis.net wrote:
>----- Original Message Follows -----
>>1. All the backroom and campus machines are now running ntp-dev and
>>all seem to work except Linux albert on the campus wire. It segfaults
>>after a few minutes. I am dumb with Linux debugging tools, so I'll
>>leave the carcass on the hope some Linux jockey can look at it.
>We've seen that. We suspect a bad resolver library. Harlan may have
>more to say about this.
>>2. I'm very suspicious about the Solaris jitter using a serial port
>>and any of several radios. The jitter can be over one second(!) and
>>varies in intensity with time. I can't believe the port interrupt
>>routine can have jitter that high. The jitter does not occur with a
>>SunOS SPARC IPC running ntp-dev, which is now the best timekeeper we
>>have. The jitter first showed up on Ultra-1 pogo running Solaris 8/9
>>and Blade 1500 running Solaris 9. Could there be something in the
>>ntpd I/O code causing this? It's only in the serial port code; there
>>is no such jitter in the packet I/O code.
>I haven't touch ANY of the serial port code, on the packet code. Maybe
>changes in one of the refclocks affects this?
>>hackers mailing list
>>hackers at support.ntp.org
More information about the hackers