time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Recommendations for NTP server

PK
Poul-Henning Kamp
Mon, Apr 24, 2006 9:38 AM

In message Gb7QUsAye$SEFwKA@g8kbz.demon.co.uk, Geoff Powell writes:

So you'd recommend a 4501, with FreeBSD in Compact Flash? I wanted to
use CF anyway, since a box running 24/7 is not the best environment in
which to have moving parts. The box will have no more that NTP and MRTG
on it.

There isn't much I can add here, but I just want to add a few things:

Sub-microsecond precision is impossible with regular crystals, end
of story.  You need OCXO or Rb support for that.

If you don't need the SNMP capability, drop MRTG and use RRDtool,
(MRTG's more general sibling).

If you want to run MRTG or RRDtool, you probably do not want to use
a CF card: it will wear out - eventually.  Don't trust more than a
year.

I wrote a hack called "Remote RRD" which sends updates in UDP packets
to another host which hosts the RRD file and web-pages and all that
to get around this problem.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message <Gb7QUsAye$SEFwKA@g8kbz.demon.co.uk>, Geoff Powell writes: >So you'd recommend a 4501, with FreeBSD in Compact Flash? I wanted to >use CF anyway, since a box running 24/7 is not the best environment in >which to have moving parts. The box will have no more that NTP and MRTG >on it. There isn't much I can add here, but I just want to add a few things: Sub-microsecond precision is impossible with regular crystals, end of story. You need OCXO or Rb support for that. If you don't need the SNMP capability, drop MRTG and use RRDtool, (MRTG's more general sibling). If you want to run MRTG or RRDtool, you probably do not want to use a CF card: it will wear out - eventually. Don't trust more than a year. I wrote a hack called "Remote RRD" which sends updates in UDP packets to another host which hosts the RRD file and web-pages and all that to get around this problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
GP
Geoff Powell
Mon, Apr 24, 2006 10:05 PM

In article 15153.1145871481@critter.freebsd.dk, Poul-Henning Kamp
phk@phk.freebsd.dk writes

In message Gb7QUsAye$SEFwKA@g8kbz.demon.co.uk, Geoff Powell writes:

So you'd recommend a 4501, with FreeBSD in Compact Flash? I wanted to
use CF anyway, since a box running 24/7 is not the best environment in
which to have moving parts. The box will have no more that NTP and MRTG
on it.

There isn't much I can add here, but I just want to add a few things:

Sub-microsecond precision is impossible with regular crystals, end
of story.  You need OCXO or Rb support for that.

Fine - I presume something like your web page about Soekris boards
(where you characterised the performance of such a unit at ultimate
precision) is the route to follow. I have follow-up plans for something
similar further down the road. This year, next year, sometime, never...

Meanwhile, FreeBSD with your patches on a NET4501 will give units of
microseconds?

If you don't need the SNMP capability, drop MRTG and use RRDtool,
(MRTG's more general sibling).

Rats! Another app to learn! But you're right, SNTP is a gong - the bells
and whistles I want are NTP stats.

If you want to run MRTG or RRDtool, you probably do not want to use
a CF card: it will wear out - eventually.  Don't trust more than a
year.

Yes, I am aware of flash memory wear-out problems. I was thinking of
NFS-mounting a directory elsewhere on my network as scratch space.

I wrote a hack called "Remote RRD" which sends updates in UDP packets
to another host which hosts the RRD file and web-pages and all that
to get around this problem.

Aha! A cure. Would you post a URL? Pretty please?

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

--
Geoff Powell

In article <15153.1145871481@critter.freebsd.dk>, Poul-Henning Kamp <phk@phk.freebsd.dk> writes >In message <Gb7QUsAye$SEFwKA@g8kbz.demon.co.uk>, Geoff Powell writes: > >>So you'd recommend a 4501, with FreeBSD in Compact Flash? I wanted to >>use CF anyway, since a box running 24/7 is not the best environment in >>which to have moving parts. The box will have no more that NTP and MRTG >>on it. > >There isn't much I can add here, but I just want to add a few things: > >Sub-microsecond precision is impossible with regular crystals, end >of story. You need OCXO or Rb support for that. Fine - I presume something like your web page about Soekris boards (where you characterised the performance of such a unit at ultimate precision) is the route to follow. I have follow-up plans for something similar further down the road. This year, next year, sometime, never... Meanwhile, FreeBSD with your patches on a NET4501 will give units of microseconds? > >If you don't need the SNMP capability, drop MRTG and use RRDtool, >(MRTG's more general sibling). Rats! Another app to learn! But you're right, SNTP is a gong - the bells and whistles I want are NTP stats. > >If you want to run MRTG or RRDtool, you probably do not want to use >a CF card: it will wear out - eventually. Don't trust more than a >year. Yes, I am aware of flash memory wear-out problems. I was thinking of NFS-mounting a directory elsewhere on my network as scratch space. > >I wrote a hack called "Remote RRD" which sends updates in UDP packets >to another host which hosts the RRD file and web-pages and all that >to get around this problem. Aha! A cure. Would you post a URL? Pretty please? > >-- >Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >phk@FreeBSD.ORG | TCP/IP since RFC 956 >FreeBSD committer | BSD since 4.3-tahoe >Never attribute to malice what can adequately be explained by incompetence. > >_______________________________________________ >time-nuts mailing list >time-nuts@febo.com >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > -- Geoff Powell
AB
Ask Bjørn Hansen
Mon, Apr 24, 2006 10:56 PM

On Apr 24, 2006, at 3:05 PM, Geoff Powell wrote:

