[ntp:questions] how to have offset < 1ms

Richard B. Gilbert rgilbert88 at comcast.net
Thu Apr 15 18:55:23 UTC 2010

unruh wrote:
> On 2010-04-15, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>> unruh wrote:
>>> On 2010-04-15, Uwe Klein <uwe_klein_habertwedt at t-online.de> wrote:
>>>> nemo_outis wrote:
>>>>> It is frequently the case that OPs (for a variety of reasons) misstate or 
>>>>> mispecify their problem or overconstrain its solution (either in terms of 
>>>>> what can or must be done or what can't or mustn't).  I submit that the 
>>>>> current OP is a classic case.
>>>> The classic situation I've seen here on a regular basis is
>>>> that the submittant would like to have a cohesive timing situation
>>>> and does not care for syncronicity to the outside world.
>>>> The classic answer seems to be a handwaving jedi gesture.
>>>> You don't want that, you want "real" timekeeping.
>>> The easiest way to achieve cohesive timing is to have everything locked
>>> to real time. If everything is locked to real time, then everything is
>>> cohesive as well. And with the price of a GPS receiver, that is also
>>> often the cheapest way to do it as well. 
>>> Of course one can always just set on system to local time source  and have it as
>>> the server to everything else. That will, unless that particular machine
>>> suffers from severe temp variations, or other hardware problems, also
>>> work. Or I guess the new orphan mode of ntp. 
>>>> ( which imho is understandable, some here have put a significant
>>>>    amount of their lifetime into "real" timekeeping.
>>>>     The request thus is a distastefull abomination )
>>>> On the other hand cohesive group timing is quite sufficient in a lot of
>>>> applications. And lacking in agility to jump all the hoops presented
>>>> on the way towards "real" timekeeping this will just have to do in some
>>>> cases.
>>> What hoops? It is easy. Probably easier than worrying about cohesive
>>> timing in its absense. 
>>> Timekeeping to usec accuracy has become almost trivial. Now if someone
>>> would only start selling GPS18x with a usb/serial/parallel plug at the
>>> end of it, so one could just plug it in and not worry about soldering it
>>> would become totally trivial. ( Mind you some way of adding an extention
>>> to the 5m cable would also be useful)
>> My understanding is that USB is a poor choice due to large and 
>> unpredictable latencies.  I've never tried it because I never needed to.
>> My Motorola Oncore M12+T has an RS232-C serial interface that works very 
>> well.
> The usb is solely for power. In my case I use the usb for power, the
> parallel port with a home written interrupt service module for the PPS,
> and the serial port for the nmea output. 
> If you just want the pps, ( the date/time to second available elsewhere)
> then you just need usb/parallel port.
> For ms accuracy you would just need usb for power and serial port, but
> work by Lichvar suggests that you cannot just use the serial port if you
> want usec accuracy. 

Well, the last time I looked,I was getting sub millisecond accuracy 
using a Motorola Oncore M12+T and a serial port on a Sun Ultra 10 
workstation.  It might be done better some other way but what I have 
meets my modest needs.

More information about the questions mailing list