Greetings,

I'd like to assemble an NTP server and need some advice on the hardware 
and operating system.  FreeBSD and Linux have kernel PLL code, so would 
it be safe so say they would be the optimal OSes to run NTP?

What GPS receiver or interface card, performs best off the shelf?

Any motherboard recommendations?  Asus, or Intel make use particularly 
good crystals?

Given that maintainability, security, reliability, and cost are factors, 
what do the experts suggest?

Thanks,
Bill

William Holden wrote:

> I'd like to assemble an NTP server and need some advice on the hardware 
> and operating system.  FreeBSD and Linux have kernel PLL code, so would 
> it be safe so say they would be the optimal OSes to run NTP?

I'd say FreeBSD.

> What GPS receiver or interface card, performs best off the shelf?

http://www.synergy-gps.com/

> Any motherboard recommendations?  Asus, or Intel make use particularly 
> good crystals?

See below -- the stock xtals on the Soekris are excellent.  They are,
however, also excellent thermometers.  You could replace the 33.333MHz
xtal with a 32.768MHz OCXO if you -- for some reason -- need microsecond
accuracy.

> Given that maintainability, security, reliability, and cost are factors, 
> what do the experts suggest?

http://phk.freebsd.dk/soekris-pps/

http://www.soekris.com/

If you need to place the GPS/antenna far from the box (not likely),
you'll need an RS-422 card instead of the onboard RS-232 on the Soekris.

http://www.quatech.com/catalog/rs422_upci.php

In article <azWdnfgBBtSzQZmiU-KYvg@speakeasy.net>,
	Michael Sierchio <kudzu@tenebras.com> writes:
> William Holden wrote:
> 
>> I'd like to assemble an NTP server and need some advice on the hardware 
>> and operating system.  FreeBSD and Linux have kernel PLL code, so would 
>> it be safe so say they would be the optimal OSes to run NTP?
> 
> I'd say FreeBSD.

Except that FreeBSD does not support mlock calls so that if you run
low on real memory and start swapping then everything will degrade.


>> What GPS receiver or interface card, performs best off the shelf?
> 
> http://www.synergy-gps.com/

Where in the world are you?


>> Any motherboard recommendations?  Asus, or Intel make use particularly 
>> good crystals?
> 
> See below -- the stock xtals on the Soekris are excellent.  They are,
> however, also excellent thermometers.  You could replace the 33.333MHz
> xtal with a 32.768MHz OCXO if you -- for some reason -- need microsecond
> accuracy.
> 
>> Given that maintainability, security, reliability, and cost are factors, 
>> what do the experts suggest?
> 

You need more than one time source. If you are in range of some
of the LW radioclocks then

    http://www.buzzard.org.uk/radioclock.html

make excellent low cost receivers. I have had two (one MSF one DCF77)
running for 18 months without any trouble whatsoever.

JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan at buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Jonathan Buzzard wrote:

> Except that FreeBSD does not support mlock calls so that if you run
> low on real memory and start swapping then everything will degrade.

Why make assertions on a subject you know nothing about?

Absolutely false, wrong, stupidly misinformed.  FreeBSD does not
implement mlockall(), which even in the case of Linux does not
offer an ironclad guarantee.  See the archives.

MLOCK(2)                  FreeBSD System Calls Manual                 MLOCK(2)

NAME
      mlock, munlock - lock (unlock) physical pages in memory

LIBRARY
      Standard C Library (libc, -lc)

SYNOPSIS
      #include <sys/types.h>
      #include <sys/mman.h>

      int
      mlock(const void *addr, size_t len);

      int
      munlock(const void *addr, size_t len);

DESCRIPTION
      The mlock() system call locks into memory the physical pages associated
      with the virtual address range starting at addr for len bytes.

Modern operating systems don't swap, they page.

In any case, you're not well-informed.  My stratum 1 server is a Soekris
net4501 box that runs with a read-only root filesystem and no swap.

It's cheap enough to dedicate to timekeeping.

> You need more than one time source.

24 satellites?

