|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NTp sources that work in a datacenter (was Re: Is latency equivalent to RTT?)
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. > [email protected] 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: [email protected] me: [email protected] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
|