Using standard PC hardware, and no directly connected reference clocks 
as limitations, is there a general recommendation for OS on a box that 
will be dedicated to NTP?  My current background has me most 
comfortable with FreeBSD, but if using a true RTOS will give me any 
tangible improvements in the quality of time pushed out of these boxes 
(stratum issues not withstanding) then I'm willing to learn a new 
setup.

Joshua Coombs 

Joshua Coombs wrote:

> Using standard PC hardware, and no directly connected reference clocks 
> as limitations, is there a general recommendation for OS on a box that 
> will be dedicated to NTP?  My current background has me most 
> comfortable with FreeBSD, but if using a true RTOS will give me any 
> tangible improvements in the quality of time pushed out of these boxes 
> (stratum issues not withstanding) then I'm willing to learn a new setup.
>
> Joshua Coombs

Free BSD will get the job done.   So will Solaris (also free these 
days).  Linux and Windows are poor choices for this application as both 
have a tendency to lose clock interrupts.

In article <U_ydnaOtxYcnzYLeRVn-sQ@comcast.com>,
 "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:

> Free BSD will get the job done.   So will Solaris (also free these 
> days).  Linux and Windows are poor choices for this application as both 
> have a tendency to lose clock interrupts.

That's not the first time I've seen recommendations for FreeBSD, and I 
promised myself I'd run the "next" NTP server I run on that OS.

However, I need to get an el-cheapo PC to run FreeBSD -- my old Cobalt 
RaQ3 finally bit the dust, and I was waiting for it to die before I'd 
bother buying new hardware.

Any advice for a relatively inexpensive, small PC? Rackmount's fine, but 
it'd be sitting on it's side on my floor, so a small tower would work 
well too. It would be running the NTP server, and optionally an HTTP 
server serving a small informational website about it. Power consumption 
should be low, as my electric bill is already quite high. I'm looking 
for something <$300, and I don't need a monitor, keyboard, or 
anything...just the computer.

Cheers!

-- 
Pete Stephenson
HeyPete.com

At 4:17 PM -0400 2005-09-07, Joshua Coombs wrote:

>  Using standard PC hardware, and no directly connected reference clocks
>  as limitations, is there a general recommendation for OS on a box that
>  will be dedicated to NTP?  My current background has me most comfortable
>  with FreeBSD, but if using a true RTOS will give me any tangible
>  improvements in the quality of time pushed out of these boxes (stratum
>  issues not withstanding) then I'm willing to learn a new setup.

	Choosing the right hardware platform, with the right kernel 
configuration, Poul-Henning Kamp has gotten FreeBSD configurations 
down to the nanosecond range for accuracy -- note that most of the 
rest of us have to make do with accuracy down only as far as the 
millisecond range.

	Of course, he had a good-quality Stratum-1 GPS directly 
connected, but the same hardware platform/kernel configuration should 
likely do as well as can reasonably be expected for a Stratum-2 time 
server without any directly connected refclocks.


	You could probably do the same or somewhat better with an RTOS, 
but the real kicker is that you have to be very careful with your 
hardware and OS configuration -- just any random PC ain't gonna be 
able to get you anywhere close to that level, no matter what the OS 
looks like.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

At 9:00 PM +0000 2005-09-07, Pete Stephenson wrote:

>  Any advice for a relatively inexpensive, small PC?

	Actually, the ideal PC for running an NTP server is a Soekris 
4501, with CompactFlash for storage media.  Including the case, the 
three network interfaces, etc..., these things are still about the 
size of small books.  Plop a couple of largish remote controls down 
beside each other, and they might be bigger than the Soekris.  Board 
size is 4.85" x 5.7".  Power supply is an external "wall wart", 
6-20VDC, maximum 10 watts.

	You could also run quite a nice little web server, and a whole 
host of other things on there too.  Even a nice little firewall, 
which should be able to handle operations up to about 50-100MBps, 
depending on the configuration and the load.

	Nice little boxes.  See <http://www.soekris.com/net4501.htm>. 