I'll second (no pun intended) that. I get <1ms stability which would 
probably be better if my local crystal was not suffering from
fits. When well behaved it is -17,4ppm at around 20�C. THat's
a long long way from that available from the cheapest TCXO, but
I can't see how to safely make the swap on the main board.

In article <sRydnRczEKN9LJiiXTWJjQ@speakeasy.net>,
	Michael Sierchio <kudzu@tenebras.com> writes:
> Jonathan Buzzard wrote:
> 
>> Except that FreeBSD does not support mlock calls so that if you run
>> low on real memory and start swapping then everything will degrade.
> 
> Why make assertions on a subject you know nothing about?

Because I have had several emails discussion on exactly this topic,
from people wanting to port my radioclkd program to FreeBSD last year
and finding that mlockall is not supported that is why.  Yes it exists
but it is a stup that does nothing.

If this has changed in the very latest FreeBSD then I stand corrected,
but it is not something I know nothing about.


> Absolutely false, wrong, stupidly misinformed.  FreeBSD does not
> implement mlockall(), which even in the case of Linux does not
> offer an ironclad guarantee.  See the archives.

Well I disagree totally, it is not absolutely false, wrong or
stupidly misinformed.


[SNIP]

> Modern operating systems don't swap, they page.

You are being pedantic here.

> In any case, you're not well-informed.  My stratum 1 server is a Soekris
> net4501 box that runs with a read-only root filesystem and no swap.
> 
> It's cheap enough to dedicate to timekeeping.

Not everyone has the space to dedicate a whole machine to time keeping,
or is happy wasting the energy required to run a machine for just
time keeping either.


>> You need more than one time source.
> 
> 24 satellites?
> 

Go read the NTP FAQ's. You do not have 24 satellites, you have a
single GPS receiver. These can and do have hardware and firmware
bugs/faults that can cause them to pass false time information into
ntpd. If ntpd has no other means to verify the time then it will
start passing this bad time information onto other machines.

This is why it is recommened that you have three time sources
so that if one goes bad, the other two can vote it down.

JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan at buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Jonathan Buzzard wrote:

> This is why it is recommened that you have three time sources
> so that if one goes bad, the other two can vote it down.

I don't want to join the rest of this "debate" but want to comment on 
this particular item.

I've seen stability problems with only 3 NTP sources. I've found that 4 
works better and even more works better still.

IMO NTP is quite "fragile" in terms of how it behaves if the input 
sources have very much offset or jitter at all. I often see poor 
behavior over my 768/128 DSL line. This is stock NTP under various 
recent versions of FreeBSD 4.x. I don't know what version, I just run 
what comes with the OS.

Jonathan Buzzard wrote:

>>>Except that FreeBSD does not support mlock calls so that if you run
>>>low on real memory and start swapping then everything will degrade.
>>
>>Why make assertions on a subject you know nothing about?
> 
> 
> Because I have had several emails discussion on exactly this topic,
> from people wanting to port my radioclkd program to FreeBSD last year
> and finding that mlockall is not supported that is why.  Yes it exists
> but it is a stup that does nothing.

You made the assertion that FreeBSD does not support mlock.  This
is simply false.  'mlockall()' is not supported,  but this is
mostly out of intellectual honesty -- no OS supports mlockall()
in such a way as to honor the guarantee that it seems to make.

>>Modern operating systems don't swap, they page.
 >
> You are being pedantic here.

And you are in need of instruction, so it seemed appropriate.

> Not everyone has the space to dedicate a whole machine to time keeping,
> or is happy wasting the energy required to run a machine for just
> time keeping either.

There's no waste of energy -- either electrical or otherwise. It's
a bulletproof appliance that draws less than 10 Watts, and may be
place atop a pole in an enclosure with the GPS unit, with all the
necessary power supplied via PoE.

> Go read the NTP FAQ's. You do not have 24 satellites, you have a
> single GPS receiver. These can and do have hardware and firmware
> bugs/faults that can cause them to pass false time information into
> ntpd. If ntpd has no other means to verify the time then it will
> start passing this bad time information onto other machines.

