Re: NTp sources that work in a datacenter (was Re: Is latency equivalent to RTT?)

["David G. Andersen" <dga () lcs mit edu>]

On Wed, May 14, 2003 at 08:02:28AM -0700, Steve Francis quacked:
> But what GPS clock can you install in a datacenter? AFAIK, they all 
> require roof (or at least window) access in order to install the 
> antenna. (At least, all the GPS based ntp servers I've looked at do).
> Is that not true of CDMA servers?
> How have others solved this issue? (Short of owning their datacenters.)

  http://www.endruntechnologies.com/

  I've got about 20 of their Praecis Ct units installed in various
datacenters around the world, and they work in ... most of them.
There are a couple that're buried deeply enough inside buildings
that they can't receive enough of a signal, but that's about
only 5% or 10% of the time.  Most of the time they just work.

> Michael.Dillon () radianz com wrote:
>
> > I assume that it's fairly common for people to have Solaris or Linux 
> > boxes
> >
> > in every PoP to do measurements. In that case, the difficulty isn't in 
> > measuring one-way latency, it's in synchronizing the time on all the 
> > servers. And with fairly cheap GPS and CDMA clocks that is a lot 
> > easier/cheaper than it once was.

(Warning, somewhat involved rant below from someone who's spent
too much time trying to measure one-way latencies):

It's easier, but it's still not trivial.  There are some systems
level issues that still creep up when you're doing one-way measurements
that you might not often think about.  For instance, FreeBSD (and
now Linux, I think) have a recvmsg option to get a card-level
timestamp of when a packet was _received_, called SO_TIMESTAMP, but
there's no standard way of finding out when packets were actually
transmitted.  The measurement folk at CAIDA have a kernel patch
for FreeBSD that puts a kernel-level timestamp in outgoing packets
to get rid of that source of uncertainty:

http://www.caida.org/tools/measurement/skitter/skping/index.xml

Using both of those gets you away from calling gettimeofday() to
time your packets.  Kernels are usually pretty good about trying
to make sure the user visible clock doesn't go backwards, but
when you're checking it against an external source, you can notice
some really weird happenings.  On FreeBSD, setting
kern.timecounter.method=1 will help.

Anyway, while getting the basic equipment up and running is
really easy, there's more to getting accurate one-way latencies
than just running ping once and a while.  Be nice if we had
a high-resolution equivalent of the ICMP_TSTAMP request
type, so we could just use a ping variant.

    -Dave

-- 
work: dga () lcs mit edu                          me:  dga () pobox com
      MIT Laboratory for Computer Science           http://www.angio.net/
      I do not accept unsolicited commercial email.  Do not spam me.