[time-nuts] distirbuted sync

[Hal Murray]

albertson.chris at gmail.com said:
> Then use you Blue Tooth or whatever other short distance communications
> system you have to support an IP network.  TCP/IP over zBlueTooth works well
> and is a standard now.  Using this you can configure a NTP based network of
> "peers".  .., 

I'm a big NTP fan, but I wouldn't use NTP for this.  (I assume we are talking 
about the standard NTP reference package from ntp.org.)  It's too big and 
complicated and will be hard to debug if something goes wrong.  The real 
problem is that it will do the best it can rather than scream and shout when 
something unexpected happens.

On the other hand, I like playing with low level things like packets and 
clocks, and I'm not good at paying attention to the big picture when 
resources (manpower, time) are limited.  It might work fine.  It's probably 
easy to try it.

If I was doing something like this (and I could be way off by what "this" 
is), I'd try roughly:

Measure the clock drift rate on a sample of typical systems.  These systems 
need a clock good to 1E-10.  If that can be used by the OS time keeping code 
the drift should be hard to measure.  If not, measure whatever the system 
will be using.  Most likely, it will be way off, as in 10s to 100s of PPM.  
(The 100s covers software bugs in the OS and design errors in the hardware.)

Linux (on a PC) measures the CPU crystal at boot time.  There is lots of 
noise in that.  You can bypass that noise if you build your own kernel and 
find that chunk of code and patch in a constant.  (I'm thinking of one kernel 
build per set of boxes rather than one per box.)

Now you have a good thermometer.  Ballpark is 1 PPM per C.

If you measure the drift on each system and save it in ROM/Flash/file-system, 
you can add some code to the startup area to tell the system how to tweak its 
clock.  (I'll fish out the API details if anybody wants it.)

Is that good enough?   Do you even need to do the drift measurement and 
correction on each box?  ...  That's some combination of the requirements, 
how much drift is left and how well the boxes in the field track each other 
(temperature, manufacturing batch) and if you need the correct time or just 
closely tracked time.  Are some boxes in the sun and others in the shadow?  
...

Another quirk to consider is that happens if you reboot a box half way 
through the battery lifetime.  Does it get the time from its brothers or from 
the master PC?   Does the PC drift track the others or track GPS  or...?




-- 
These are my opinions.  I hate spam.