I wrote a hack called "Remote RRD" which sends updates in UDP packets
to another host which hosts the RRD file and web-pages and all that
to get around this problem.

Aha! A cure. Would you post a URL? Pretty please?

On Apr 24, 2006, at 3:05 PM, Geoff Powell wrote: >> I wrote a hack called "Remote RRD" which sends updates in UDP packets >> to another host which hosts the RRD file and web-pages and all that >> to get around this problem. > > Aha! A cure. Would you post a URL? Pretty please? http://phk.freebsd.dk/rrdd/ - ask -- http://askask.com/ - http://develooper.com/
PK
Poul-Henning Kamp
Tue, Apr 25, 2006 2:01 PM

In message $AguiKAZuUTEFw0R@g8kbz.demon.co.uk, Geoff Powell writes:

Meanwhile, FreeBSD with your patches on a NET4501 will give units of
microseconds?

It's all in stock FreeBSD, no patches needed.

The major problem you will have is that NTPD isn't very good once
you get down into microseconds.

Yes, I am aware of flash memory wear-out problems. I was thinking of
NFS-mounting a directory elsewhere on my network as scratch space.

That would work too.

I wrote a hack called "Remote RRD" which sends updates in UDP packets
to another host which hosts the RRD file and web-pages and all that
to get around this problem.

Aha! A cure. Would you post a URL? Pretty please?

http://phk.freebsd.dk/rrdd

It's not very slick, but it works :-)

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message <$AguiKAZuUTEFw0R@g8kbz.demon.co.uk>, Geoff Powell writes: >Meanwhile, FreeBSD with your patches on a NET4501 will give units of >microseconds? It's all in stock FreeBSD, no patches needed. The major problem you will have is that NTPD isn't very good once you get down into microseconds. >Yes, I am aware of flash memory wear-out problems. I was thinking of >NFS-mounting a directory elsewhere on my network as scratch space. That would work too. >>I wrote a hack called "Remote RRD" which sends updates in UDP packets >>to another host which hosts the RRD file and web-pages and all that >>to get around this problem. > >Aha! A cure. Would you post a URL? Pretty please? http://phk.freebsd.dk/rrdd It's not very slick, but it works :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
G
Glenn
Fri, May 5, 2006 6:22 PM

John Ackermann N8UR wrote:

Geoff Powell said the following on 04/23/2006 05:42 PM:

Is PPS kernel discipline compiled into the default FreeBSD kernel?

No, but it's a pretty easy thing to turn on -- you add a line to the
config file and tell it to go.  Pretty straightforward, once you find
the instructions.

Where would I find these instructions?

I've decided to setup a FreeBSD box for my time server sooner rather
than later.
I presume FreeBSD v6.0 is up to the task. Other than PPS kernel
discipline, are
there any other nonobvious configuration changes I'll need to make?

thanks,
glenn

John Ackermann N8UR wrote: >Geoff Powell said the following on 04/23/2006 05:42 PM: > > > >>Is PPS kernel discipline compiled into the default FreeBSD kernel? >> >> > >No, but it's a pretty easy thing to turn on -- you add a line to the >config file and tell it to go. Pretty straightforward, *once* you find >the instructions. > > Where would I find these instructions? I've decided to setup a FreeBSD box for my time server sooner rather than later. I presume FreeBSD v6.0 is up to the task. Other than PPS kernel discipline, are there any other nonobvious configuration changes I'll need to make? thanks, glenn
JA
John Ackermann N8UR
Fri, May 5, 2006 6:35 PM

Glenn wrote:

Is PPS kernel discipline compiled into the default FreeBSD kernel?

No, but it's a pretty easy thing to turn on -- you add a line to the
config file and tell it to go.  Pretty straightforward, once you find
the instructions.

Where would I find these instructions?

It's in the FreeBSD users manual (or whatever it's called) which I found
at the FreeBSD web site.  That gives general instructions for rebuilding
the kernel.  I'm not sure if it specifically identifies the PPS flag or
not.  On my 5.4 machine, it was adding:

NTP PPS support

options        PPS_SYNC

to the /usr/src/sys/i386/config/PPS_KERNEL file, which was copied from
the generic kernel config file.  Then rebuild, specifying PPS_KERNEL as
the config file name.  There's also an associated .hints file which
allows you to set the serial ports to low-latency mode by disabling the
FIFO in the 16550 UART chip; this can reduce jitter.  I don't recall for
sure, but I think it's setting the second bit (ie, 0x1_) in the flags
field:

hint.sio.0.at="isa"
hint.sio.0.port="0x3F8"
hint.sio.0.flags="0x12"

John

Glenn wrote: >>>Is PPS kernel discipline compiled into the default FreeBSD kernel? >>> >>> >> >>No, but it's a pretty easy thing to turn on -- you add a line to the >>config file and tell it to go. Pretty straightforward, *once* you find >>the instructions. >> >> > > > Where would I find these instructions? It's in the FreeBSD users manual (or whatever it's called) which I found at the FreeBSD web site. That gives general instructions for rebuilding the kernel. I'm not sure if it specifically identifies the PPS flag or not. On my 5.4 machine, it was adding: # NTP PPS support options PPS_SYNC to the /usr/src/sys/i386/config/PPS_KERNEL file, which was copied from the generic kernel config file. Then rebuild, specifying PPS_KERNEL as the config file name. There's also an associated .hints file which allows you to set the serial ports to low-latency mode by disabling the FIFO in the 16550 UART chip; this can reduce jitter. I don't recall for sure, but I *think* it's setting the second bit (ie, 0x1_) in the flags field: hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.flags="0x12" John