Pierre,
The NTPv4 driver interface already implements a trimmed-mean filter, which
cleans up a good deal of jitter as it is. The IRIG and CHU drivers do a
lot more signal processing, yielding generally low jitter in the tens
of microseconds. Deglitching and filtering noisy time sampls is somewhat
On Sun, Mar 07, 1999 at 08:09:50PM +0100, Poul-Henning Kamp wrote:
> I don't think Ollivier is doing PPP/hardpps() yet, at least I have not
> given him the semi-magic code needed for it :-)
>
> I wouldn't recommend trying it either, he is bound to have a >1
> msec jitter on the DCF77 waves at his
In message <199903071351.aa20...@huey.udel.edu>, Dave Mills writes:
>Ollivier,
>
>For performance monitoring with the nanokernel and PPS source, see the
>peerstats and grope for "127.0.0.1" with grep. When the daemon has
>handed off PPS to the kernel, the radio timecode is used only to
>mean the tr
Ollivier,
For performance monitoring with the nanokernel and PPS source, see the
peerstats and grope for "127.0.0.1" with grep. When the daemon has
handed off PPS to the kernel, the radio timecode is used only to
mean the transmitter is still on the air.
Dave
To Unsubscribe: send mail to majord
According to Pierre Beyssac:
> absolutely no reason why you should enable PARENB for a raw DCF77
> driver; yet that's what ntpd's configure does, at least under
> FreeBSD.
Yes, it seems to be that again. I thought I had fixed it in config.cache
but it seems not. It is working now.
remote
On Sat, Mar 06, 1999 at 08:00:53PM +0100, Ollivier Robert wrote:
> The two outputs I sent were with 4.0.90f. When I run 4.0.92c, ntpd is not
> able to get any accurate data from the device whereas 4.0.90f does.
>
> I get lots of these in /var/log/messages and it doesn't sync at all.
> -=-=-
> Mar
I just got a new set of PARSE patches from Frank Kardel, and I'm waiting
for Dave Mills to give me the go-ahead to commit them. Dave is chasing
some possible bugs and wanted a stable codebase for a while.
H
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current"
This looks like a reception problem. You must be pretty far out in
the reception area of DCF77 (just like me), and will probably find
that whenever a sunrise or sunset is in the area reception sux.
Try to see if it does better in daylight...
I don't know the state of the DCF77/parse stuff in v4
According to Poul-Henning Kamp:
> It looks synchronized to me, it just looks like it hasn't swung in yet ?
The two outputs I sent were with 4.0.90f. When I run 4.0.92c, ntpd is not
able to get any accurate data from the device whereas 4.0.90f does.
I get lots of these in /var/log/messages and it
In message <19990306164238.a29...@keltia.freenix.fr>, Ollivier Robert writes:
>According to Poul-Henning Kamp:
>> Please send comments and observations, both positive AND negative.
>
>I can't get my DCF77 device to synchronize with both the kernel diff
>applied and 4.0.92c. With the older 4.0.90f I
According to Poul-Henning Kamp:
> Please send comments and observations, both positive AND negative.
I can't get my DCF77 device to synchronize with both the kernel diff
applied and 4.0.92c. With the older 4.0.90f I'm able to sync.
remote refid st t when poll reach delay o
http://www.freebsd.org/~phk/x.nanokernel.gz
contains patches relative to -current to implement the new "nanokernel"
PLL from Dave Mills.
This only works with a ntpd v4, suggest 4.92c or better from:
ftp://ftp.eecis.udel.edu/pub/ntp
It does still not support the hardpps()/PPS_SY
12 matches
Mail list logo
