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 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
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?
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?
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.
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
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:
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