The pricelist at <http://www.soekris.com/how_to_buy.htm> shows that, 
in quantities of one, board and case for a net4501 runs $177, plus 
power supply ($9-16, depending on model).  UPS ground shipping within 
the Continental US is free for orders over $130, but you pay extra if 
you want something else.


	But then, maybe this is a bit smaller than you had in mind.  ;-)

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Pete Stephenson wrote:
> In article <U_ydnaOtxYcnzYLeRVn-sQ@comcast.com>,
>  "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
> 
> 
>>Free BSD will get the job done.   So will Solaris (also free these 
>>days).  Linux and Windows are poor choices for this application as both 
>>have a tendency to lose clock interrupts.
> 
> 
> That's not the first time I've seen recommendations for FreeBSD, and I 
> promised myself I'd run the "next" NTP server I run on that OS.
> 
> However, I need to get an el-cheapo PC to run FreeBSD -- my old Cobalt 
> RaQ3 finally bit the dust, and I was waiting for it to die before I'd 
> bother buying new hardware.
> 
> Any advice for a relatively inexpensive, small PC? Rackmount's fine, but 
> it'd be sitting on it's side on my floor, so a small tower would work 
> well too. It would be running the NTP server, and optionally an HTTP 
> server serving a small informational website about it. Power consumption 
> should be low, as my electric bill is already quite high. I'm looking 
> for something <$300, and I don't need a monitor, keyboard, or 
> anything...just the computer.
> 
> Cheers!
> 

Check out the sokeris boxes (I have two 4801's running one of which is
an S1 time server - they consume less than 15W each) - if you want
something a little bigger I also have a $350 eMachines Celeron box
that I got on closeout from Best buy (2.9ghz celeron, 512mb, 80 gb
disk, DVD + CD-RW for $350 not bad).  Pretty much any Pentium class
box will work will work as a time server (even down to old 133mhz
machines you can get for free).



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDH1zLaVyA7PElsKkRAx7cAJ43AIjY8gSZVnaiD8sfmK+P2cVGTACgqoAc
GHWgrbnBZOTfRl6N6eXILPk=
=udw9
-----END PGP SIGNATURE-----

I gather the soekris 4501s do an even better job with NTP than the 4801s.

This assumes you want "new" hardware.

If all you want to run is ntp and perhaps a small web server, pretty much
any old/suitable box will do fine.

This also assume you are not interested in creating a Good S1 server.

H

"Harlan Stenn" <stenn@ntp.isc.org> wrote in message 
news:ywn9hdcw8iyy.fsf@ntp1.isc.org...

>I gather the soekris 4501s do an even better job with NTP than the 4801s.
>
> This assumes you want "new" hardware.
>
> If all you want to run is ntp and perhaps a small web server, pretty much
> any old/suitable box will do fine.
>
> This also assume you are not interested in creating a Good S1 server.

    I would just recommend making sure it's at least a Pentium class 
machine. You really want a CPU with a TSC. Although I guess for a stratum 
two, the accuracy difference might not be noticeable.

    DS

In article <p062007a6bf450a7b3b72@[10.0.1.210]>,
 brad@stop.mail-abuse.org (Brad Knowles) wrote:

> 	Nice little boxes.  See <http://www.soekris.com/net4501.htm>. 
> The pricelist at <http://www.soekris.com/how_to_buy.htm> shows that, 
> in quantities of one, board and case for a net4501 runs $177, plus 
> power supply ($9-16, depending on model).  UPS ground shipping within 
> the Continental US is free for orders over $130, but you pay extra if 
> you want something else.
> 
> 
> 	But then, maybe this is a bit smaller than you had in mind.  ;-)

That looks exactly like what I'm looking for.

Now, the question is how does one interface with it visually? Only via a 
serial cable and a terminal emulator on a "host" PC? Doesn't look like 
it has any capability for a monitor, keyboard, or other interfaces.

Otherwise, it sounds great. Anyone have any experience on how easy it is 
to configure FreeBSD on them and get an NTP server running? It's been a 
while since I've dealt with FreeBSD...and then it was only trying to get 
it working on a RaQ3, which didn't work out too well.

-- 
Pete Stephenson
HeyPete.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Pete Stephenson wrote:
> In article <p062007a6bf450a7b3b72@[10.0.1.210]>,
>  brad@stop.mail-abuse.org (Brad Knowles) wrote:
> 
> 
>>	Nice little boxes.  See <http://www.soekris.com/net4501.htm>. 
>>The pricelist at <http://www.soekris.com/how_to_buy.htm> shows that, 
>>in quantities of one, board and case for a net4501 runs $177, plus 
>>power supply ($9-16, depending on model).  UPS ground shipping within 
>>the Continental US is free for orders over $130, but you pay extra if 
>>you want something else.
>>
>>
>>	But then, maybe this is a bit smaller than you had in mind.  ;-)
> 
> 
> That looks exactly like what I'm looking for.
> 
> Now, the question is how does one interface with it visually? Only via a 
> serial cable and a terminal emulator on a "host" PC? Doesn't look like 
> it has any capability for a monitor, keyboard, or other interfaces.
> 
> Otherwise, it sounds great. Anyone have any experience on how easy it is 
> to configure FreeBSD on them and get an NTP server running? It's been a 
> while since I've dealt with FreeBSD...and then it was only trying to get 
> it working on a RaQ3, which didn't work out too well.
> 