It makes little sense to attach more than one reference clock to
a machine, however.  It makes more sense to deploy multiple
timekeepers and have the stratum 1 clocks peers with each
other.

In article <GHSdnUQUAovOrZqiXTWJgA@speakeasy.net>,
	Michael Sierchio <kudzu@tenebras.com> writes:
> Jonathan Buzzard wrote:
> 
>>>>Except that FreeBSD does not support mlock calls so that if you run
>>>>low on real memory and start swapping then everything will degrade.
>>>
>>>Why make assertions on a subject you know nothing about?
>> 
>> 
>> Because I have had several emails discussion on exactly this topic,
>> from people wanting to port my radioclkd program to FreeBSD last year
>> and finding that mlockall is not supported that is why.  Yes it exists
>> but it is a stup that does nothing.
> 
> You made the assertion that FreeBSD does not support mlock.  This
> is simply false.  'mlockall()' is not supported,  but this is
> mostly out of intellectual honesty -- no OS supports mlockall()
> in such a way as to honor the guarantee that it seems to make.

Well pardon me if I made a small typing mistake. Further more Linux
makes a very good job of keeping the program in memory. Without
mlockall my radioclkd program shows lots of jitter under heavy
memory usage, with mlockall, it works a treat.

Let's face it a small program only depending on libc can easily
be locked into memory.


>>>Modern operating systems don't swap, they page.
> >
>> You are being pedantic here.
> 
> And you are in need of instruction, so it seemed appropriate.

99.9% of people refer to the process of paging in passing as swaping,
if nothing from historical usage.

>> Not everyone has the space to dedicate a whole machine to time keeping,
>> or is happy wasting the energy required to run a machine for just
>> time keeping either.
> 
> There's no waste of energy -- either electrical or otherwise. It's
> a bulletproof appliance that draws less than 10 Watts, and may be
> place atop a pole in an enclosure with the GPS unit, with all the
> necessary power supplied via PoE.

10W is 10W, if it is not needed.

>> Go read the NTP FAQ's. You do not have 24 satellites, you have a
>> single GPS receiver. These can and do have hardware and firmware
>> bugs/faults that can cause them to pass false time information into
>> ntpd. If ntpd has no other means to verify the time then it will
>> start passing this bad time information onto other machines.
> 
> It makes little sense to attach more than one reference clock to
> a machine, however.  It makes more sense to deploy multiple
> timekeepers and have the stratum 1 clocks peers with each
> other.

Not quite true. It is more robust to have three or more machines,
but to stop false times getting onto the system more than one
clock on a machine is perfectly acceptable. Sure if you have three
clocks on a machine and it dies, then you have no time source but
at least you are not going to have bad time stamps. The machines
will just start drifting till you bring it back online.

Have three seperate identical machines, and some firmware bug and
you are going to have bad time stamps.

JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan at buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Just out of curiosity:  If the accuracy of PC hardware clocks varies so
much with temperature, couldn't ntpd analyze the drift vs. temperature
(assuming the hardware had a temperature sensor for the CPU case or
something) and further refine corrections for the clock in consequence?

I assume that clock drift induced by temperature varies smoothly with
that temperature, and so it seems some sort of tracking should be
possible, and it might improve the free-running accuracy of time on the
server substantially, increasing the autonomy of the server if a more
accurate reference is not available.

-- 
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

In article <n6sfgv0pcinrq480re86615jgn53gf3f20@4ax.com>,
	Mxsmanic <mxsmanic@hotmail.com> writes:
> Jonathan Buzzard writes:
> 
>> Well pardon me if I made a small typing mistake.
> 
> It would require quite a coincidental cascade of typing mistakes to make
> such an assertion.

No I typed mlock instead of mlockall, hardly a large mistake.

>> 99.9% of people refer to the process of paging
>> in passing as swaping, if nothing from historical usage.
> 
> Paging and swapping are not the same thing.

I am perfectly well aware of this. However the process is often
referred to as swapping, mainly for historical reasons. You tend
to say things like "my machine is swapping like mad" etc.

