david.lindauer@honeywell.com wrote:
[]
> Finally, are those equations for round trip time and propagation delay
> in RFC2030 actually correct? They aren't what I would expect, and
> don't even seem to match each other.

No, they are in error.

David

>>> In article <1155648559.784059.118920@75g2000cwc.googlegroups.c om>, david.lindauer@honeywell.com writes:

david> I've got a question about the rationale behind the SNTP RFC2030.
david> Basically, a valid SNTP server is supposed to be sourced directly
david> from a reference, never from a remote NTP server. We believe this is
david> because of the lack of sophisticated algorithms as found in NTP; e.g.
david> sourcing an SNTP server from an NTP server is going to be inherently
david> less accurate. Is that the gist of it, or is there other rationale
david> as well?

Yes, to the best of my knowledge.

david> Also, assuming an SNTP client is doing similar to the spec and
david> aliasing the server time with a calculated propagation delay, and
david> assuming a LAN rather than the internet at large, can anyone give a
david> general feel for how far off the client is going to be from its
david> server?

It depends on how good the system clock is and how often sntp polls.

david> Finally, are those equations for round trip time and propagation
david> delay in RFC2030 actually correct? They aren't what I would expect,
david> and don't even seem to match each other.

Please see the updated/newer RFC:

http://ntp.isc.org/Support/NTPRelatedRFCs

H

Harlan Stenn wrote:
> >>> In article <1155648559.784059.118920@75g2000cwc.googlegroups.c om>, david.lindauer@honeywell.com writes:
> david> Also, assuming an SNTP client is doing similar to the spec and
> david> aliasing the server time with a calculated propagation delay, and
> david> assuming a LAN rather than the internet at large, can anyone give a
> david> general feel for how far off the client is going to be from its
> david> server?
>
> It depends on how good the system clock is and how often sntp polls.

thanks. We aren't looking for performance extremes... Would it be
reasonable to get an accuracy within several seconds, feeding sntp
clients on a lan from an sntp server which itself was fed from an NTP
server on the net? Assuming a local clock which is nominally 60 ticks
per second? And assuming the polls on both ends could be done often
enough to account for local clock drifts?

and thanks for the updated RFC...

david.lindauer@honeywell.com wrote:
> Harlan Stenn wrote:
>
>>>>>In article <1155648559.784059.118920@75g2000cwc.googlegroups.c om>, david.lindauer@honeywell.com writes:
>>
>>david> Also, assuming an SNTP client is doing similar to the spec and
>>david> aliasing the server time with a calculated propagation delay, and
>>david> assuming a LAN rather than the internet at large, can anyone give a
>>david> general feel for how far off the client is going to be from its
>>david> server?
>>
>>It depends on how good the system clock is and how often sntp polls.
>
>
> thanks. We aren't looking for performance extremes... Would it be
> reasonable to get an accuracy within several seconds, feeding sntp
> clients on a lan from an sntp server which itself was fed from an NTP
> server on the net? Assuming a local clock which is nominally 60 ticks
> per second? And assuming the polls on both ends could be done often
> enough to account for local clock drifts?
>
> and thanks for the updated RFC...
>

W32TIME is good enough to keep things synched up within a second or two.
That's good enough for many applications. It seems to query a server
somewhere between once an hour and once a week and does not place a
heavy load on a server. If it meets your requirements, you don't need
to do more.

Using an SNTP client as a server is not recommended but if it works for
you, use it. If you have doubts, it's not terribly difficult to set up
a true NTP server although I've never done it on Windoze. I have a Sun
Solaris system in that role.

>thanks. We aren't looking for performance extremes... Would it be
>reasonable to get an accuracy within several seconds, feeding sntp
>clients on a lan from an sntp server which itself was fed from an NTP
>server on the net? Assuming a local clock which is nominally 60 ticks
>per second? And assuming the polls on both ends could be done often
>enough to account for local clock drifts?

That depends on how often you poll and how much your clock drifts.

"several seconds" is a long time relative to round-trip delays to
a nearby time server. Let's ignore those delays for now.

Several PCs I have access to are off by slighly more than 100 ppm.
There are 86K seconds per day. Call it 100K. So a crystal error of
10 ppm would turn into a clock error of one second per day.

So you would have to poll 10 times per day - once every 2 hours.

Back to network delays. Does your link to the outside world get
overloaded at times? That may confuse things.

--
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 wrote:
>
> That depends on how often you poll and how much your clock drifts.
>
> "several seconds" is a long time relative to round-trip delays to
> a nearby time server. Let's ignore those delays for now.
>
> Several PCs I have access to are off by slighly more than 100 ppm.
> There are 86K seconds per day. Call it 100K. So a crystal error of
> 10 ppm would turn into a clock error of one second per day.
>
> So you would have to poll 10 times per day - once every 2 hours.
>
> Back to network delays. Does your link to the outside world get
> overloaded at times? That may confuse things.
>
yes that pretty much agrees with our notion of PC clocks... although
some of what we get is much worse.

Our main concern is that the clocks at the lowest tier agree with each
other within a couple of seconds... the real time isn't quite so
important but we are trying to get a feel for whether we can keep them
reasonably close to the real time without a full NTP client in our part
of the system. Reasonably close being within a few seconds, and this
assuming there aren't local network problems with polling once an hour.


This is just one possible configuration... there are other
configurations we are considering some of which are more accurate than
this and some less...

Try it. If it works, great. If not, your choices include running sntp more
often or running ntpd.

H

>Try it. If it works, great. If not, your choices include running sntp more
>often or running ntpd.

Another thing to consider is calibrating the drift.

Let it run for a week or so and see how much it has drifted.
Then do the math to figure out the fudge-factor you need.
I think there is some program to set it, but I don't remember
the name.

The idea is to correct for the manufacturering error in the
crystal. That doesn't cover temperature variations, but it
will many a huge difference on many systems.


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