Pretty easy.  I'm running 4801's which take a laptop HD so I just
loaded FreeBSD on the drive on a PC then plugged it in (see phk's
sokeris page for the other changes you need to make).   The 4501 uses
CF cards and there are some CF image sites around (ask on the sokeris
mailing list).  You only need a serial cable until you have it booted
then you just ssh to it and do everything that way.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDH7cyaVyA7PElsKkRA5F/AKCaeGIYmXoEaaRVEu5Jcc6GJJQZFgCg9mS4
wKnVfv+IU+Ui7C6+wPV8ED4=
=R/vW
-----END PGP SIGNATURE-----

At 3:37 AM +0000 2005-09-08, Pete Stephenson wrote:

>  Now, the question is how does one interface with it visually? Only via a
>  serial cable and a terminal emulator on a "host" PC? Doesn't look like
>  it has any capability for a monitor, keyboard, or other interfaces.

	Serial cable and terminal emulator, up to the point where you get 
the OS installed and the network interface working, at which point 
you can use ssh or whatever to access the system via Ethernet.

>  Otherwise, it sounds great. Anyone have any experience on how easy it is
>  to configure FreeBSD on them and get an NTP server running? It's been a
>  while since I've dealt with FreeBSD...and then it was only trying to get
>  it working on a RaQ3, which didn't work out too well.

	For these things, the process of "burning" a configuration onto 
CompactFlash cards is pretty well known.  Everything depends on the 
size of card you have, what all features you want on the box, etc.... 
But there are pre-existing routines to handle the creation of the 
image on CompactFlash for you, once you've got the configuration 
decided.  IIRC, the Soekris website has some more information on this.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

In article <p062007a2bf4503c9a9cf@[10.0.1.210]>,
 brad@stop.mail-abuse.org (Brad Knowles) wrote:

> At 4:17 PM -0400 2005-09-07, Joshua Coombs wrote:
> 
> >  Using standard PC hardware, and no directly connected reference clocks
> >  as limitations, is there a general recommendation for OS on a box that
> >  will be dedicated to NTP?  My current background has me most comfortable
> >  with FreeBSD, but if using a true RTOS will give me any tangible
> >  improvements in the quality of time pushed out of these boxes (stratum
> >  issues not withstanding) then I'm willing to learn a new setup.
> 
> 	Choosing the right hardware platform, with the right kernel 
> configuration, Poul-Henning Kamp has gotten FreeBSD configurations 
> down to the nanosecond range for accuracy -- note that most of the 
> rest of us have to make do with accuracy down only as far as the 
> millisecond range.
> 
[snip]
> 
> 	You could probably do the same or somewhat better with an RTOS, 
> but the real kicker is that you have to be very careful with your 
> hardware and OS configuration -- just any random PC ain't gonna be 
> able to get you anywhere close to that level, no matter what the OS 
> looks like.

There is one trick that never gets mentioned: On OSs that support this, 
give the NTP daemon the highest realtime priority, exceeding even parts 
of the OS, rather than its usual default priority.  Making the daemon 
realtime greatly reduces interference from other activity in the 
computer, more or less eliminating the long tail of timing error 
excursions in practical systems.

I verified this as part of a US Navy funded investigation using Solaris 
something like ten years ago.  (Unfortunately, the report is not 
electronically available.)

Joe Gwinn

Joe Gwinn

Pete Stephenson wrote:

