North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Interesting stratum 1 NTP clock
- From: Jerry Scharf
- Date: Wed Jun 24 14:13:37 1998
> Would a GPS hooked to the serial port of a Linux box do the same?
> On Mon, Jun 22, 1998 at 10:43:48PM -0700, Tony Li wrote:
> > Folks who run NTP in their nets might wanna check out:
> > http://www.coetanian.com/tss/tss100.htm
> > This is a reasonably affordable, NTP-ready, GPS based stratum 1 chimer,
> > complete with 10BaseT interface. It's also getting close to being
> > plug-n-play.
> > I've been beta testing one for a couple of weeks and it seems to chime
> > reasonably well.
> > Tony
> > p.s. I have no finanical interest in this product or this company
> > whatsoever. I'm just a time geek...
Any clock hooked up to a NTP server will make the server a stratum 1 server.
It makes no statements about accuracy, just NTP hopwise closeness to truth. To
NTP stratum, there is no difference between the thing Tony mentioned and a
modem calling ACTS. Your accuracy of time will be much lower in the later
cases, with what you proposed usually having errors in the single digit
Lots of people say 'Why should I care about accurate time?' I have used NTP
synchronized clock with both tcpdump and Cisco logging to chase problems.
Sometimes I'm after big things, but other times I'm trying to figure out
whether two things that are happening are the same or different. Being able to
have time accurate to the few packet range is a real in separating these out.
It's really hard to get there when you're talking about OC48s, but even fast
ethernets have packets lasting in the 10s of microseconds.
The nastiest problem I ever traced this way was a ethernet card on a bsd unix
box that would occasionally drop interrupts when the system was under load.
Being able to have two machines looking on the wires while the problem machine
was acting as a router was the only way I found it. The events rarely lasted
more than a couple milliseconds, so 10+ms timing just wouldn't have been good
enough. Someone might have been able to guess the problem other ways, but with
this I had tools to see the problem.
So usually you don't need it, and if you don't have it you won't even believe
you need it, but I have used it and always want it available. Not many (maybe
none) customers are going to care below the 10s on milliseconds, but as a
network engineers it could save you.
(end or rant)