[ntp:questions] Local (own site) NTP servers.

David Woolley david at ex.djwhome.demon.co.uk.invalid
Thu Jul 23 23:31:50 UTC 2009

G8KBV wrote:
> Wonder if this will get posed, or returned to me..

As far as I know, Google groups rejects synchronously.  A direct NNTP 
client certainly would.
> So...  I'm about to try a couple of Windows "solutions"
> (opportunities)  One the "Tardis" program, that would appear

Unless you are using an MS-DOS based Windows (ME was the last) I can see 
no point whatsoever in using a shareware program with unknown internals 
when the official version of NTP is available as open source!  There is 
no certainty about the internals of Tardis, but it is quite likely no 
better than recent versions of w32time (when configured properly, rather 
than out of the box) which has been supplied, bundled with NT based 
versions of Windows, for many years.  w32time doesn't support local 
reference clocks, or PPS.

The prime designer of ntpd is a radio amateur.

> (& just why is it that about all 'nix documentation and help
> files, are written almost exclusively to obfuscate the needed
> information?)

At least the information is there.  Have you ever tried to navigate 
MSDN: a maze of windy passages leading nowhere.  In order to make 
Windows appear easy, Microsoft make the scary stuff difficult or 
impossible to find, even though it exists in copious amounts.

> Also the Meinberg NTP software (not looked at in detail yet)
> Both of them (independently while I play with them) will each

This is the same software as on FreeBSD, except that it doesn't work as 
well, because of the limitations of Windows.  All Meinberg did was 
configure a Windows installer for it.

> live on a dedicated PC for now, but ultimately one or the
> other would need to co-exist on the same PC with the
> monitoring program (Faros) that needs the time stamps.
> Pointing it's NTP client routines at LocalHost?  Low single
> figure mS jitter is OK, sub uS accuracy is just not needed.

Seriously stretches Windows.  Actually using NTP to access the time on 
the same machine removes the problem that the Windows clock cannot be 
read that accurately, but you still have the problem that Windows 
scheduling delays will introduce jitter of more than this in the 
measurement of the external events that you are monitoring, and possibly 
in the scheduling of the return to the application from the time server.

Normally people reckon in terms of low 10s of mss for Windows, although 
there are claims of better performance, possibly on lightly loaded systems.

If you want really high precision timing of sound card input, you should 
probably construct special hardware to inject the PPS signal into the 
analogue input of the sound card.

> However, while involved in something else, this came to my
> attention....
> http://bifferos.bizhat.com/
> Now, I realise the clock speed is not that quick by modern
> standards, but could that have enough "grunt" to work as a
> GPSDNTP server for a small low traffic LAN?..
> OK, I've managed (I think, as earlier) to get an older version
> of FreeBSD to run for this sort of thing (on a 500MHz P3

Seriously over-powered!  You should be thinking something more like 
50MHz i486.

> machine)  But, just how cut down can it go, with just enough
> left to boot and do the NTP task, or is the Kernel BifferOS

The size of ntpd will be the main limit.  With older versions of Linux, 
and presumably FreeBSD, you can fit everything else onto one floppy. 
Again, without ntpd, you would probably get away with 6MB of RAM.  I'd 
budget on more like 16MHz, unless you start building custom versions 
against custom libc's.
> To get Faros (HF Beacon monitoring program, runs on Windows,
> only.)  A GPSDNTP source, HF Receiver control app (my own
> code) and the resulting web based status page (or website

Be careful about the licencing for Windows; there are severe limits on 
how many people can legally access a web server on a non-server edition 
of Windows.

> Now, if Alex would integrate GPS timekeeping within Faros, all
> this would not be needed, but he has his own reasons it seems
> for not doing so.  As a result, it needs a 24/7 'net
> connection, or access to some other NTP time source.   My
> ISP's servers are somewhat less than reliable at times,
> likewise access to others due to unpredictable and huge WAN
> network latencies from time to time.

You are locked into the wrong platform, and you can't go the VM route, 
as VM systems give very poor timing to the virtual machines.

 > http://bifferos.bizhat.com/

Modern versions of ntpd require floating point, whereas 486SX doesn't 
have it, so you will need software floating point.  On the other hand, 
it may well have plenty of excess processing speed to support that.

More information about the questions mailing list