>In article <U_ydnaOtxYcnzYLeRVn-sQ@comcast.com>,
> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
>
>  
>
>>Free BSD will get the job done.   So will Solaris (also free these 
>>days).  Linux and Windows are poor choices for this application as both 
>>have a tendency to lose clock interrupts.
>>    
>>
>
>That's not the first time I've seen recommendations for FreeBSD, and I 
>promised myself I'd run the "next" NTP server I run on that OS.
>
>However, I need to get an el-cheapo PC to run FreeBSD -- my old Cobalt 
>RaQ3 finally bit the dust, and I was waiting for it to die before I'd 
>bother buying new hardware.
>
>Any advice for a relatively inexpensive, small PC? Rackmount's fine, but 
>it'd be sitting on it's side on my floor, so a small tower would work 
>well too. It would be running the NTP server, and optionally an HTTP 
>server serving a small informational website about it. Power consumption 
>should be low, as my electric bill is already quite high. I'm looking 
>for something <$300, and I don't need a monitor, keyboard, or 
>anything...just the computer.
>
>Cheers!
>
>  
>
PCs are relatively cheap these days.   An HP "micro tower" with 2.8GHz 
processor and 256MB, 40GB disk, etc. goes for just under 500 from PC 
Connection.

If you want really really cheap, ask the IT department where you work if 
you can have a discarded machine.  Since the company may well have to 
pay someone $5 or $10 to dispose of it, they might just be delighted to 
give you a 133 MHz Pentium.  Try trash picking!  An early morning cruise 
of the neighborhood on the day that trash is picked up might reveal a 
machine at curbside.  Or treat yourself to a new desktop and use the old 
one as an NTP server. 

In article <pete+usenet-A58DAA.14014407092005@typhoon.sonic.net>,
Pete Stephenson  <pete+usenet@heypete.com> wrote:
>In article <U_ydnaOtxYcnzYLeRVn-sQ@comcast.com>,
> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
>
>> Free BSD will get the job done.   So will Solaris (also free these 
>> days).  Linux and Windows are poor choices for this application as both 
>> have a tendency to lose clock interrupts.
>
>That's not the first time I've seen recommendations for FreeBSD, and I 
>promised myself I'd run the "next" NTP server I run on that OS.
>
>However, I need to get an el-cheapo PC to run FreeBSD -- my old Cobalt 
>RaQ3 finally bit the dust, and I was waiting for it to die before I'd 
>bother buying new hardware.
>
>Any advice for a relatively inexpensive, small PC? Rackmount's fine, but 
>it'd be sitting on it's side on my floor, so a small tower would work 
>well too. It would be running the NTP server, and optionally an HTTP 
>server serving a small informational website about it. Power consumption 
>should be low, as my electric bill is already quite high. I'm looking 
>for something <$300, and I don't need a monitor, keyboard, or 
>anything...just the computer.
>

I've run FreeBSD on very generic 486 systems.  You're not looking for
drivers for sound, modens, USB, or other newfangled stuff. Just the
basics.    

The power bill is an issue.  You also want it on a UPS, probably.  I'd
look for an old laptop. Teh battery probably has enough life in it to
last 30 minutes or so whish covers 99% of the unscheduled power
outages, at least in my part of the country. It's compact and draws
little power.  When you need to work on it you've got a decent kbd abd
screen right there.  A standard PC costs me about $10/month to run,
even with the monitor off.   

It should have all the CPU and memory and disk you need.  A pentium-1
should be fine but you may want to max out the memory. ALl you need is
a working ethernet card for it.








-- 
a d y k e s @ p a n i x . c o m 

Don't blame me. I voted for Gore.

In article <pete+usenet-5F22FB.20390007092005@typhoon.sonic.net>,
Pete Stephenson  <pete+usenet@heypete.com> wrote:
>In article <p062007a6bf450a7b3b72@[10.0.1.210]>,
> brad@stop.mail-abuse.org (Brad Knowles) wrote:
>
>> 	Nice little boxes.  See <http://www.soekris.com/net4501.htm>. 
>> The pricelist at <http://www.soekris.com/how_to_buy.htm> shows that, 
>> in quantities of one, board and case for a net4501 runs $177, plus 
>> power supply ($9-16, depending on model).  UPS ground shipping within 
>> the Continental US is free for orders over $130, but you pay extra if 
>> you want something else.
>> 
>> 
>> 	But then, maybe this is a bit smaller than you had in mind.  ;-)
>
>That looks exactly like what I'm looking for.
>
>Now, the question is how does one interface with it visually? Only via a 
>serial cable and a terminal emulator on a "host" PC? Doesn't look like 
>it has any capability for a monitor, keyboard, or other interfaces.
>
>Otherwise, it sounds great. Anyone have any experience on how easy it is 
>to configure FreeBSD on them and get an NTP server running? It's been a 
>while since I've dealt with FreeBSD...and then it was only trying to get 
>it working on a RaQ3, which didn't work out too well.
>

