[ntp:questions] how to have offset < 1ms
unruh at wormhole.physics.ubc.ca
Thu Apr 15 17:36:03 UTC 2010
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
>> 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
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.
More information about the questions