[ntp:questions] Query about NTP accuracy

Hal Murray hal-usenet at ip-64-139-1-69.sjc.megapath.net
Sat May 23 04:26:18 UTC 2009


In article <4a173189$0$18246$da0feed9 at news.zen.co.uk>,
 Andy Yates <andyy1234 at gmail.com> writes:

>Hi Hal
>
>Its up to us to specify what we think the SLA should be - the guide is
>"as accurate as possible"!

I think there is an implied "at reasonable cost" in there.

I've never run a data center nor had to hassle with SLAs.

If my boss gave me that task, I'd push back real hard.  Where
is the knee of the benefit curve?  Is 100 ms good enough?
What fraction of the time?  How much more is 10 ms worth?

There are two types of costs.  One is hardware and easy to see.
The other is operations.  If you spec things too tight, you will
create a lot of work for the operations team.

If you do anything sane, the clocks will be within 10-100 ms
most of the time.  Is that good enough?  What sort of "most"
do you need?

Do you have legal requirements?  (as in stock market transactions)
What does your lawyer say?

If you are going to put a SLA for time into a contract.  You
will have to have a way to verify that you are meeting specs
so you might as well start debugging the monitoring process
now.  If you are sufficiently paranoid, you will need (at
least) 2 of them in each data center.

You will also need a time-wizard to keep track of things.


>> How stable is your temperature?  (Both the room and the CPU load.)
>
>Temperature will be very stable, the DC is the very well specified and
>scrupulously engineered - no cables blocking air flow etc. Generally
>speaking the CPU is over specified.

Does anybody ever hold the door open for more than a few seconds?
Can you be sure they won't do it tomorrow?

That's only half the problem.  The other is the source of heat
inside the box.  An active system makes a lot more heat than
an idle one.  To get numbers, I'd setup a system, turn on lots of
logging, leave it idle for a long time (say a day) then look at
the drift.  (It's in loopstats.)  Then start a good load, let it
run for several hours, and see how much the drift changed.
I'd also look at the offset during the transient.

(PS: If your specs are tight, you will have to repeat that
experiment each time you get a new flavor of server box.
It's just another item for the checklist.)


>> What is the load on the LAN between the clients and servers?
>> (Delay is not a problem.  Variation in delay is a problem.)
>The NTP will be on a separate management LAN to the production traffic
>so not subject to the variances that application load has on the network.

That seems like a reasonable assumption.  Are you sure?  Will
it ever get used for an emergency transfer of a large file?
(say recovering from a crashed disk)


There are a handful of things I can think of that will screwup
your clocks.
  temperature
  network load
  software bugs
  operational screwups
  driver quirks

Linux has a history of screwing up the timekeeping kernel code.

Operators can be very ingenious at finding ways to screw things up.
If your time spec is tight enough, you will have to go over the
checklist carefully with time in mind.  You'll need to add things
like "wait x minutes for the system to warm up" when you swap in
a new box for one that died.

Ethernet drivers often try to batch interrupts to reduce CPU
overhead.  Details matter.  Another item for the checklist.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.




More information about the questions mailing list