On 2/4/06, Tim Shoppa <[EMAIL PROTECTED]> wrote:
> Tony Hoyle <[EMAIL PROTECTED]> wrote:
> > That's transmitted in plaintext over a relatively slow RS232 link,
> > interpreted by the operating system, then the NTP driver.. by the time
> > you get it it's way off.
> >
> > PPS helps (enormously.. without it it's hard to get within 200ms)
>
> 200ms happens with some serial clocks, but not all. Many are good
> to +/-1 character (which is 1ms at 9600 baud) and a few to +/- one bit
> (better than 1ms), although all of these have to be tuned via the
> fudges.
>
> > - but
> > even with that it's damned hard to get the GPS sync within 1.5
> > milliseconds of 'known' time, and the jitter is consistently 5ms or
> > more... that's just inevitable in a multi-tasking OS, even a relatively
> > idle one.
>
> Not at all inevitable. PPS support in the kernel gives me jitters of
> +/- a few microseconds. (Z3801A, Linux with Ulrich's PPS patches).
>
> The difference between PPS out on a GPS receiver and "true" time at the
> receiver is usually guaranteed to be less than a microsecond. RS-232
> smears the pulse but you can always use differential signaling instead.
> Interrupt latency is the remaining uncertainty but even then there are tricks
> around this microsecond-level uncertainty.
>
> Tim.
>

I think most GPS that does 1PPS out gives few microseconds jitter, at
least, my non-timing Jupiter gives me few microseconds jitter.
Sometimes(2~3 per day) I see 20us spike, but I think its cause is my
environment.. my antenna is glued to outside frame of window where it
has limited sky view(half of frontal view is blocked by building.).
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to