I've installed Linux on a soekris. It's popular as a 
proxy server for free wilress sites. I'm not recommending Linux but
the tricks to get it running may be similar and you may find links
to Freebsd soekris projects.   I think the soekris web site 
has lots of freebsd info, also. 

http://www.nycwireless.net/pebble/


The soekris will make a fine ntp server and it will run apache at the
same time but the soekris models I'm familiar are roughy a 64MB
486/100.  Not much disk space, either. I've heard of heat problems
when people try to put a hard disk inside the box.

I say get an old pentium-I laptop with some battery life left. 



-- 
a d y k e s @ p a n i x . c o m 

Don't blame me. I voted for Gore.

Joseph Gwinn wrote:
> In article <p062007a2bf4503c9a9cf@[10.0.1.210]>,
>  brad@stop.mail-abuse.org (Brad Knowles) wrote:
> 
> 
>>At 4:17 PM -0400 2005-09-07, Joshua Coombs wrote:
>>
>>
>>> Using standard PC hardware, and no directly connected reference clocks
>>> as limitations, is there a general recommendation for OS on a box that
>>> will be dedicated to NTP?  My current background has me most comfortable
>>> with FreeBSD, but if using a true RTOS will give me any tangible
>>> improvements in the quality of time pushed out of these boxes (stratum
>>> issues not withstanding) then I'm willing to learn a new setup.
>>
>>	Choosing the right hardware platform, with the right kernel 
>>configuration, Poul-Henning Kamp has gotten FreeBSD configurations 
>>down to the nanosecond range for accuracy -- note that most of the 
>>rest of us have to make do with accuracy down only as far as the 
>>millisecond range.
>>
> 
> [snip]
> 
>>	You could probably do the same or somewhat better with an RTOS, 
>>but the real kicker is that you have to be very careful with your 
>>hardware and OS configuration -- just any random PC ain't gonna be 
>>able to get you anywhere close to that level, no matter what the OS 
>>looks like.
> 
> 
> There is one trick that never gets mentioned: On OSs that support this, 
> give the NTP daemon the highest realtime priority, exceeding even parts 
> of the OS, rather than its usual default priority. 

I believe that NTP does this already in it's code.

Danny

  Making the daemon
> realtime greatly reduces interference from other activity in the 
> computer, more or less eliminating the long tail of timing error 
> excursions in practical systems.
> 
> I verified this as part of a US Navy funded investigation using Solaris 
> something like ten years ago.  (Unfortunately, the report is not 
> electronically available.)
> 
> Joe Gwinn
> 
> Joe Gwinn
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 


_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> Joseph Gwinn wrote:
[]
>> There is one trick that never gets mentioned: On OSs that support
>> this, give the NTP daemon the highest realtime priority, exceeding
>> even parts of the OS, rather than its usual default priority.
>
> I believe that NTP does this already in it's code.
>
> Danny

True for Windows 2000 and Windows XP.

David 

At 10:22 PM -0400 2005-09-10, Danny Mayer wrote:

>>  There is one trick that never gets mentioned: On OSs that support this,
>>  give the NTP daemon the highest realtime priority, exceeding even parts
>>  of the OS, rather than its usual default priority.
>
>  I believe that NTP does this already in it's code.

	It has the "-N" option, yes.  However, that is not used by 
default, although it can always be specified on the command line.

	What I believe that Joseph Gwinn was talking about was running at 
actual real-time priority (rtprio), which causes ntpd to actually run 
at higher priority than most parts of the OS itself, which is a 
feature that only some OSes support.  He is right that this can be 
very useful, and can help eliminate lost clock interrupts and other 
sources of internal jitter, although it is rarely necessary.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Brad Knowles wrote:
[]
> What I believe that Joseph Gwinn was talking about was running at
> actual real-time priority (rtprio), which causes ntpd to actually run
> at higher priority than most parts of the OS itself, which is a
> feature that only some OSes support.  He is right that this can be
> very useful, and can help eliminate lost clock interrupts and other
> sources of internal jitter, although it is rarely necessary.

If you run NTP so that other interrupts are lost, isn't that a potential 
source of problems?

David 

At 2:56 PM +0000 2005-09-11, David J Taylor wrote:

>  If you run NTP so that other interrupts are lost, isn't that a potential
>  source of problems?

	Yes, but you very rarely need to run at rtprio in order to avoid 
lost interrupts.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

In article <p06200715bf49e0aff7e0@[10.0.1.210]>,
 brad@stop.mail-abuse.org (Brad Knowles) wrote:

