[ntp:questions] Re: OS recomendations for stratum 2 clocks
Richard B. Gilbert
rgilbert88 at comcast.net
Tue Sep 13 19:10:06 UTC 2005
Joseph Gwinn wrote:
>In article <8c-dnZ2dnZ39fdy0nZ2dnb_puN6dnZ2dRVn-yZ2dnZ0 at comcast.com>,
> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote:
>
>
>
>>Joseph Gwinn wrote:
>>
>>
>>
>>>In article <p06200715bf49e0aff7e0@[10.0.1.210]>,
>>>brad at stop.mail-abuse.org (Brad Knowles) wrote:
>>>
>>>
>[snip]
>
>
>>>Probability of necessity varies with application.
>>>
>>>Right now I have a problem with a closed network where the computer
>>>clocks sometimes get ten or twenty milliseconds out of synch, even
>>>though they usually stay within a millisecond or so. The LANs are very
>>>lightly loaded, and the whole system would fit into a sphere 35 meters
>>>in diameter, so transport delay isn't the issue.
>>>
>>>The problem is that other realtime activities (application code) in the
>>>various servers is kicking the NTP daemons sidewise during heavy system
>>>load. The daemons are at default priority. NTP cannot tell this from
>>>real transport delay, randomly asymmetrical delay at that, so a lot of
>>>really bad samples eventually leak through the median filter and corrupt
>>>NTP's notion of the time offset to the master clocks. NTP is actually
>>>fairly resistant to this kind of abuse, but the application code is
>>>sufficiently overloaded that the necessary abuse is often arranged.
>>>
>>>The immediate solution will have to be to promote the daemons to higher
>>>realtime priority than that of those interfering other activities, but
>>>the people responsible for those activities are likely to object (more
>>>
>>>
>>>from fear than from thought, but ... the pressure is on). Or, just live
>>
>>
>>>with it.
>>>
>>>Joe Gwinn
>>>
>>>
>>>
>>>
>>If these servers are running Windows, there's little hope!
>>
>>
>
>True enough.
>
>But no; they are running SGI IRIX on the servers where the sideways
>kicking happens. No Windows in this drama.
>
>
>
>
>>If they are running some flavor of Linux and the clock tick rate is set
>>to 1000 Hz, it can be changed to 100 Hz and the kernel rebuilt. This
>>cuts the opportunity to lose interrupts by a factor of ten.
>>
>>
>
>Which helps, but isn't close to a solution. There should be *no* lost
>timer interrupts.
>
>
>Joe Gwinn
>
>
Then I think you need to talk to Silicon Graphics about it. If it's a
bug they may be able to patch it. If, as seems likely, it's an O/S
design issue, the fix may require a lot of time and resources.
More information about the questions
mailing list