Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > Hello, > > I've been running ntpd 4.2.4 to synchronize my system clock using remote > stratum 2 servers as a reference. (The RTT to these servers is in the > 30-50 ms range.) The accuracy is in the 1-2 ms range, based on the > reported offset. > > I've been asked to evaluate the following time server, in order to reach > a better accuracy than what the current setup provides. > > http://www.heoldesign.com/index.php?id=58 > That link takes me to a page advertising THREE products! Which one did you have in mind? > (AFAIU, this time server implements SNTP, not the full NTP.) > > The idea would be to put this (stratum 1) time server in the same LAN as > my box, and add it my ntp.conf. (The RTT on the LAN is on the order of > 100 µs.) > > Will it work? > It should work. > Is it a problem that the time server only implements SNTP? > It should not be a problem. The largest difference between NTP and SNTP is the effort to account for the vagaries of the internet! > What kind of accuracy may I expect? > These devices should be accurate to within the range of 25 to 100 nanoseconds. The limiting factor will be the jitter introduced while getting the time into your computer. A SWAG (Scientific Wild Ass Guess) would be 500 microseconds. By spending a lot of time and effort you might be able to get something better than that. The chief difficulty would be measuring and controlling the delays within the computer. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Richard B. Gilbert wrote: > Noob wrote: > >> I've been running ntpd 4.2.4 to synchronize my system clock using >> remote stratum 2 servers as a reference. (The RTT to these servers is >> in the 30-50 ms range.) The accuracy is in the 1-2 ms range, based on >> the reported offset. >> >> I've been asked to evaluate the following time server, in order to >> reach a better accuracy than what the current setup provides. >> >> http://www.heoldesign.com/index.php?id=58 > > That link takes me to a page advertising THREE products! Which one did > you have in mind? The HEOL-T101 (with a Fast Ethernet port). >> Is it a problem that the time server only implements SNTP? > > It should not be a problem. The largest difference between NTP and SNTP > is the effort to account for the vagaries of the internet! Cool. (I'll give RFC 4330 a look.) >> What kind of accuracy may I expect? > > These devices should be accurate to within the range of 25 to 100 > nanoseconds. The spec seems to mention +/- 40 ns. > The limiting factor will be the jitter introduced while > getting the time into your computer. I plan to connect my box to the time server using a cross-over cable. (My box has 4 Ethernet ports, I will devote one to NTP traffic.) The RTT is very stable at 80-85 µs. > A SWAG (Scientific Wild Ass Guess) would be 500 microseconds. By > spending a lot of time and effort you might be able to get something > better than that. The chief difficulty would be measuring and > controlling the delays within the computer. I thought the error was on the order of half the RTT, i.e. I could hope for 40-50 µs in my situation? Regards. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > I'll give RFC 4330 a look. http://tools.ietf.org/html/rfc4330 David Mills wrote: "SNTP servers should operate only at the root (stratum 1) of the subnet, and then only in configurations where no other source of synchronization other than a reliable radio clock or telephone modem is available." Is a GPS receiver considered a reliable radio clock? Regards. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > Richard B. Gilbert wrote: > >> Noob wrote: >> >>> I've been running ntpd 4.2.4 to synchronize my system clock using >>> remote stratum 2 servers as a reference. (The RTT to these servers is >>> in the 30-50 ms range.) The accuracy is in the 1-2 ms range, based on >>> the reported offset. >>> >>> I've been asked to evaluate the following time server, in order to >>> reach a better accuracy than what the current setup provides. >>> >>> http://www.heoldesign.com/index.php?id=58 >> >> >> That link takes me to a page advertising THREE products! Which one >> did you have in mind? > > > The HEOL-T101 (with a Fast Ethernet port). > >>> Is it a problem that the time server only implements SNTP? >> >> >> It should not be a problem. The largest difference between NTP and >> SNTP is the effort to account for the vagaries of the internet! > > > Cool. (I'll give RFC 4330 a look.) > >>> What kind of accuracy may I expect? >> >> >> These devices should be accurate to within the range of 25 to 100 >> nanoseconds. > > > The spec seems to mention +/- 40 ns. > >> The limiting factor will be the jitter introduced while getting the >> time into your computer. > > > I plan to connect my box to the time server using a cross-over cable. > (My box has 4 Ethernet ports, I will devote one to NTP traffic.) The RTT > is very stable at 80-85 µs. > >> A SWAG (Scientific Wild Ass Guess) would be 500 microseconds. By >> spending a lot of time and effort you might be able to get something >> better than that. The chief difficulty would be measuring and >> controlling the delays within the computer. > > > I thought the error was on the order of half the RTT, i.e. I could hope > for 40-50 µs in my situation? > > Regards. Given the above, you are correct, 40-50 microseconds. I had assumed that you were using a serial port where the latencies are greater. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > Noob wrote: > >> I'll give RFC 4330 a look. > > > http://tools.ietf.org/html/rfc4330 > > David Mills wrote: > > "SNTP servers should operate only at the root (stratum 1) of the subnet, > and then only in configurations where no other source of synchronization > other than a reliable radio clock or telephone modem is available." > > Is a GPS receiver considered a reliable radio clock? Yes. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > > I've been running ntpd 4.2.4 to synchronize my system clock using remote > stratum 2 servers as a reference. (The RTT to these servers is in the > 30-50 ms range.) The accuracy is in the 1-2 ms range, based on the > reported offset. Offset doesn't tell you the accuracy, it only gives you an idea of the variability of the error. Theoretically, the error could be as much as 15 to 25ms, plus the error from the stratum one to the stratum 2. > > I've been asked to evaluate the following time server, in order to reach > a better accuracy than what the current setup provides. > > http://www.heoldesign.com/index.php?id=58 > > (AFAIU, this time server implements SNTP, not the full NTP.) There are many network timeservers that implement full NTP, so I'm not sure what they are doing with just SNTP; maybe it is aimed at the Windows w32time market. Also, you can use a GPS timing receiver, with 1pps output, directly. > > The idea would be to put this (stratum 1) time server in the same LAN as > my box, and add it my ntp.conf. (The RTT on the LAN is on the order of > 100 µs.) > > Will it work? It's a violation of NTP, so you the result will only be compliant as an SNTP client. It may or may not work, depending on whether or not early w32time implementations conformed to SNTP. Early versions of w32time didn't set enough of the response fields to sensible values to guarantee that ntpd would work as a client. > > Is it a problem that the time server only implements SNTP? > > What kind of accuracy may I expect? If it works, you can probably expect most of the errors to be within your box. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
David Woolley <[EMAIL PROTECTED]> writes: >Noob wrote: >>=20 >> I've been running ntpd 4.2.4 to synchronize my system clock using remot= >e=20 >> stratum 2 servers as a reference. (The RTT to these servers is in the=20 >> 30-50 ms range.) The accuracy is in the 1-2 ms range, based on the=20 >> reported offset. >Offset doesn't tell you the accuracy, it only gives you an idea of the=20 >variability of the error. Theoretically, the error could be as much as=20 >15 to 25ms, plus the error from the stratum one to the stratum 2. Agreed. The accuracy is bounded by the round trip time. The offset fluctuations will give and estimate of those variations in round trip time. But that time could be biased (ie outbound packets always take 10ms moere than inbound packets for example) and your clock would be biased. It is highly unlikely that packets take zero time to go out and 50ms to get back however. >>=20 >> I've been asked to evaluate the following time server, in order to reac= >h=20 >> a better accuracy than what the current setup provides. You are not going to get better accuracy by changing ntp program (well the evidence is that chrony is a somewhat better client, but in your case the difference will be negligible) . YOu are going to get a better time by using a server that is closer to you and has more predictable round trip times (ethernet, not ADSL) going to get better accuracy >>=20 >> http://www.heoldesign.com/index.php?id=3D58 >>=20 >> (AFAIU, this time server implements SNTP, not the full NTP.) Then it is not a server. >There are many network timeservers that implement full NTP, so I'm not=20 >sure what they are doing with just SNTP; maybe it is aimed at the=20 >Windows w32time market. >Also, you can use a GPS timing receiver, with 1pps output, directly. Yes. IF you want better accuracy, get yourself a Garmin 18LVC, wire it up and use the PPM output. They you will have a few microsecond accuracy. YOu will never get your network ntp under a few ms. >>=20 >> The idea would be to put this (stratum 1) time server in the same LAN a= >s=20 >> my box, and add it my ntp.conf. (The RTT on the LAN is on the order of = It is NOT a stratum 1. A stratum 1 gets its time from an atomic clock. It you attach a GPS to one of your (Linux) machines, you will get 2usec accuracy on that machine. On the machines attached on your lan yyou will get 10s of usec accuracy, if they are unix type machines. As far as I know windows does not impliment a proper clock control API so you will have be happy with a few msec for those. >> 100 =B5s.) >>=20 >> Will it work? >It's a violation of NTP, so you the result will only be compliant as an=20 >SNTP client. It may or may not work, depending on whether or not early=20 >w32time implementations conformed to SNTP. Early versions of w32time=20 >didn't set enough of the response fields to sensible values to guarantee = >that ntpd would work as a client. >>=20 >> Is it a problem that the time server only implements SNTP? >>=20 >> What kind of accuracy may I expect? >If it works, you can probably expect most of the errors to be within=20 >your box. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
David Woolley wrote: > Noob wrote: > >> I've been running ntpd 4.2.4 to synchronize my system clock using >> remote stratum 2 servers as a reference. (The RTT to these servers is >> in the 30-50 ms range.) The accuracy is in the 1-2 ms range, based on >> the reported offset. > > Offset doesn't tell you the accuracy, it only gives you an idea of the > variability of the error. Theoretically, the error could be as much as > 15 to 25ms, plus the error from the stratum one to the stratum 2. What metric should I consider to determine accuracy? # ntpq -crv assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg, version="ntpd [EMAIL PROTECTED] Fri Mar 16 10:45:43 UTC 2007 (1)", processor="i686", system="Linux/2.6.22.1-rt9", leap=00, stratum=2, precision=-20, rootdelay=46.299, rootdispersion=17.260, peer=18760, refid=134.226.81.3, reftime=cb88c64c.edb1a310 Mon, Mar 17 2008 10:28:28.928, poll=8, clock=cb88c77e.ef7df269 Mon, Mar 17 2008 10:33:34.935, state=4, offset=-0.295, frequency=-6.442, jitter=0.291, noise=0.248, stability=0.001 09:07:02: offset -0.000288 sec freq -6.433 ppm error 0.000453 poll 8 09:14:02: offset -0.000712 sec freq -6.436 ppm error 0.000431 poll 8 09:21:02: offset -0.000551 sec freq -6.437 ppm error 0.000418 poll 8 09:28:02: offset -0.000551 sec freq -6.437 ppm error 0.000422 poll 8 09:35:02: offset -0.000539 sec freq -6.438 ppm error 0.000415 poll 8 09:42:02: offset -0.000347 sec freq -6.439 ppm error 0.000856 poll 8 09:49:02: offset -0.000389 sec freq -6.440 ppm error 0.000597 poll 8 09:56:02: offset -0.000389 sec freq -6.440 ppm error 0.000874 poll 8 10:03:02: offset -0.39 sec freq -6.441 ppm error 0.000793 poll 8 10:10:02: offset -0.39 sec freq -6.441 ppm error 0.000402 poll 8 10:17:02: offset -0.39 sec freq -6.441 ppm error 0.000402 poll 8 10:24:02: offset -0.39 sec freq -6.441 ppm error 0.000368 poll 8 10:31:02: offset -0.000295 sec freq -6.442 ppm error 0.000291 poll 8 10:38:02: offset -0.000295 sec freq -6.442 ppm error 0.000167 poll 8 10:45:02: offset -0.000295 sec freq -6.442 ppm error 0.000417 poll 8 10:52:02: offset -0.000313 sec freq -6.443 ppm error 0.000349 poll 8 10:59:02: offset -0.000103 sec freq -6.444 ppm error 0.000312 poll 8 11:06:02: offset -0.000103 sec freq -6.444 ppm error 0.000285 poll 8 11:13:02: offset -0.000103 sec freq -6.444 ppm error 0.000255 poll 8 11:20:02: offset -0.000103 sec freq -6.444 ppm error 0.000340 poll 8 >> I've been asked to evaluate the following time server, in order to >> reach a better accuracy than what the current setup provides. >> >> http://www.heoldesign.com/index.php?id=58 >> >> (AFAIU, this time server implements SNTP, not the full NTP.) > > There are many network timeservers that implement full NTP, so I'm not > sure what they are doing with just SNTP; maybe it is aimed at the > Windows w32time market. Maybe they just need a clue? :-) > Also, you can use a GPS timing receiver, with 1 pps output, directly. My system is running a Linux kernel patched with real-time support. I don't feel confident applying the PPS support patch on top of it. >> The idea would be to put this (stratum 1) time server in the same LAN >> as my box, and add it my ntp.conf. (The RTT on the LAN is on the order >> of 100 µs.) >> >> Will it work? > > It's a violation of NTP, so the result will only be compliant as an > SNTP client. What is a violation of NTP? > It may or may not work, depending on whether or not early > w32time implementations conformed to SNTP. Early versions of w32time > didn't set enough of the response fields to sensible values to guarantee > that ntpd would work as a client. Why do you mention w32time? Do you think the HEOL-T101 is running Windows? >> What kind of accuracy may I expect? > > If it works, you can probably expect most of the errors to be within > your box. Does this mean it is reasonable to expect 100 µs accuracy? Regards. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Hello Bill, (Your news client often adds an extraneous =20 suffix to quotes.) Bill Unruh wrote: > David Woolley wrote: > >> Noob wrote: >> >>> I've been running ntpd 4.2.4 to synchronize my system clock using remote >>> stratum 2 servers as a reference. (The RTT to these servers is in the >>> 30-50 ms range.) The accuracy is in the 1-2 ms range, based on the >>> reported offset. >> >> Offset doesn't tell you the accuracy, it only gives you an idea of the >> variability of the error. Theoretically, the error could be as much as >> 15 to 25ms, plus the error from the stratum one to the stratum 2. > > Agreed. The accuracy is bounded by the round trip time. The offset > fluctuations will give and estimate of those variations in round trip time. > But that time could be biased (ie outbound packets always take 10ms more > than inbound packets for example) and your clock would be biased. Point taken. >>> I've been asked to evaluate the following time server, in order to reach >>> a better accuracy than what the current setup provides. > > You are not going to get better accuracy by changing ntp program You have apparently misread my original post. I do not plan to change ntpd. > You are going to get a better time by using a server that is closer to > you and has more predictable round trip times (ethernet, not ADSL) This is precisely what I plan to do. Specifically, I plan to connect my box to the time server using a cross-over Ethernet cable. (My box has 4 gigabit Ethernet ports, I will devote one to NTP traffic.) The RTT is very stable at 80-85 µs. >>> (AFAIU, this time server implements SNTP, not the full NTP.) > > Then it is not a server. I don't understand the point you are trying to make. It is an SNTP server. > You will never get your network ntp under a few ms. Unless the stratum 1 server is on the same LAN... (As you state later.) >>> The idea would be to put this (stratum 1) time server in the same LAN as >>> my box, and add it my ntp.conf. (The RTT on the LAN is on the order of > > It is NOT a stratum 1. > A stratum 1 gets its time from an atomic clock. I don't understand the point you are trying to make. The time server has a GPS receiver, thus it is "attached" to a stratum 0 device, thus it is a stratum 1 server. > If you attach a GPS to one of your (Linux) machines, you will get 2 µs > accuracy on that machine. On the machines attached on your LAN you will > get 10s of µs accuracy, if they are unix type machines. This is the setup I've been discussing, with the GPS receiver inside the "time server" I'm supposed to evaluate... > As far as I know > windows does not impliment a proper clock control API so you will have be > happy with a few msec for those. I should have made clear that I am not using Windows. The system to be synchronized runs Linux 2.6.22.1-rt9 and ntpd 4.2.4 Regards. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: >> Offset doesn't tell you the accuracy, it only gives you an idea of the >> variability of the error. Theoretically, the error could be as much >> as 15 to 25ms, plus the error from the stratum one to the stratum 2. > > What metric should I consider to determine accuracy? You cannot measure that using ntpd itself. If you really need to know the accuracy, you must measure the true time with something with lower error bounds and compare. The error should be somewhere within about +/- (rootdelay/2 + rootdispersion + jitter), if I remember correctly. Most of the time it will be much better than this, but you need to know the limits of asymmetry in your network round trip time and the worst case frequency errors, if you want a better figure. The basic problem is that, if ntpd knew the error, it would compensate for it and that part of the error would no longer be part of the error! With your figures, I would guess that the rootdispersion contribution is low, so the real question is how much propagation delay asymmetry there is. >> It's a violation of NTP, so the result will only be compliant as an >> SNTP client. > > What is a violation of NTP? NTP clients must use NTP servers, not SNTP ones. > >> It may or may not work, depending on whether or not early w32time >> implementations conformed to SNTP. Early versions of w32time didn't >> set enough of the response fields to sensible values to guarantee that >> ntpd would work as a client. > > Why do you mention w32time? Because w32time claims to be SNTP and I've seen cases where ntpd will refuse to synchronise to it because it is reporting error metrics that exceed maximums, even though it has got an upstream time source. (If I remember correctly, it was reflecting those in the request.) > > Do you think the HEOL-T101 is running Windows? It's running SNTP and w32time is the most commonly encountered implementation claiming to be SNTP, these days, so w32time is a model of what can go wrong when using SNTP. >> If it works, you can probably expect most of the errors to be within >> your box. > > Does this mean it is reasonable to expect 100 µs accuracy? For ethernet communicated time, one typically expects 1ms to 2ms. However, you need to know network loading (a properly dimensioned ethernet will have significant latency due to contention) and interrupt and process scheduling latencies on both sides. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > Hello Bill, > > (Your news client often adds an extraneous =20 suffix to quotes.) That happens when you reply to a MIME Quoted-Printable posting that has trailing spaces, using a user agent that doesn't understand MIME. Mine will have trailing spaced so that suitable clients will treat the newline as soft, and ones that don't will insert a newline at a sensible position. (Many GUI user agents try to put whole paragraphs on one line, which is simply broken. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob <[EMAIL PROTECTED]> writes: >David Woolley wrote: >> Noob wrote: >> >>> I've been running ntpd 4.2.4 to synchronize my system clock using >>> remote stratum 2 servers as a reference. (The RTT to these servers is >>> in the 30-50 ms range.) The accuracy is in the 1-2 ms range, based on >>> the reported offset. >> >> Offset doesn't tell you the accuracy, it only gives you an idea of the >> variability of the error. Theoretically, the error could be as much as >> 15 to 25ms, plus the error from the stratum one to the stratum 2. >What metric should I consider to determine accuracy? The round trip time is an upper bound on the accuracy. The problem is that the delay can be very asymmetric-- the outbound packet could take 29ms to get there and teh return 1ms. While unlikely, DSL for example IS assymmetric. at the tenths of a msec range. There is no way of knowing with ntp whether or not the trip is asymetric. Ie, while there is an upper bound on accuracy, there is no metric which measures actual accuracy. ># ntpq -crv >assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg, >version="ntpd [EMAIL PROTECTED] Fri Mar 16 10:45:43 UTC 2007 (1)", >processor="i686", system="Linux/2.6.22.1-rt9", leap=00, stratum=2, >precision=-20, rootdelay=46.299, rootdispersion=17.260, peer=18760, >refid=134.226.81.3, >reftime=cb88c64c.edb1a310 Mon, Mar 17 2008 10:28:28.928, poll=8, >clock=cb88c77e.ef7df269 Mon, Mar 17 2008 10:33:34.935, state=4, >offset=-0.295, frequency=-6.442, jitter=0.291, noise=0.248, >stability=0.001 >09:07:02: offset -0.000288 sec freq -6.433 ppm error 0.000453 poll 8 >09:14:02: offset -0.000712 sec freq -6.436 ppm error 0.000431 poll 8 >09:21:02: offset -0.000551 sec freq -6.437 ppm error 0.000418 poll 8 >09:28:02: offset -0.000551 sec freq -6.437 ppm error 0.000422 poll 8 >09:35:02: offset -0.000539 sec freq -6.438 ppm error 0.000415 poll 8 >09:42:02: offset -0.000347 sec freq -6.439 ppm error 0.000856 poll 8 >09:49:02: offset -0.000389 sec freq -6.440 ppm error 0.000597 poll 8 >09:56:02: offset -0.000389 sec freq -6.440 ppm error 0.000874 poll 8 >10:03:02: offset -0.39 sec freq -6.441 ppm error 0.000793 poll 8 >10:10:02: offset -0.39 sec freq -6.441 ppm error 0.000402 poll 8 >10:17:02: offset -0.39 sec freq -6.441 ppm error 0.000402 poll 8 >10:24:02: offset -0.39 sec freq -6.441 ppm error 0.000368 poll 8 >10:31:02: offset -0.000295 sec freq -6.442 ppm error 0.000291 poll 8 >10:38:02: offset -0.000295 sec freq -6.442 ppm error 0.000167 poll 8 >10:45:02: offset -0.000295 sec freq -6.442 ppm error 0.000417 poll 8 >10:52:02: offset -0.000313 sec freq -6.443 ppm error 0.000349 poll 8 >10:59:02: offset -0.000103 sec freq -6.444 ppm error 0.000312 poll 8 >11:06:02: offset -0.000103 sec freq -6.444 ppm error 0.000285 poll 8 >11:13:02: offset -0.000103 sec freq -6.444 ppm error 0.000255 poll 8 >11:20:02: offset -0.000103 sec freq -6.444 ppm error 0.000340 poll 8 >>> I've been asked to evaluate the following time server, in order to >>> reach a better accuracy than what the current setup provides. >>> >>> http://www.heoldesign.com/index.php?id=58 >>> >>> (AFAIU, this time server implements SNTP, not the full NTP.) >> >> There are many network timeservers that implement full NTP, so I'm not >> sure what they are doing with just SNTP; maybe it is aimed at the >> Windows w32time market. >Maybe they just need a clue? :-) sorry, but using an SNTP as a server is idiotic. It is designed as a client. Just use ntp as a server. >> Also, you can use a GPS timing receiver, with 1 pps output, directly. >My system is running a Linux kernel patched with real-time support. >I don't feel confident applying the PPS support patch on top of it. No need. Just attach the gps as a refclock. The kernel does not need pps support to use the refclock. >>> The idea would be to put this (stratum 1) time server in the same LAN >>> as my box, and add it my ntp.conf. (The RTT on the LAN is on the order >>> of 100 µs.) >>> >>> Will it work? >> >> It's a violation of NTP, so the result will only be compliant as an >> SNTP client. >What is a violation of NTP? SNTP is a client protocol, not a server, according to RFC. >> It may or may not work, depending on whether or not early >> w32time implementations conformed to SNTP. Early versions of w32time >> didn't set enough of the response fields to sensible values to guarantee >> that ntpd would work as a client. >Why do you mention w32time? >Do you think the HEOL-T101 is running Windows? We have absolutely no idea what you are running on all your machines. You never told us. This was an assumption based on the weird conditions you stated. It really really helps if you give information when you ask for help so that the help may actually be helpful. Tell us what your system is, what "SNTP program" you are using as the server, what the other client machines on the lan are running. >>> What kind of accuracy may I expe
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob <[EMAIL PROTECTED]> writes: >Hello Bill, >(Your news client often adds an extraneous =20 suffix to quotes.) Nope, that is your new client. Mine is a primative ascii based client which just reports what it sees. No special encoding is needed for a blank. >Bill Unruh wrote: >> David Woolley wrote: >> >>> Noob wrote: >>> I've been running ntpd 4.2.4 to synchronize my system clock using remote stratum 2 servers as a reference. (The RTT to these servers is in the 30-50 ms range.) The accuracy is in the 1-2 ms range, based on the reported offset. >>> >>> Offset doesn't tell you the accuracy, it only gives you an idea of the >>> variability of the error. Theoretically, the error could be as much as >>> 15 to 25ms, plus the error from the stratum one to the stratum 2. >> >> Agreed. The accuracy is bounded by the round trip time. The offset >> fluctuations will give and estimate of those variations in round trip time. >> But that time could be biased (ie outbound packets always take 10ms more >> than inbound packets for example) and your clock would be biased. >Point taken. I've been asked to evaluate the following time server, in order to reach a better accuracy than what the current setup provides. >> >> You are not going to get better accuracy by changing ntp program >You have apparently misread my original post. I do not plan to change >ntpd. >> You are going to get a better time by using a server that is closer to >> you and has more predictable round trip times (ethernet, not ADSL) >This is precisely what I plan to do. Specifically, I plan to connect >my box to the time server using a cross-over Ethernet cable. (My box >has 4 gigabit Ethernet ports, I will devote one to NTP traffic.) The >RTT is very stable at 80-85 µs. That does not help if the server does not have good time. Where does it gets its time from? (AFAIU, this time server implements SNTP, not the full NTP.) >> >> Then it is not a server. >I don't understand the point you are trying to make. >It is an SNTP server. AFAIK, SNTP is a CLIENT protocol, not a server. That is why it is called Simple. >> You will never get your network ntp under a few ms. >Unless the stratum 1 server is on the same LAN... >(As you state later.) No unless your server is disciplined by an attached refclock or by a very nearby refclock. The idea would be to put this (stratum 1) time server in the same LAN as my box, and add it my ntp.conf. (The RTT on the LAN is on the order of >> >> It is NOT a stratum 1. >> A stratum 1 gets its time from an atomic clock. >I don't understand the point you are trying to make. >The time server has a GPS receiver, thus it is "attached" to a >stratum 0 device, thus it is a stratum 1 server. An SNTP server which is attached to a GPS? What are you running? What IS this SNTP software? IF you have a true Stratum 1 as you describe, then yes, you can get 10usec accuracy on your clients. >> If you attach a GPS to one of your (Linux) machines, you will get 2 µs >> accuracy on that machine. On the machines attached on your LAN you will >> get 10s of µs accuracy, if they are unix type machines. >This is the setup I've been discussing, with the GPS receiver inside >the "time server" I'm supposed to evaluate... >> As far as I know >> windows does not impliment a proper clock control API so you will have be >> happy with a few msec for those. >I should have made clear that I am not using Windows. >The system to be synchronized runs Linux 2.6.22.1-rt9 and ntpd 4.2.4 What does the system you are evaluating run? To evaluate it, buy a Garmin GPS18LVC wire it up, place it onto the client, and have a parallel port interrupt routine read the times of the PPS input connected to the parallel port. That will be good to 2usec or so. Then you can see how accurate the discipline by the evaluated receiver is. There is absolutely no way of evaluating a timeclock on its own. It could be 7 ms out and you would have no way of knowing. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: > AFAIK, SNTP is a CLIENT protocol, not a server. That is why it > is called Simple. Is section 6 in RFC 4330 a figment of my imagination then? http://tools.ietf.org/html/rfc4330#section-6 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: > Noob <[EMAIL PROTECTED]> writes: > > >>David Woolley wrote: > > >>>Noob wrote: >>> >>> I've been running ntpd 4.2.4 to synchronize my system clock using remote stratum 2 servers as a reference. (The RTT to these servers is in the 30-50 ms range.) The accuracy is in the 1-2 ms range, based on the reported offset. >>> >>>Offset doesn't tell you the accuracy, it only gives you an idea of the >>>variability of the error. Theoretically, the error could be as much as >>>15 to 25ms, plus the error from the stratum one to the stratum 2. >> > >>What metric should I consider to determine accuracy? > > > The round trip time is an upper bound on the accuracy. The problem is that > the delay can be very asymmetric-- the outbound packet could take 29ms to > get there and teh return 1ms. While unlikely, DSL for example IS > assymmetric. at the tenths of a msec range. There is no way of knowing with > ntp whether or not the trip is asymetric. Ie, while there is an upper bound > on accuracy, there is no metric which measures actual accuracy. > > > > > >># ntpq -crv >>assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg, >>version="ntpd [EMAIL PROTECTED] Fri Mar 16 10:45:43 UTC 2007 (1)", >>processor="i686", system="Linux/2.6.22.1-rt9", leap=00, stratum=2, >>precision=-20, rootdelay=46.299, rootdispersion=17.260, peer=18760, >>refid=134.226.81.3, >>reftime=cb88c64c.edb1a310 Mon, Mar 17 2008 10:28:28.928, poll=8, >>clock=cb88c77e.ef7df269 Mon, Mar 17 2008 10:33:34.935, state=4, >>offset=-0.295, frequency=-6.442, jitter=0.291, noise=0.248, >>stability=0.001 > > >>09:07:02: offset -0.000288 sec freq -6.433 ppm error 0.000453 poll 8 >>09:14:02: offset -0.000712 sec freq -6.436 ppm error 0.000431 poll 8 >>09:21:02: offset -0.000551 sec freq -6.437 ppm error 0.000418 poll 8 >>09:28:02: offset -0.000551 sec freq -6.437 ppm error 0.000422 poll 8 >>09:35:02: offset -0.000539 sec freq -6.438 ppm error 0.000415 poll 8 >>09:42:02: offset -0.000347 sec freq -6.439 ppm error 0.000856 poll 8 >>09:49:02: offset -0.000389 sec freq -6.440 ppm error 0.000597 poll 8 >>09:56:02: offset -0.000389 sec freq -6.440 ppm error 0.000874 poll 8 >>10:03:02: offset -0.39 sec freq -6.441 ppm error 0.000793 poll 8 >>10:10:02: offset -0.39 sec freq -6.441 ppm error 0.000402 poll 8 >>10:17:02: offset -0.39 sec freq -6.441 ppm error 0.000402 poll 8 >>10:24:02: offset -0.39 sec freq -6.441 ppm error 0.000368 poll 8 >>10:31:02: offset -0.000295 sec freq -6.442 ppm error 0.000291 poll 8 >>10:38:02: offset -0.000295 sec freq -6.442 ppm error 0.000167 poll 8 >>10:45:02: offset -0.000295 sec freq -6.442 ppm error 0.000417 poll 8 >>10:52:02: offset -0.000313 sec freq -6.443 ppm error 0.000349 poll 8 >>10:59:02: offset -0.000103 sec freq -6.444 ppm error 0.000312 poll 8 >>11:06:02: offset -0.000103 sec freq -6.444 ppm error 0.000285 poll 8 >>11:13:02: offset -0.000103 sec freq -6.444 ppm error 0.000255 poll 8 >>11:20:02: offset -0.000103 sec freq -6.444 ppm error 0.000340 poll 8 > > I've been asked to evaluate the following time server, in order to reach a better accuracy than what the current setup provides. http://www.heoldesign.com/index.php?id=58 (AFAIU, this time server implements SNTP, not the full NTP.) >>> >>>There are many network timeservers that implement full NTP, so I'm not >>>sure what they are doing with just SNTP; maybe it is aimed at the >>>Windows w32time market. >> > >>Maybe they just need a clue? :-) > > > sorry, but using an SNTP as a server is idiotic. It is designed as a > client. Just use ntp as a server. > > > >>>Also, you can use a GPS timing receiver, with 1 pps output, directly. >> > >>My system is running a Linux kernel patched with real-time support. >>I don't feel confident applying the PPS support patch on top of it. > > > No need. Just attach the gps as a refclock. The kernel does not need pps > support to use the refclock. > > > The idea would be to put this (stratum 1) time server in the same LAN as my box, and add it my ntp.conf. (The RTT on the LAN is on the order of 100 µs.) Will it work? >>> >>>It's a violation of NTP, so the result will only be compliant as an >>>SNTP client. >> > >>What is a violation of NTP? > > > SNTP is a client protocol, not a server, according to RFC. > > > > >>>It may or may not work, depending on whether or not early >>>w32time implementations conformed to SNTP. Early versions of w32time >>>didn't set enough of the response fields to sensible values to guarantee >>>that ntpd would work as a client. >> > >>Why do you mention w32time? > > >>Do you think the HEOL-T101 is running Windows? > > > We have absolutely no idea what you are running on all your machines. You > never told us. This was an assumption based on the weird conditions you > stated. It really really helps if you give information when you ask for > help so that the help
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: >> My system is running a Linux kernel patched with real-time support. >> I don't feel confident applying the PPS support patch on top of it. > > No need. Just attach the gps as a refclock. The kernel does not need pps > support to use the refclock. The Linux kernel does not have built-in PPS support, so yes he would have to patch and recompile the kernel in order to use the PPS provided by the GPS device. Otherwise it will just be using NMEA time, which is not very accurate for timing purposes. For Linux 2.4 there is the PPSkit, and for Linux 2.6 there is LinuxPPS. Instead you can use the shmpps driver to use the PPS signal without patching the Linux kernel. I use it and it works very well. FreeBSD has built-in PPS support (no patch needed), but it's not enabled by default. PPS support has to be enabled in the kernel config and the kernel recompiled. Dennis -- Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
"Dennis Hilberg, Jr." <[EMAIL PROTECTED]> writes: >Unruh wrote: >>> My system is running a Linux kernel patched with real-time support. >>> I don't feel confident applying the PPS support patch on top of it. >> >> No need. Just attach the gps as a refclock. The kernel does not need pps >> support to use the refclock. >The Linux kernel does not have built-in PPS support, so yes he would have to >patch and recompile the kernel in order to use the PPS provided by the GPS >device. Otherwise it will just be using NMEA time, which is not very >accurate for timing purposes. For Linux 2.4 there is the PPSkit, and for >Linux 2.6 there is LinuxPPS. >Instead you can use the shmpps driver to use the PPS signal without patching >the Linux kernel. I use it and it works very well. Precisely. As I said, your kernel does not need pps support to use the refclock. I also use it and it works well. (well, I actually modified it, so I have a purpose built interrupt service routine to service the parallel port interrupt and read the clock. The shmpps then reads those times, and sends them to ntp. A bit of a rube goldberg but it works. I like the parallel port interrupt better than the serial but am not sure why. >FreeBSD has built-in PPS support (no patch needed), but it's not enabled by >default. PPS support has to be enabled in the kernel config and the kernel >recompiled. And exactly what is that supposed to buy you? You need something which can be interrupted by the pps signal from the gps, and read the system time on that interrupt. That does not require kernel support (except of course being able to respond to interrupts-- and if your kernel cannot do that, you forgot to switch on your computer.) >Dennis >-- >Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com >NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >> >> It you attach a gps PPS receiver to one of your boxes (the server) and you >> use a reasonable client then yes you can expect much better than 100us >> accuracy on your net-- assuming it is not overloaded and the machines are >> not overloaded with disk activity. >> >> >> >> >>>Regards. >> >If you REALLY want to determine the accuracy of NTP, get yourself a >Cesium Clock, have it calibrated by your national standdards lab, and >then measure your error. ??? Just get yourself a gpsPPS receiver. They cost about $60 ( vs thousands for a cesium clock) and are more accurate than your ability to read the system clock. Ie, anthing more accurate than about 1usec is completely wasted on almost any computer around, since the random latencies in reading the clock and servicing the interrupt are the dominant source of noise. >If you think that's too much trouble, you're probably right!! Yes, especially since the additional accuracy over a $60 solution is completely wasted. Note to the OP. Apparently you are evaluating some time source. It probably costs $2000 or more. That money is completely wasted. YOu do not need it to get the accuracy you can use. Unless your system is under a mountain or in a basement with no access to the sky, a gps PPS receiver will work just as well as your expensive time source. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: >> FreeBSD has built-in PPS support (no patch needed), but it's not enabled by >> default. PPS support has to be enabled in the kernel config and the kernel >> recompiled. > > And exactly what is that supposed to buy you? > You need something which can be interrupted by the pps signal from the gps, > and read the system time on that interrupt. That does not require kernel > support (except of course being able to respond to interrupts-- and if your > kernel cannot do that, you forgot to switch on your computer.) If I understand correctly, it allows the kernel to discipline the local clock directly from the PPS signal, instead of having a separate helper program like shmpps pass it to a shared memory segment for ntpd to handle, which will discipline the clock via the SHM driver. I don't know if one method is better as I've tried both and there didn't seem to be much difference as far as I could tell. But at the least having PPS support enabled allows you to use the type 20 (generic NMEA GPS receiver) driver which will deal with both the PPS and NMEA time. That would eliminate both the need to have upstream servers for time sources as well as the separate helper program. However, most timekeepers will (should) have a few upstream servers for sanity checks anyway, and most systems nowadays can easily handle a small driver like shmpps running all the time. Dennis -- Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
>>> In article <[EMAIL PROTECTED]>, David Woolley <[EMAIL PROTECTED]> writes: David> NTP clients must use NTP servers, not SNTP ones. I do not believe this is true. The problem is one might want to *know* that the SNTP server is actually talking to a refclock, or more generally, that the SNTP "instance" is playing by the rules. -- Harlan Stenn <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: > SNTP is a client protocol, not a server, according to RFC. You keep saying that. Which RFC are you referring to? > We have absolutely no idea what you are running on all your machines. You > never told us. This was an assumption based on the weird conditions you > stated. It really really helps if you give information when you ask for > help so that the help may actually be helpful. Tell us what your system is, > what "SNTP program" you are using as the server, what the other client > machines on the lan are running. The only client is an x86 PC running Linux 2.6.22.1-rt9 (i.e. with real-time extensions) and ntpd [EMAIL PROTECTED] The server is an embedded device (HEOL-T101) with a GPS receiver and a Fast Ethernet port. I have no idea what operating system runs on the device; there might not even be an OS. The manufacturer claims the device implements SNTPv4 instead of the full NTP. ( http://www.heoldesign.com/index.php?id=58 ) I plan to connect the two systems with a cross-over Ethernet cable. The round-trip time between the two systems would be 80-85 µs. > If you attach a GPS PPS receiver to one of your boxes (the server) and you > use a reasonable client then yes you can expect much better than 100 µs > accuracy on your net-- assuming it is not overloaded and the machines are > not overloaded with disk activity. The GPS receiver is inside the embedded device, which will serve time over its Ethernet port. Considering the answers I've been given by you and by others in this thread, I believe there is a good chance that the setup outlined above will work. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob <[EMAIL PROTECTED]> writes: >Unruh wrote: >> SNTP is a client protocol, not a server, according to RFC. >You keep saying that. Which RFC are you referring to? >> We have absolutely no idea what you are running on all your machines. You >> never told us. This was an assumption based on the weird conditions you >> stated. It really really helps if you give information when you ask for >> help so that the help may actually be helpful. Tell us what your system is, >> what "SNTP program" you are using as the server, what the other client >> machines on the lan are running. >The only client is an x86 PC running Linux 2.6.22.1-rt9 (i.e. with >real-time extensions) and ntpd [EMAIL PROTECTED] >The server is an embedded device (HEOL-T101) with a GPS receiver and a >Fast Ethernet port. I have no idea what operating system runs on the >device; there might not even be an OS. The manufacturer claims the >device implements SNTPv4 instead of the full NTP. Just looked it up. A bit bizarre-- power over the ethernet? The ethernet has no power supply capability. Do you mean that you have to supply the device with 60V running on one of the unused ethernet cable lines? Sounds noisy to me. The GPS timing claimed is 40ns, but the timestamp is only 10usec. How much does this thing cost? Are you really in a situation where this is a better solution than say a cheap Garmin 18LVC? >( http://www.heoldesign.com/index.php?id=58 ) >I plan to connect the two systems with a cross-over Ethernet cable. >The round-trip time between the two systems would be 80-85 µs. >> If you attach a GPS PPS receiver to one of your boxes (the server) and you >> use a reasonable client then yes you can expect much better than 100 µs >> accuracy on your net-- assuming it is not overloaded and the machines are >> not overloaded with disk activity. >The GPS receiver is inside the embedded device, which will serve time >over its Ethernet port. >Considering the answers I've been given by you and by others in this >thread, I believe there is a good chance that the setup outlined above >will work. YOu have not told us what the requirements are, so what "will work" is is unclear. Yes, I am sure it will discipline your computer's clock. probably to better than ms accuracy. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: Just looked it up. A bit bizarre-- power over the ethernet? The ethernet has no power supply capability. Do you mean that you have to supply the device with 60V running on one of the unused ethernet cable lines? Sounds noisy to me. You have no PoE devices in your environment? Phones over twisted pair? No APs? Cool! :-) The thing that strikes me as odd about this device is that it *doesn't* support NTP. If you are building a time appliance, why would you scrimp on the code and deny your customers NTP? -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology [EMAIL PROTECTED] --- Feedback? Contact my director, Craig Cochell, [EMAIL PROTECTED] Thank you! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: > Just looked it up. A bit bizarre-- power over the ethernet? The ethernet > has no power supply capability. Do you mean that you have to supply the > device with 60V running on one of the unused ethernet cable lines? Sounds > noisy to me. > I believe it is a relatively new, but very real, standard. The power is transmitted as a phantom between two pairs. In one variation, they are the pairs used for normal, 10baseT. I gather one reason is that there are exemptions in electrical codes for ELV power feeds as part of datacommunication systems, whereas a normal feed would require a formally qualified (not just competent) electrician. The feed is 48V DC. I'm not 100% sure that counts as ELV, but it is the same as most analogue telephone systems. The apparent source specification is IEE 802.3-2005, although I haven't gone to source. As the power is common mode with respect to the signals, the noise should not be excessive. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
I use PoE every day -- it powers the outdoor antennae that connects to my wireless ISP (distance of about 5 miles). I have gotten up to 3000kb/s over this link (which is slightly higher than what I'm paying for). So, whatever you are debating here, PoE is almost certainly *not* the problem. David Woolley wrote: > Unruh wrote: > > >> Just looked it up. A bit bizarre-- power over the ethernet? The ethernet >> has no power supply capability. Do you mean that you have to supply the >> device with 60V running on one of the unused ethernet cable lines? Sounds >> noisy to me. >> >> > I believe it is a relatively new, but very real, standard. The power is > transmitted as a phantom between two pairs. In one variation, they are > the pairs used for normal, 10baseT. I gather one reason is that there > are exemptions in electrical codes for ELV power feeds as part of > datacommunication systems, whereas a normal feed would require a > formally qualified (not just competent) electrician. > > The feed is 48V DC. I'm not 100% sure that counts as ELV, but it is the > same as most analogue telephone systems. > > The apparent source specification is IEE 802.3-2005, although I haven't > gone to source. > > As the power is common mode with respect to the signals, the noise > should not be excessive. > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
[EMAIL PROTECTED] (Andy Helten) writes: >I use PoE every day -- it powers the outdoor antennae that connects to >my wireless ISP (distance of about 5 miles). I have gotten up to >3000kb/s over this link (which is slightly higher than what I'm paying >for). So, whatever you are debating here, PoE is almost certainly *not* >the problem. OK, learn something new every day! I do agree that it is weird that they would have put SNTP on that thing rather than NTP. How much did it cost? >David Woolley wrote: >> Unruh wrote: >> >> >>> Just looked it up. A bit bizarre-- power over the ethernet? The ethernet >>> has no power supply capability. Do you mean that you have to supply the >>> device with 60V running on one of the unused ethernet cable lines? Sounds >>> noisy to me. >>> >>> >> I believe it is a relatively new, but very real, standard. The power is >> transmitted as a phantom between two pairs. In one variation, they are >> the pairs used for normal, 10baseT. I gather one reason is that there >> are exemptions in electrical codes for ELV power feeds as part of >> datacommunication systems, whereas a normal feed would require a >> formally qualified (not just competent) electrician. >> >> The feed is 48V DC. I'm not 100% sure that counts as ELV, but it is the >> same as most analogue telephone systems. >> >> The apparent source specification is IEE 802.3-2005, although I haven't >> gone to source. >> >> As the power is common mode with respect to the signals, the noise >> should not be excessive. >> ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
The web page http://www.heoldesign.com/index.php?id=58 twice
refers to NTP ("High Precision PG NTP Micro Server"; "The
HEOL-T101 NTP server...") and twice refers to SNTP
("compliant with SNTP protocol"; "Timing Ethernet protocol:
SNTP V4").
Giving the manufacturer the benefit of the doubt, I would
infer that it is a genuine NTP server, and that the packets
sent over the wire comply with RFC 4330 (SNTP v4), which is
the most recent RFC to be published on the subject of NTP
and its relatives. As the RFC states, "The NTP and SNTP
packet formats are the same".
Paul
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: > Noob wrote: > >> Unruh wrote: >> >>> SNTP is a client protocol, not a server, according to RFC. >> >> You keep saying that. Which RFC are you referring to? Apparently, you forgot to answer this question ;-) >> The only client is an x86 PC running Linux 2.6.22.1-rt9 (i.e. with >> real-time extensions) and ntpd [EMAIL PROTECTED] > >> The server is an embedded device (HEOL-T101) with a GPS receiver and a >> Fast Ethernet port. I have no idea what operating system runs on the >> device; there might not even be an OS. The manufacturer claims the >> device implements SNTPv4 instead of the full NTP. > > Just looked it up. A bit bizarre -- power over the ethernet? The ethernet > has no power supply capability. Engineers do all sorts of crazy things. http://en.wikipedia.org/wiki/Power_over_Ethernet Anyway, I didn't plan on using that feature. > The GPS timing claimed is 40ns, but the timestamp is only 10usec. How much > does this thing cost? Over 1000 euros (!!) AFAIU. > Are you really in a situation where this is a better > solution than say a cheap Garmin 18LVC? I've already told my boss several times about the GPS18LVC. I'm not sure why he ignores my request to test a unit. Reference to self: https://buy.garmin.com/shop/shop.do?pID=223&pvID=796 The HEOL-T101 comes with a very stable XO (OCXO perhaps?) accurate within +/- 30 ppb. How much does such an XO cost? Does the GPS18LVC provide an oscillator to serve time even when there are not enough satellites in sight? >> Considering the answers I've been given by you and by others in this >> thread, I believe there is a good chance that the setup outlined above >> will work. > > You have not told us what the requirements are, so what "will work" is > is unclear. Yes, I am sure it will discipline your computer's clock. > probably to better than ms accuracy. My goal was clearly stated in my original message: Will the new setup provide better accuracy than the current setup. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On Mar 18, 1:05 pm, Unruh <[EMAIL PROTECTED]> wrote: > Just looked it up. A bit bizarre-- power over the ethernet? The ethernet > has no power supply capability. Do you mean that you have to supply the > device with 60V running on one of the unused ethernet cable lines? Sounds > noisy to me. http://en.wikipedia.org/wiki/Power_over_Ethernet It's very common in VoIP environments, and environments with wireless access points. We use PoE to power both at our Chicago office; no "wall warts" needed. PoE switches cost about 30% more per port than non-PoE switches, depending on manufacturer. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
[EMAIL PROTECTED] wrote: Giving the manufacturer the benefit of the doubt, I would infer that it is a genuine NTP server, and that the packets sent over the wire comply with RFC 4330 (SNTP v4), which is the most recent RFC to be published on the subject of NTP and its relatives. As the RFC states, "The NTP and SNTP That makes more sense. That's what we get for believing the marketers ... :-) PoE clock box, eh? H. Not a bad idea ... -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology [EMAIL PROTECTED] --- Feedback? Contact my director, Craig Cochell, [EMAIL PROTECTED] Thank you! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On 2008-03-19, Noob <[EMAIL PROTECTED]> wrote: > Does the GPS18LVC provide an oscillator to serve time even when there > are not enough satellites in sight? No. You'll have to pay (much) more than $70-$80 if you want a good hold-over oscillator. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Steve Kostecke wrote: > On 2008-03-19, Noob <[EMAIL PROTECTED]> wrote: > > >>Does the GPS18LVC provide an oscillator to serve time even when there >>are not enough satellites in sight? > > > No. You'll have to pay (much) more than $70-$80 if you want a good > hold-over oscillator. > With something like 27 NAVSTAR (GPS) satellites aloft, there should almost always be seven or eight above the horizon. Satellites more than ten degrees above the horizon are preferred! I've never used the GPS18LVC (I have a Motorola M12+T) but if you know your exact location you only need one satellite to get the time. There are four equations in four unknowns (lattitude, longitude, elevation, and time). Not knowing any of these variables, you need four satellites. Once you know your location a single satellite is sufficient to solve for time. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Richard B. Gilbert wrote: > With something like 27 NAVSTAR (GPS) satellites aloft, there should > almost always be seven or eight above the horizon. Satellites more than > ten degrees above the horizon are preferred! > > I've never used the GPS18LVC (I have a Motorola M12+T) but if you know > your exact location you only need one satellite to get the time. There > are four equations in four unknowns (lattitude, longitude, elevation, > and time). ITYM latitude. > Not knowing any of these variables, you need four satellites. The Wikipedia article was an entertaining read. http://en.wikipedia.org/wiki/GPS#Calculating_positions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
>I've never used the GPS18LVC (I have a Motorola M12+T) but if you know >your exact location you only need one satellite to get the time. There >are four equations in four unknowns (lattitude, longitude, elevation, >and time). Not knowing any of these variables, you need four >satellites. Once you know your location a single satellite is >sufficient to solve for time. That works only if you have appropriate software. The GPS-18 LVC doesn't have that sort of software. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
>Does the GPS18LVC provide an oscillator to serve time even when there >are not enough satellites in sight? No. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
[EMAIL PROTECTED] writes:
>The web page http://www.heoldesign.com/index.php?id=58 twice
>refers to NTP ("High Precision PG NTP Micro Server"; "The
>HEOL-T101 NTP server...") and twice refers to SNTP
>("compliant with SNTP protocol"; "Timing Ethernet protocol:
>SNTP V4").
>Giving the manufacturer the benefit of the doubt, I would
>infer that it is a genuine NTP server, and that the packets
>sent over the wire comply with RFC 4330 (SNTP v4), which is
>the most recent RFC to be published on the subject of NTP
>and its relatives. As the RFC states, "The NTP and SNTP
>packet formats are the same".
Yes, I was completely wrong in casting doubt on the existence of SNTP
servers. I finally read the rfc again, having remembered only about the
clients, and this is exactly the kind of situation for which SNTP server
was designed for-- a single reference clock with no net backup.
I still worry about their claim that their timestamp has a 10us accuracy
while their PPS has a 40ns accuracy. For a dedicated box, 10us seems like
an very very long time. It should be able to timestamp those PPS to far
better than 10us and deliver an ntp time stamp to much better than that.
There is nothing in the box to cause it to lose time.
Again, I wonder what the price on this thing is. Just to compare it with a
$60 18LVC which should be able to do just as well-- with a bit of soldering
to do. The advantages of the Heol is supposed to be that it works in poor
reception conditions, and after it has found where it is, it will work with
timing from only one sattelite ( instead of the 4 that the 18LVC requires).
It may also be designed to flywheel a bit better if no sattelites are
available. Depends on whether those things are worth the money.
May I make an estimate as to the cost? >1000 euros.
>Paul
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >Steve Kostecke wrote: >> On 2008-03-19, Noob <[EMAIL PROTECTED]> wrote: >> >> >>>Does the GPS18LVC provide an oscillator to serve time even when there >>>are not enough satellites in sight? >> >> >> No. You'll have to pay (much) more than $70-$80 if you want a good >> hold-over oscillator. >> >With something like 27 NAVSTAR (GPS) satellites aloft, there should >almost always be seven or eight above the horizon. Satellites more than >ten degrees above the horizon are preferred! >I've never used the GPS18LVC (I have a Motorola M12+T) but if you know >your exact location you only need one satellite to get the time. There >are four equations in four unknowns (lattitude, longitude, elevation, >and time). Not knowing any of these variables, you need four >satellites. Once you know your location a single satellite is >sufficient to solve for time. Yes, but the internals of the receiver are not available to the user. Thus the 18LVC uses a minimum of 4 since it is quite possible that it is moving-- it is designed for OEM truck operations. Thus the 18LVC claim, if I recall correctly, that it needs 4 If less than 4 for a few 10s of seconds it stops delivering a PPS. On the other hand, as you say, if you have any view of the sky at all, that should not be a problem. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob <[EMAIL PROTECTED]> writes: >Unruh wrote: >> Noob wrote: >> >>> Unruh wrote: >>> SNTP is a client protocol, not a server, according to RFC. >>> >>> You keep saying that. Which RFC are you referring to? >Apparently, you forgot to answer this question ;-) As I just wrote, I was wrong. I was misremembering the rfc. Sorry for the misinformation. >> The GPS timing claimed is 40ns, but the timestamp is only 10usec. How much >> does this thing cost? >Over 1000 euros (!!) AFAIU. Ah, yes, that was exactly what I guessed ( see previous post). Sheesh. >> Are you really in a situation where this is a better >> solution than say a cheap Garmin 18LVC? >I've already told my boss several times about the GPS18LVC. I'm not >sure why he ignores my request to test a unit. >Reference to self: >https://buy.garmin.com/shop/shop.do?pID=223&pvID=796 >The HEOL-T101 comes with a very stable XO (OCXO perhaps?) accurate >within +/- 30 ppb. How much does such an XO cost? >Does the GPS18LVC provide an oscillator to serve time even when there >are not enough satellites in sight? For a little while. But even with a bad off the shelf computer, the internal crystal is probably good for 200ppb, and if it is temp controlled, better than that. >>> Considering the answers I've been given by you and by others in this >>> thread, I believe there is a good chance that the setup outlined above >>> will work. >> >> You have not told us what the requirements are, so what "will work" is >> is unclear. Yes, I am sure it will discipline your computer's clock. >> probably to better than ms accuracy. >My goal was clearly stated in my original message: Will the new setup >provide better accuracy than the current setup. I misremember your current setup. But from operating a 18LVC on one computer distributed to a bunch around the department at a university, I am getting what looks like 10us accuracy on most of the machines-- not all. It depends on the machine load, network load, etc. On a machine querying that server over an ordinary telephone ADSL I am getting about 200usec accuracy ( with a 100usec offset in quiet ADSL times) Since I seem to recall that you were currently getting about 10ms accuracy, yes, almost anything will give you better accuracy than that. IF your machine runs linux then you will get better accuracy if you use chrony than if you use ntp ( by a factor of 2-3).(chrony is an ntp implimentation but with a very different clock discipline algorithm than is used by ntp). If you computer that you are trying to control is temperature controlled and has a constant work load, both will probably be about the same, but if the temp fluctuates due for example to changing work loads, then chrony does a much better job of tracking those fluctuations. What accuracy do you need? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
David Woolley wrote: >>> It's a violation of NTP, so the result will only be compliant as an >>> SNTP client. >> What is a violation of NTP? > > NTP clients must use NTP servers, not SNTP ones. > No, That is not correct. NTP clients can use SNTP servers. See the draft NTPv4 spec, section 14, for details. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > Unruh wrote: > >> AFAIK, SNTP is a CLIENT protocol, not a server. That is why it >> is called Simple. > > Is section 6 in RFC 4330 a figment of my imagination then? > > http://tools.ietf.org/html/rfc4330#section-6 That is correct. It's not called CNTP. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Harlan Stenn wrote: > David> NTP clients must use NTP servers, not SNTP ones. > > I do not believe this is true. > Correct. > The problem is one might want to *know* that the SNTP server is actually > talking to a refclock, or more generally, that the SNTP "instance" is > playing by the rules. > There is no way to ensure that. Furthermore there is nothing in the protocol which allows you to differentiate between the two. This is really a non-starter. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Danny Mayer wrote: > Harlan Stenn wrote: > >>David> NTP clients must use NTP servers, not SNTP ones. >> >>I do not believe this is true. >> > > > Correct. > > >>The problem is one might want to *know* that the SNTP server is actually >>talking to a refclock, or more generally, that the SNTP "instance" is >>playing by the rules. >> > > > There is no way to ensure that. Furthermore there is nothing in the > protocol which allows you to differentiate between the two. This is > really a non-starter. > > Danny I can't say it's worth doing but you could always add some sort of a tag to the NTP packet that says "I am an NTP server" or "I am an SNTP Server with a reference clock" or "I am an SNTP leaf node and I'm not supposed to talk to you" ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >Danny Mayer wrote: >> Harlan Stenn wrote: >> >>>David> NTP clients must use NTP servers, not SNTP ones. >>> >>>I do not believe this is true. >>> >> >> >> Correct. >> >> >>>The problem is one might want to *know* that the SNTP server is actually >>>talking to a refclock, or more generally, that the SNTP "instance" is >>>playing by the rules. >>> >> >> >> There is no way to ensure that. Furthermore there is nothing in the >> protocol which allows you to differentiate between the two. This is >> really a non-starter. >> >> Danny >I can't say it's worth doing but you could always add some sort of a tag >to the NTP packet that says "I am an NTP server" or "I am an SNTP Server >with a reference clock" or "I am an SNTP leaf node and I'm not supposed >to talk to you" Look, an SNTP client is not supposed to act as a server. Period. If it does it means whoever programmed it broke the rules. Do you really thing having him program in an extra flag saying "I did not break the rules" is going to do anything? It is the same person who programmed it in the first place who also programs what it sends out in the packet. An sntp client is not supposed to respond to server requests. You want it to respond. Why? I would think that the "flag" of no-response is far more effective than some bit in the packet. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
>>> In article <[EMAIL PROTECTED]>, "Richard B. Gilbert" <[EMAIL PROTECTED]> >>> writes: Richard> Danny Mayer wrote: Harlan> The problem is one might want to *know* that the SNTP server is Harlan> actually talking to a refclock, or more generally, that the SNTP Harlan> "instance" is playing by the rules. Danny> There is no way to ensure that. Furthermore there is nothing in the Danny> protocol which allows you to differentiate between the two. This is Danny> really a non-starter. What is the "non-starter" Danny? Richard> I can't say it's worth doing but you could always add some sort of Richard> a tag to the NTP packet that says "I am an NTP server" or "I am an Richard> SNTP Server with a reference clock" or "I am an SNTP leaf node and Richard> I'm not supposed to talk to you" It's already been done. It's called the NTP RFC. The "stratum" tells you this. What difference does it make if somebody blows the stratum code v. somebody blows the code to say "believe me when I tell you that I am an NTP server"? -- Harlan Stenn <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Unruh wrote: > "Richard B. Gilbert" <[EMAIL PROTECTED]> writes: > >> Danny Mayer wrote: >>> Harlan Stenn wrote: >>> David> NTP clients must use NTP servers, not SNTP ones. I do not believe this is true. >>> >>> Correct. >>> >>> The problem is one might want to *know* that the SNTP server is actually talking to a refclock, or more generally, that the SNTP "instance" is playing by the rules. >>> >>> There is no way to ensure that. Furthermore there is nothing in the >>> protocol which allows you to differentiate between the two. This is >>> really a non-starter. >>> >>> Danny > >> I can't say it's worth doing but you could always add some sort of a tag >> to the NTP packet that says "I am an NTP server" or "I am an SNTP Server >> with a reference clock" or "I am an SNTP leaf node and I'm not supposed >> to talk to you" > > Look, an SNTP client is not supposed to act as a server. Period. If it does > it means whoever programmed it broke the rules. Do you really thing having > him program in an extra flag saying "I did not break the rules" is going to > do anything? It is the same person who programmed it in the first place who > also programs what it sends out in the packet. > An sntp client is not supposed to respond to server requests. You want it > to respond. Why? I would think that the "flag" of no-response is far more > effective than some bit in the packet. I'm going to need to point you to the RFC draft for the definition of an SNTP server. However, no RFC will prevent anyone from writing code that allow an SNTP client also serving that time to other clients. The Internet police just aren't up to the task. That's the difference between an RFC and reality. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Harlan Stenn wrote: In article <[EMAIL PROTECTED]>, "Richard B. Gilbert" <[EMAIL PROTECTED]> writes: > > Richard> Danny Mayer wrote: > > Harlan> The problem is one might want to *know* that the SNTP server is > Harlan> actually talking to a refclock, or more generally, that the SNTP > Harlan> "instance" is playing by the rules. > > Danny> There is no way to ensure that. Furthermore there is nothing in the > Danny> protocol which allows you to differentiate between the two. This is > Danny> really a non-starter. > > What is the "non-starter" Danny? > That there's a way of telling the difference. The RFC only tells you want you need to send in the packet. It says nothing about identifying the type of server and you have no way of probing it for that answer. > Richard> I can't say it's worth doing but you could always add some sort of > Richard> a tag to the NTP packet that says "I am an NTP server" or "I am an > Richard> SNTP Server with a reference clock" or "I am an SNTP leaf node and > Richard> I'm not supposed to talk to you" > > It's already been done. It's called the NTP RFC. The "stratum" tells you > this. > The stratum is what the server says it is. Why else would Microsoft have their time servers that claim that they are all stratum 2 servers? They are not even NTP servers. > What difference does it make if somebody blows the stratum code v. somebody > blows the code to say "believe me when I tell you that I am an NTP server"? Nothing. That's why you cannot differentiate between them and that's why it's a nonstarter. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Noob wrote: > Unruh wrote: > >> SNTP is a client protocol, not a server, according to RFC. > > You keep saying that. Which RFC are you referring to? > SNTP is defined in the NTPv4 draft in http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-09.txt in section 14. You can also look at RFC 4330 but that's about to be obsoleted by the NTPv4 draft. SNTP is *not* a client protocol. >> We have absolutely no idea what you are running on all your machines. You >> never told us. This was an assumption based on the weird conditions you >> stated. It really really helps if you give information when you ask for >> help so that the help may actually be helpful. Tell us what your system is, >> what "SNTP program" you are using as the server, what the other client >> machines on the lan are running. > > The only client is an x86 PC running Linux 2.6.22.1-rt9 (i.e. with > real-time extensions) and ntpd [EMAIL PROTECTED] > > The server is an embedded device (HEOL-T101) with a GPS receiver and a > Fast Ethernet port. I have no idea what operating system runs on the > device; there might not even be an OS. The manufacturer claims the > device implements SNTPv4 instead of the full NTP. > > ( http://www.heoldesign.com/index.php?id=58 ) > Since it hads a GPS receiver in it, it only needs the SNTP part of the spec and be an SNTP server. See the NTPv4 draft. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Danny Mayer wrote: > SNTP is defined in the NTPv4 draft in section 14. You can also look > at RFC 4330 but that's about to be obsoleted by the NTPv4 draft. Thanks for the pointer. The HTML version of the draft adds incremental diffs. http://tools.ietf.org/html/draft-ietf-ntp-ntpv4-proto-09 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Richard B. Gilbert wrote: > I can't say it's worth doing but you could always add some sort of a tag > to the NTP packet that says "I am an NTP server" or "I am an SNTP Server > with a reference clock" or "I am an SNTP leaf node and I'm not supposed > to talk to you" No need for that. The SNTP client should just ignore incoming packets that it didn't send. Only server mode and broadcast mode packets are valid. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
"Unruh" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [...] > Look, an SNTP client is not supposed to act as a server. Period. Unless... its clock is disciplined by means external to NTP. For example, by a reference clock. Not all reference clocks must necessarily be NTP servers; there are other ways to use them to make sure that some clock in the next computer over runs Very Close to UTC. It has been said right here that many if not most of the black box stratum-1 servers operate by the exact mechanism you condemn: an SNTP client polling a local refclock at some suitably short interval, presumably with a simple feedback loop but without the full NTP and its higher math & other assorted magic. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Harlan Stenn wrote: > > Richard> I can't say it's worth doing but you could always add some sort of > Richard> a tag to the NTP packet that says "I am an NTP server" or "I am an > Richard> SNTP Server with a reference clock" or "I am an SNTP leaf node and > Richard> I'm not supposed to talk to you" > > It's already been done. It's called the NTP RFC. The "stratum" tells you > this. Note that Microsfoft's "SNTP" implementation claims stratum 2, when acting as an a server with an illegal time source. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On Mar 25, 7:21 am, David Woolley <[EMAIL PROTECTED]> wrote: > Note that Microsfoft's "SNTP" implementation claims stratum 2, when > acting as an a server with an illegal time source. This is not true in Windows 2003 and newer. Considering that Windows 2000 sales ended in 2003, and mainstream support ended in 2005, I think your statement needs qualification. Windows Time Service (w32time) is an RFC-1305-compliant NTP (not SNTP!) implementation, and has been for 5 years or more. It reports the correct statum, has the clock discipline algorithms, etc. Yes, it has some limitations (precision is -6), and is easy to mis-configure (so is ntpd), but it mostly just works. I advise most of my clients to use it rather than messing with the complexity of ntpd on Windows if possible. I know a lot of people hate MSFT, but let's not let that get in the way of the actual facts. Not everyone can or should run the reference ntpd implementation. There will always be other commercial and open source implementations of the NTP and SNTP protocols. This is a very good thing from a security perspective, and also from a competitive perspective. Would we have the pool scheme in the development versions of ntpd now if OpenNTPD hadn't implemented it first? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
Ryan Malayter wrote: > This is not true in Windows 2003 and newer. Considering that Windows Depends on the service pack. I believe it was finally fixed about two years ago. The reference implementation is still better. > 2000 sales ended in 2003, and mainstream support ended in 2005, I > think your statement needs qualification. But noting that Windows XP support life has been extended because users refused to move to Vista. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On 2008-03-25, Ryan Malayter <[EMAIL PROTECTED]> wrote: > On Mar 25, 7:21 am, David Woolley wrote: > >> Note that Microsfoft's "SNTP" implementation claims stratum 2, when >> acting as an a server with an illegal time source. > > This is not true in Windows 2003 and newer. Considering that Windows > 2000 sales ended in 2003, and mainstream support ended in 2005, I > think your statement needs qualification. > > Windows Time Service (w32time) is an RFC-1305-compliant NTP (not > SNTP!) implementation, and has been for 5 years or more. We all now how long older versions of Windows remain in service well past the EOL. What _version_ of w32time is RFC-1305 compliant? > Would we have the pool scheme in the development versions of ntpd now > if OpenNTPD hadn't implemented it first? Really? They did? Are you sure that the person who wrote the pool configuration directive code for the Reference Implementation of NTP pays any attention to OpenNTPD? -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
"Steve Kostecke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 2008-03-25, Ryan Malayter <[EMAIL PROTECTED]> wrote: [...] >> Would we have the pool scheme in the development versions of ntpd >> now if OpenNTPD hadn't implemented it first? > > Really? They did? The NTP Pool was implemented at first as a bunch of public NTP servers, with clever use of DNS to make it work. The point I'm trying to make is that it worked before and without any NTP implementation knowing about it. It does work better when the NTP client is aware of the need to re-resolve hostnames under certain circumstances, but those same circumstances occur outside the pool, just not as often or as pressing. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
"Maarten Wiltink" <[EMAIL PROTECTED]> writes: >"Unruh" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >[...] >> Look, an SNTP client is not supposed to act as a server. Period. >Unless... its clock is disciplined by means external to NTP. >For example, by a reference clock. Not all reference clocks must >necessarily be NTP servers; there are other ways to use them to >make sure that some clock in the next computer over runs Very Close >to UTC. >It has been said right here that many if not most of the black box >stratum-1 servers operate by the exact mechanism you condemn: an >SNTP client polling a local refclock at some suitably short interval, >presumably with a simple feedback loop but without the full NTP and >its higher math & other assorted magic. The problem with netnews-- your mistakes far outlive your recognition that you have made a mistake. Yes, I have admitted that I was out and out wrong. Period. You are perfectly correct. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
On Mar 25, 9:47 am, Steve Kostecke <[EMAIL PROTECTED]> wrote: > What _version_ of w32time is RFC-1305 compliant? Microsoft's documentation indicates that all versions of w32time in Windows 2003 are RFC-1305 compliant. I know from testing that the versions in Windows 2003 SP1 (releleased March 30 2005) and later are RFC-1305 compliant when configured properly. I did not test the RTM version of Windows 2003. > > Would we have the pool scheme in the development versions of ntpd now > > if OpenNTPD hadn't implemented it first? > Really? They did? Yes, they did, back in 2004. See the "servers" keyword: http://www.openbsd.org/cgi-bin/man.cgi?query=ntpd.conf&apropos=0&sektion=0&manpath=OpenBSD+3.6&arch=i386&format=html > Are you sure that the person who wrote the pool configuration directive > code for the Reference Implementation of NTP pays any attention to > OpenNTPD? No, I am not sure. But I do recall the OpenNTPD "servers" keyword being mentioned on the NTP Pool project mailing list long before the "pool" directive appeared in the development versions NTPD. Shouldn't any software developer be looking at other solutions in the same problem space for ideas? Especially in an open souce world? -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