> At 10:22 PM -0400 2005-09-10, Danny Mayer wrote:
> 
> >>  There is one trick that never gets mentioned: On OSs that support this,
> >>  give the NTP daemon the highest realtime priority, exceeding even parts
> >>  of the OS, rather than its usual default priority.
> >
> >  I believe that NTP does this already in it's code.
> 
> 	It has the "-N" option, yes.  However, that is not used by 
> default, although it can always be specified on the command line.

At least in Solaris and IRIX, one needs special permissions to use true  
realtime priorities (where winner takes all), so the -N option by itself 
may not suffice.


> 	What I believe that Joseph Gwinn was talking about was running at 
> actual real-time priority (rtprio), which causes ntpd to actually run 
> at higher priority than most parts of the OS itself, which is a 
> feature that only some OSes support.  

You are correct; that is what I was talking about.

This can also be done with RTOSs like VxWorks. In one application ten 
years ago, we ran a homebrew NTP responder at realtime priority under 
VxWorks, answering polls from the NTP daemons in some workstations.  The 
NTP responder had direct hardware access to the system's master clock, 
and so was our Stratum 1.

I believe that the commercial GPS-based NTP time servers work the same 
way.


> He is right that this can be 
> very useful, and can help eliminate lost clock interrupts and other 
> sources of internal jitter, although it is rarely necessary.

Probability of necessity varies with application. 

Right now I have a problem with a closed network where the computer 
clocks sometimes get ten or twenty milliseconds out of synch, even 
though they usually stay within a millisecond or so.  The LANs are very 
lightly loaded, and the whole system would fit into a sphere 35 meters 
in diameter, so transport delay isn't the issue.

The problem is that other realtime activities (application code) in the 
various servers is kicking the NTP daemons sidewise during heavy system 
load.   The daemons are at default priority.  NTP cannot tell this from 
real transport delay, randomly asymmetrical delay at that, so a lot of 
really bad samples eventually leak through the median filter and corrupt 
NTP's notion of the time offset to the master clocks.   NTP is actually 
fairly resistant to this kind of abuse, but the application code is 
sufficiently overloaded that the necessary abuse is often arranged.

The immediate solution will have to be to promote the daemons to higher 
realtime priority than that of those interfering other activities, but 
the people responsible for those activities are likely to object (more 
from fear than from thought, but ... the pressure is on).  Or, just live 
with it.

Joe Gwinn

Joseph Gwinn wrote:

>In article <p06200715bf49e0aff7e0@[10.0.1.210]>,
> brad@stop.mail-abuse.org (Brad Knowles) wrote:
>
>  
>
>>At 10:22 PM -0400 2005-09-10, Danny Mayer wrote:
>>
>>    
>>
>>>> There is one trick that never gets mentioned: On OSs that support this,
>>>> give the NTP daemon the highest realtime priority, exceeding even parts
>>>> of the OS, rather than its usual default priority.
>>>>        
>>>>
>>> I believe that NTP does this already in it's code.
>>>      
>>>
>>	It has the "-N" option, yes.  However, that is not used by 
>>default, although it can always be specified on the command line.
>>    
>>
>
>At least in Solaris and IRIX, one needs special permissions to use true  
>realtime priorities (where winner takes all), so the -N option by itself 
>may not suffice.
>
>
>  
>
>>	What I believe that Joseph Gwinn was talking about was running at 
>>actual real-time priority (rtprio), which causes ntpd to actually run 
>>at higher priority than most parts of the OS itself, which is a 
>>feature that only some OSes support.  
>>    
>>
>
>You are correct; that is what I was talking about.
>
>This can also be done with RTOSs like VxWorks. In one application ten 
>years ago, we ran a homebrew NTP responder at realtime priority under 
>VxWorks, answering polls from the NTP daemons in some workstations.  The 
>NTP responder had direct hardware access to the system's master clock, 
>and so was our Stratum 1.
>
>I believe that the commercial GPS-based NTP time servers work the same 
>way.
>
>
>  
>
>>He is right that this can be 
>>very useful, and can help eliminate lost clock interrupts and other 
>>sources of internal jitter, although it is rarely necessary.
>>    
>>
>
>Probability of necessity varies with application. 
>
>Right now I have a problem with a closed network where the computer 
>clocks sometimes get ten or twenty milliseconds out of synch, even 
>though they usually stay within a millisecond or so.  The LANs are very 
>lightly loaded, and the whole system would fit into a sphere 35 meters 
>in diameter, so transport delay isn't the issue.
>
>The problem is that other realtime activities (application code) in the 
>various servers is kicking the NTP daemons sidewise during heavy system 
>load.   The daemons are at default priority.  NTP cannot tell this from 
>real transport delay, randomly asymmetrical delay at that, so a lot of 
>really bad samples eventually leak through the median filter and corrupt 
>NTP's notion of the time offset to the master clocks.   NTP is actually 
>fairly resistant to this kind of abuse, but the application code is 
>sufficiently overloaded that the necessary abuse is often arranged.
>
>The immediate solution will have to be to promote the daemons to higher 
>realtime priority than that of those interfering other activities, but 
>the people responsible for those activities are likely to object (more 
>from fear than from thought, but ... the pressure is on).  Or, just live 
>with it.
>
>Joe Gwinn
>  
>
If these servers are running Windows, there's little hope!