I will to further hammer the point home that he was being a pedantic
idiot that on Linux, it "pages" as he puts to a "swap area". From
"man swapon" 

    Swapon is used to specify devices on which paging and
    swapping are to take place.

    Swapoff disables swapping on the specified devices and
    files, or on all swap entries in /etc/fstab when the -a
    flag is given.

> Paging involves segments of a process.  Swapping involves the entire
> process.  Swapping is the only option on systems without hardware
> support for paging.  On systems with such support, swapping is still an
> option, but only one of several; many operating systems designed to run
> on paging hardware using both paging and swapping.

Well that is one take on the issue. I could equally argue that it
is "swapping" of pages and the entire process is can still correctly
be called swapping, and paging is just one type of swapping.

I am sure if I trawlled the lkml I could find Linus or Alan Cox
or some other notible kernel hacker refering to it as swapping.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan at buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

"Maarten Wiltink" <maarten@kittensandcats.net> wrote in message news:<3f082573$0$49111$e4fe514c@news.xs4all.nl>...
> Tim Shoppa wrote in message ...
> >Bohdan Tashchuk <tashchuk@easystreet.com> wrote in message
>  news:<vge8g6arifjkad@corp.supernews.com>...
> >>            ...my 768/128 DSL line.
>  [...]
> >The NTP design implicitly assumes symmetric network delays, yet your
> >network connection advertises itself by how asymmetric it is :-(.
> 
> 
> Those numbers are asymmetric bandwidth. Nothing is said about the delay.
> In theory, I suspect the technology is the same both ways, and the only
> difference is in the throttling at the ISP, so as long as your line isn't
> saturated, it should have the same delay both ways. In theory anyway.

Well, yeah, that's the assumption of NTP.  Maybe if you
have more download bandwidth than upload bandwidth AND you really download
more than you upload everything may work out well.  Reverse the load
situation and then it's not so good.

If your round trip delays get much above the step threshold offset
(by default 128ms?) then you have trouble brewing.  Large downloads
over modems or ADSL or SDSL will give you round-trip-times several
times this.

In practice one of the few ways to measure asymmetric delays in
both directions (as opposed to simple round-trip) is to set
both nodes up with good stratum-0 references and compare timestamps
both ways.  Some folks have been doing this for years... see

 http://www.ripe.net/test-traffic/

Tim.

>I'll second (no pun intended) that. I get <1ms stability which would 
>probably be better if my local crystal was not suffering from
>fits. When well behaved it is -17,4ppm at around 20�C. THat's
>a long long way from that available from the cheapest TCXO, but
>I can't see how to safely make the swap on the main board.

The absolute value of the drift doesn't matter much.  ntpd is
very good at correcting for that.

What does matter is the temperature coefficient and/or the temperature
stability of the environment where your system is running.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

>Just out of curiosity:  If the accuracy of PC hardware clocks varies so
>much with temperature, couldn't ntpd analyze the drift vs. temperature
>(assuming the hardware had a temperature sensor for the CPU case or
>something) and further refine corrections for the clock in consequence?

http://www.ijs.si/time/temp-compensation/


>I assume that clock drift induced by temperature varies smoothly with
>that temperature, and so it seems some sort of tracking should be
>possible, and it might improve the free-running accuracy of time on the
>server substantially, increasing the autonomy of the server if a more
>accurate reference is not available.

The hard part is measuring the temperature of the crystal.  (rather
than the CPU)

The crystal itself is reasonably linear within a small temperature
range.  If you are interested in a wide enough temperature range,
then the curve becomes second or third order.

Manfacturers/designers have some control over the curve by
picking the angle that the block is cut relative to the axis
of the physical quartz "crystal".

Sometimes you can get data from manufacturers.  Sometimes
they cut things so there is a flat spot where you want it.

Sometimes they will only tell you "x PPM over initial
manufacturaring error and temperature and voltage".
They often make the curves have flat spots a long way from
normal operations since that fits the specs.  That usually
puts a steep curve where you would like a flat spot.

http://www.toyocom.co.uk/crystal/appcry.htm
http://www.corningfrequency.com/library/isaac.html
http://www.mancini99.freeserve.co.uk/Omega_folder.html

There is lots and lots of data/info on this area.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray writes:

> The hard part is measuring the temperature of the
> crystal.  (rather than the CPU)

If you have the case temperature, as many PCs do, wouldn't that track
the crystal temperature fairly closely?  The CPU temperature certainly
would not, but the case temperature overall probably would.

-- 
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

This is a multi-part message in MIME format.
--------------070407010609070702060504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mxsmanic wrote:

>Just out of curiosity:  If the accuracy of PC hardware clocks varies so
>much with temperature, couldn't ntpd analyze the drift vs. temperature
>(assuming the hardware had a temperature sensor for the CPU case or
>something) and further refine corrections for the clock in consequence?
>
>I assume that clock drift induced by temperature varies smoothly with
>that temperature, and so it seems some sort of tracking should be
>possible, and it might improve the free-running accuracy of time on the
>server substantially, increasing the autonomy of the server if a more
>accurate reference is not available.
>
>  
>
Since most PCs, especially those being used for a time server, live in 
relatively stable environments and since the clocks in the PC are only 
necessary when you've lost GPS sync for extended periods of time, and 
since the PC is generally not moving a good location for the GPS antenna 
should not be difficult to find:

    * The GPS should not go out of sync much
    * The software should calibrate the internal clocks to the GPS
      signals to determine their true clock rate
    * And since the temperature should not change much the clock
      frequencies should remain stable

Using software to calibrate the internal clocks and stable temperatures 
I can easily keep my PC to within 100 us of drift per day.  If you're 
loosing GPS signal for more than an hour, you've got major problems with 
your GPS.

So, the stability and accuracy of the PC's on-board clocks are not that 
critical unless you're using it in an unusual situation.

Mike


--------------070407010609070702060504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Mxsmanic wrote:<br>
<blockquote type="cite"
 cite="midhcsfgvkq5khoc0lqbd11usc8r8op091nbe@4ax.com">
  <pre wrap="">Just out of curiosity:  If the accuracy of PC hardware clocks varies so
much with temperature, couldn't ntpd analyze the drift vs. temperature
(assuming the hardware had a temperature sensor for the CPU case or
something) and further refine corrections for the clock in consequence?

I assume that clock drift induced by temperature varies smoothly with
that temperature, and so it seems some sort of tracking should be
possible, and it might improve the free-running accuracy of time on the
server substantially, increasing the autonomy of the server if a more
accurate reference is not available.

  </pre>
</blockquote>
Since most PCs, especially those being used for a time server, live in
relatively stable environments and since the clocks in the PC are only
necessary when you've lost GPS sync for extended periods of time, and
since the PC is generally not moving a good location for the GPS
antenna should not be difficult to find:<br>
<ul>
  <li>The GPS should not go out of sync much</li>
  <li>The software should calibrate the internal clocks to the GPS
signals to determine their true clock rate</li>
  <li>And since the temperature should not change much the clock
frequencies should remain stable <br>
  </li>
</ul>
Using software to calibrate the internal clocks and stable temperatures
I can easily keep my PC to within 100 us of drift per day.&nbsp; If you're
loosing GPS signal for more than an hour, you've got major problems
with your GPS.<br>
<br>
So, the stability and accuracy of the PC's on-board clocks are not that
critical unless you're using it in an unusual situation.<br>
<br>
Mike<br>
<br>
</body>
</html>

--------------070407010609070702060504--

"Michael Klos" <mike@klos.com> wrote in message
news:EEFOa.11851$EQ5.11037@twister.nyroc.rr.com...

> So, the stability and accuracy of the PC's on-board clocks are not that
> critical unless you're using it in an unusual situation.

    If the GPS only provides a pulse every second, what do you think the
time server uses to tell at what point between two seconds you are?
Short-term stability of the PC clock is *very* important.

    DS