home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!agate!ucbvax!maths.tcd.ie!ajudge
- From: ajudge@maths.tcd.ie (Alan Judge)
- Newsgroups: comp.protocols.time.ntp
- Subject: Re: Problems with xntp and MIPS RISC/os 5.01
- Message-ID: <9301121633.aa05583@salmon.maths.tcd.ie>
- Date: 12 Jan 93 16:33:09 GMT
- Sender: daemon@ucbvax.BERKELEY.EDU
- Distribution: inet
- Organization: The Internet
- Lines: 33
-
- Lars> I am not sure that the SLEWALWAYS code has ever been tested. (I
- Lars> certainly didn't do so when I was hacking xntp to version 3.) On the
- Lars> other hand, it does seem like it ``ought to'' work --- it's not that
- Lars> complicated.
-
- I'm a little worried about what happens if the clock drifts too far
- for adjtime to be able to cope reasonably.
-
- Lars> It does seem that you need something like SLEWALWAYS, or perhaps a
- Lars> variant that uses gettimeofday to get to the nearest second and leaves
- Lars> the residue in sys_offset. Since it is you who needs the feature, it
- Lars> is probably up to you to get it to work.
-
- This is what I was thinking of doing. I'm willing to do the coding,
- but I'm worried about breaking NTP in the process, as I don't really
- understand how it works.
-
- For example, if I use a variant of settimeofday to get to the nearest
- second, will xntp be able to deal with the rest of the offset with
- adjtime? As the code is now, it looks like it will attempt to step
- for any offset greater than 128ms, and may never get in sync. Also,
- the comments warn about increasing CLOCK_MAX above 500ms, which is the
- minimum that I would need (and, even then, I could end up stepping a
- lot).
-
- What sort of tickadj values are reasonable if one is reliant on
- adjtime?
-
- Have you any hints about what I might try, or things to avoid?
- What is the best way of testing an NTP server? (I don't want to start
- running a flaky Stratum 2.)
- --
- Alan
-