If they are running some flavor of Linux and the clock tick rate is set 
to 1000 Hz, it can be changed to 100 Hz and the kernel rebuilt.   This 
cuts the opportunity to lose interrupts by a factor of ten.

In article <8c-dnZ2dnZ39fdy0nZ2dnb_puN6dnZ2dRVn-yZ2dnZ0@comcast.com>,
 "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:

> Joseph Gwinn wrote:
> 
> >In article <p06200715bf49e0aff7e0@[10.0.1.210]>,
> > brad@stop.mail-abuse.org (Brad Knowles) wrote:
[snip]
> >Probability of necessity varies with application. 
> >
> >Right now I have a problem with a closed network where the computer 
> >clocks sometimes get ten or twenty milliseconds out of synch, even 
> >though they usually stay within a millisecond or so.  The LANs are very 
> >lightly loaded, and the whole system would fit into a sphere 35 meters 
> >in diameter, so transport delay isn't the issue.
> >
> >The problem is that other realtime activities (application code) in the 
> >various servers is kicking the NTP daemons sidewise during heavy system 
> >load.   The daemons are at default priority.  NTP cannot tell this from 
> >real transport delay, randomly asymmetrical delay at that, so a lot of 
> >really bad samples eventually leak through the median filter and corrupt 
> >NTP's notion of the time offset to the master clocks.   NTP is actually 
> >fairly resistant to this kind of abuse, but the application code is 
> >sufficiently overloaded that the necessary abuse is often arranged.
> >
> >The immediate solution will have to be to promote the daemons to higher 
> >realtime priority than that of those interfering other activities, but 
> >the people responsible for those activities are likely to object (more 
> >from fear than from thought, but ... the pressure is on).  Or, just live 
> >with it.
> >
> >Joe Gwinn
> >  
> >
> If these servers are running Windows, there's little hope!

True enough.  

But no; they are running SGI IRIX on the servers where the sideways 
kicking happens.  No Windows in this drama.


> If they are running some flavor of Linux and the clock tick rate is set 
> to 1000 Hz, it can be changed to 100 Hz and the kernel rebuilt.   This 
> cuts the opportunity to lose interrupts by a factor of ten.

Which helps, but isn't close to a solution.  There should be *no* lost 
timer interrupts.


Joe Gwinn

Joseph Gwinn wrote:

>In article <8c-dnZ2dnZ39fdy0nZ2dnb_puN6dnZ2dRVn-yZ2dnZ0@comcast.com>,
> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
>
>  
>
>>Joseph Gwinn wrote:
>>
>>    
>>
>>>In article <p06200715bf49e0aff7e0@[10.0.1.210]>,
>>>brad@stop.mail-abuse.org (Brad Knowles) wrote:
>>>      
>>>
>[snip]
>  
>
>>>Probability of necessity varies with application. 
>>>
>>>Right now I have a problem with a closed network where the computer 
>>>clocks sometimes get ten or twenty milliseconds out of synch, even 
>>>though they usually stay within a millisecond or so.  The LANs are very 
>>>lightly loaded, and the whole system would fit into a sphere 35 meters 
>>>in diameter, so transport delay isn't the issue.
>>>
>>>The problem is that other realtime activities (application code) in the 
>>>various servers is kicking the NTP daemons sidewise during heavy system 
>>>load.   The daemons are at default priority.  NTP cannot tell this from 
>>>real transport delay, randomly asymmetrical delay at that, so a lot of 
>>>really bad samples eventually leak through the median filter and corrupt 
>>>NTP's notion of the time offset to the master clocks.   NTP is actually 
>>>fairly resistant to this kind of abuse, but the application code is 
>>>sufficiently overloaded that the necessary abuse is often arranged.
>>>
>>>The immediate solution will have to be to promote the daemons to higher 
>>>realtime priority than that of those interfering other activities, but 
>>>the people responsible for those activities are likely to object (more 
>>>      
>>>
>>>from fear than from thought, but ... the pressure is on).  Or, just live 
>>    
>>
>>>with it.
>>>
>>>Joe Gwinn
>>> 
>>>
>>>      
>>>
>>If these servers are running Windows, there's little hope!
>>    
>>
>
>True enough.  
>
>But no; they are running SGI IRIX on the servers where the sideways 
>kicking happens.  No Windows in this drama.
>
>
>  
>
>>If they are running some flavor of Linux and the clock tick rate is set 
>>to 1000 Hz, it can be changed to 100 Hz and the kernel rebuilt.   This 
>>cuts the opportunity to lose interrupts by a factor of ten.
>>    
>>
>
>Which helps, but isn't close to a solution.  There should be *no* lost 
>timer interrupts.
>
>
>Joe Gwinn
>  
>
Then I think you need to talk to Silicon Graphics about it.  If it's a 
bug they may be able to patch it.  If, as seems likely, it's an O/S 
design issue, the fix may require a lot of time and resources.

In article <5M-dnfDyh5qKubreRVn-rA@comcast.com>,
 "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:

> Joseph Gwinn wrote:
> 
> >In article <8c-dnZ2dnZ39fdy0nZ2dnb_puN6dnZ2dRVn-yZ2dnZ0@comcast.com>,
> > "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
> >
> >  
> >
> >>Joseph Gwinn wrote:
> >>
> >>    
> >>
> >>>In article <p06200715bf49e0aff7e0@[10.0.1.210]>,
> >>>brad@stop.mail-abuse.org (Brad Knowles) wrote:
> >>>      
> >>>
> >[snip]
> >  
> >
> >>>Probability of necessity varies with application. 
> >>>
> >>>Right now I have a problem with a closed network where the computer 
> >>>clocks sometimes get ten or twenty milliseconds out of synch, even 
> >>>though they usually stay within a millisecond or so.  The LANs are very 
> >>>lightly loaded, and the whole system would fit into a sphere 35 meters 
> >>>in diameter, so transport delay isn't the issue.
> >>>
> >>>The problem is that other realtime activities (application code) in the 
> >>>various servers is kicking the NTP daemons sidewise during heavy system 
> >>>load.   The daemons are at default priority.  NTP cannot tell this from 
> >>>real transport delay, randomly asymmetrical delay at that, so a lot of 
> >>>really bad samples eventually leak through the median filter and corrupt 
> >>>NTP's notion of the time offset to the master clocks.   NTP is actually 
> >>>fairly resistant to this kind of abuse, but the application code is 
> >>>sufficiently overloaded that the necessary abuse is often arranged.
> >>>
> >>>The immediate solution will have to be to promote the daemons to higher 
> >>>realtime priority than that of those interfering other activities, but 
> >>>the people responsible for those activities are likely to object (more 
> >>>      
> >>>
> >>>from fear than from thought, but ... the pressure is on).  Or, just live 
> >>    
> >>
> >>>with it.
> >>>
> >>>Joe Gwinn
> >>> 
> >>>
> >>>      
> >>>
> >>If these servers are running Windows, there's little hope!
> >>    
> >>
> >
> >True enough.  
> >
> >But no; they are running SGI IRIX on the servers where the sideways 
> >kicking happens.  No Windows in this drama.
> >
> >
> >  
> >
> >>If they are running some flavor of Linux and the clock tick rate is set 
> >>to 1000 Hz, it can be changed to 100 Hz and the kernel rebuilt.   This 
> >>cuts the opportunity to lose interrupts by a factor of ten.
> >>    
> >>
> >
> >Which helps, but isn't close to a solution.  There should be *no* lost 
> >timer interrupts.
> >
> >
> >Joe Gwinn
> >  
> >
> Then I think you need to talk to Silicon Graphics about it.  If it's a 
> bug they may be able to patch it.  If, as seems likely, it's an O/S 
> design issue, the fix may require a lot of time and resources.

The lost interrupts were in Linux, not IRIX (which appears to have a 
1024-Hz RT timer interrupt).  I was reacting to the proposal that one 
drop the timer interrupt rate in Linux: while this will certainly reduce 
the number of lost interrupts, the root problem remains uncorrected.

Joe Gwinn

Joe