Re: [ntp:questions] ntpdate.c unsafe buffer write
ntdate -b steps the clock. That's the function under discussion. The one that's used nearly universally in boot sequences. -Tom David L. Mills wrote: Guys, There seems to some misinformation here. Both ntpdate and ntpd -q set the offset with adjtime() and then exit. After that, stock Unix adjtime() slews the clock at rate 500 PPM, which indeed could take 256 s for an initial offset of 128 ms. A prudent response would be to measure the initial offset and compute the time to wait. The ntp-wait script waits for ntpd to enter state 4, which could happen with an initial offset as high as 128 ms. The ntpd time constant is purposely set somewhat large at 2000 s, which results in a risetime of about 3000 s. This is a compromise for stable acquisition for herky-jerky Internet paths and speed of convergence for LANs. For typical Internet paths the Allan intercept is about 2000 s. For fast LANs with nanosecond clock resolution, the Allan intercept can be as low as 250s, which is what the kernel PPS loop is designed for. Both the daemon and kernel loops are engineered so that the time constant is directly proportional to the poll interval and the risetime scales directly. If the poll exponent is set to the minimum 4 (16 s) the risetinme is 500 s. While not admitted in public, the latest snapshot can set the poll interval to 3 (8 s), so the risetime is 250 s. This works just fine on a LAN, but I would never do this on an outside circuit. Dave Unruh wrote: Harlan Stenn [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes: David Harlan Stenn wrote: Why would ntpd be exiting during a warm start? David Because we are discussing using it with the -q option. If you just David use -g, it will take a lot longer to converge within a few David milliseconds, as it will not slew at the maximum rate. If you use David -q, you need to force a step if you want fast convergence. I still maintain you are barking up the wrong tree. In terms of the behavior model of ntp, state 4 is as good as it gets. You are in the right ballpark. And as has been commented on numerous times, ntp is state 4 is very slow to converge to the best possible time control. This was a deliberate design decision, as I understand it, so that in steady state the time is averaged over a large number of samples ( not helped by the fact that 85% of samples are thrown away), to reduce the statistical error in the clock control. Note that at poll 7 the number of actual samples averaged over in the time scale of the ntp feedback loop is only about 3, so the statistical averaging even with such a long time constant, is not very good. If you want something else, something you consider better than state 4, please make a case for this and lobby for it. I think many people have lobbied for faster response. In the discussion of the chrony/ntp comparison, chrony is much faster to correct errors, and at least on a local network, better at disciplining the clock as well ( in part I think because on such a minimal round trip network, the frequency fluctuations dominate over the offset measurement errors-- Ie, the Allen intercept is much lower than the assumed 1500 sec. in that kind of situation-- also the drift model on real systems is not well modeled by 1/f noise.) So, what I think the point is that using ntpdate, one can rapidly bring the clock into a few msec of the correct time, rather than waiting for the feedback loop to finally eliminate that last 128msec of offset. For the case I'm describing the startup script sequence is to fire up 'ntpd -g' early. If there are applications that need the system clock to be on-track stable (even if a wiggle is being dealt with), that's 'state 4', and running 'ntp-wait' before starting those services is, to the best of my knowledge, all that is required. David State 4 means within 128ms and using the normal control loop, which David has a time constant of around an hour. OK, and so what? Is State 4 insufficient for your needs, or are you just splitting hairs? David For a cold start, it won't reach state 4 for a further 900 seconds David after first priming the clock filter. If the system has a good drift file, I disagree with you. David The definition of cold start is that there is no drift file. OK, now I know what the definitions are. I don't recall offhand the expected time to hit state 4 without a drift file. 1) This should not be the ordinary case 2) How does this have any bearing on the ntpdate -b discussion? And what is the big deal with using different config files? The config file mechanism has include capability so it is trivial to to easily maintain common 'base' configuration with customizations for separate start/run phases. David You are now talking about using -q. The difficulty is that people
Re: [ntp:questions] GPS with PPS without any soldering requirements?
[EMAIL PROTECTED] (Chris Adams) writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: The moral is: don't buy a computer without a serial port :) Well, I have a serial port, but it is the serial console. Not many PC type systems (including servers) come with _two_ serial ports anymore. Sure they do, the second is usually a header on the mobo, you just have to get an extension slot cover with a DB9 connector and a flat cable. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS with PPS without any soldering requirements?
Once upon a time, Dag-Erling Smørgrav [EMAIL PROTECTED] said: [EMAIL PROTECTED] (Chris Adams) writes: The way I finally got mine working in a stable setup was to use USB for the NMEA statements and put the PPS signal over a pin on the parallel port (using shm_splc2 to get the PPS from there to ntpd) since I didn't have an available serial port. The moral is: don't buy a computer without a serial port :) Well, I have a serial port, but it is the serial console. Not many PC type systems (including servers) come with _two_ serial ports anymore. Many still come with a parallel port (that is otherwise unused). I could have added a PCI serial card, but then I still would have needed to get power from somewhere. This way I also don't need another power source. You can also draw power from a USB port without actually connecting a USB device or transferring any data over it. Yeah, I looked at that, but I've got an SVeeSix, and it is rated to draw a little more power than you are allowed as an unconfigured USB device. So, I used a USB-to-RS232 interface (DLP-2232M) to get both signal and power. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
Harlan Stenn [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes: David Harlan Stenn wrote: Why would ntpd be exiting during a warm start? David Because we are discussing using it with the -q option. If you just David use -g, it will take a lot longer to converge within a few David milliseconds, as it will not slew at the maximum rate. If you use David -q, you need to force a step if you want fast convergence. I still maintain you are barking up the wrong tree. In terms of the behavior model of ntp, state 4 is as good as it gets. You are in the right ballpark. And as has been commented on numerous times, ntp is state 4 is very slow to converge to the best possible time control. This was a deliberate design decision, as I understand it, so that in steady state the time is averaged over a large number of samples ( not helped by the fact that 85% of samples are thrown away), to reduce the statistical error in the clock control. Note that at poll 7 the number of actual samples averaged over in the time scale of the ntp feedback loop is only about 3, so the statistical averaging even with such a long time constant, is not very good. If you want something else, something you consider better than state 4, please make a case for this and lobby for it. I think many people have lobbied for faster response. In the discussion of the chrony/ntp comparison, chrony is much faster to correct errors, and at least on a local network, better at disciplining the clock as well ( in part I think because on such a minimal round trip network, the frequency fluctuations dominate over the offset measurement errors-- Ie, the Allen intercept is much lower than the assumed 1500 sec. in that kind of situation-- also the drift model on real systems is not well modeled by 1/f noise.) So, what I think the point is that using ntpdate, one can rapidly bring the clock into a few msec of the correct time, rather than waiting for the feedback loop to finally eliminate that last 128msec of offset. For the case I'm describing the startup script sequence is to fire up 'ntpd -g' early. If there are applications that need the system clock to be on-track stable (even if a wiggle is being dealt with), that's 'state 4', and running 'ntp-wait' before starting those services is, to the best of my knowledge, all that is required. David State 4 means within 128ms and using the normal control loop, which David has a time constant of around an hour. OK, and so what? Is State 4 insufficient for your needs, or are you just splitting hairs? David For a cold start, it won't reach state 4 for a further 900 seconds David after first priming the clock filter. If the system has a good drift file, I disagree with you. David The definition of cold start is that there is no drift file. OK, now I know what the definitions are. I don't recall offhand the expected time to hit state 4 without a drift file. 1) This should not be the ordinary case 2) How does this have any bearing on the ntpdate -b discussion? And what is the big deal with using different config files? The config file mechanism has include capability so it is trivial to to easily maintain common 'base' configuration with customizations for separate start/run phases. David You are now talking about using -q. The difficulty is that people David have enough trouble getting the run phase config file right. I mention it because it's what you seem to be insisting on talking about. I was providing a way to address the problems you describe with the (IMO bad) mechanism (-q) under discussion. But the bigger problem is why are you insisting on separate start/run phases? This has not been best practice for quite a while, and if you insist on using this method you will be running in to the exact problems you are describing. No, the best advice is to understand why you have been using ntpdate -b so far and understand the pros/cons of the new choices. David We are talking about system managers and package creators, neither of David which have much time to study the details. Blessed are those who get what they deserve. These are the same folks who must get ssh configurations and various other network configurations working. If the stock things work well enough for folks, great. If folks have suggestions for improvements I welcome them. If folks want something different I invite them to make a case for it. Please remember the scope and complexity of the problem case. It's much easier to have a simpler solution if one is prepared to ignore certain problems. Another case in this point is Maildir. If somebody is in the situation where they know they have specific requirements for time, they are in the situation where they have enough altitude on their requirements to know the costs/benefits of what is involved in getting there. Well, I disagree. The sign of a good piece of software is that it does what it needs to do
[ntp:questions] GPS with PPS without any soldering requirements?
Hi, Are there any cheap GPS receivers which emit a PPS signal and can be used directly without any soldering? E.g. usb or rs232. Folkert van Heusden -- Multitail - gibkaja utilita po sledovaniju log-fajlov i vyvoda kommand. Fil'trovanie, raskraivanie, slijanie, vizual'noe sravnenie, i t.d. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
Hello David,
On Monday, February 11, 2008 at 19:03:36 +, David L. Mills wrote:
Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
After that, stock Unix adjtime() slews the clock at rate 500 PPM,
which indeed could take 256 s for an initial offset of 128 ms.
And on some systems, adjtime() calls adjtimex(ADJ_OFFSET_SINGLESHOT) to
do the job.
Note that ntpdate does not stop slewing when it reaches the zero offset,
but voluntarily overshoots by 50%. That's why ntpdate -b (forced step)
or ntpd -q (exact slew until zero) are so much better.
A prudent response would be to measure the initial offset and compute
the time to wait.
Thanks! That's exactly what does the slew_sleeping script:
#!/bin/sh
function slew_sleeping() {
awk '
{print}
/^ntpd: time slew .*s$/ {
sleep = $4 * 2000
if (sleep 0)
sleep = -sleep
sleep = int(sleep + 0.99) # rounded by excess
success = 1
}
/^ntpd: time set .*s$/ {
success = 1
}
END{
if (sleep) {
printf wait for the end of time slew, sleeping %d seconds\n, sleep
system(sleep sleep)
}
exit success
}
'
}
# echo ntpd: time slew -0.003000s | slew_sleeping; exit
while ntpd -gq | slew_sleeping; do :; done; ntpd
Serge.
--
Serge point Bets arobase laposte point net
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
In article [EMAIL PROTECTED], David L. Mills [EMAIL PROTECTED] writes: David Serge, I didn't believe what you said until I checked the code and it David does increase the correction by 50%, but limits the overshoot to 50 David ms. Why in the would it overshoot at all? Dave, this is one of the many problem with ntpdate and why we wanted to kill it off since nobody was maintaining it. As I recall, somebody said For folks who want to run ntpdate out of cron, we should do a bit of overshoot so we can home in on the right adjustment. As I recall, the thought was If we start off with no overshoot and make our adjustment, the next time we run ntpdate we will make the same adjustment that we just did. So let's overshoot so next time we will be a bit closer. I didn't say the idea makes a lot of sense, but hey. -- 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] ntpdate.c unsafe buffer write
In article [EMAIL PROTECTED], Tom Smith [EMAIL PROTECTED] writes: Tom ntdate -b steps the clock. That's the function under discussion. The Tom one that's used nearly universally in boot sequences. Then change the boot sequence. Using ntpdate -b to step the clock before starting ntpd is no longer best common practice, and it hasn't been for a decent hunk of time. -- 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] ntpdate.c unsafe buffer write
Serge,
I didn't believe what you said until I checked the code and it does
increase the correction by 50%, but limits the overshoot to 50 ms. Why
in the would it overshoot at all?
Dave
Serge Bets wrote:
Hello David,
On Monday, February 11, 2008 at 19:03:36 +, David L. Mills wrote:
Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
After that, stock Unix adjtime() slews the clock at rate 500 PPM,
which indeed could take 256 s for an initial offset of 128 ms.
And on some systems, adjtime() calls adjtimex(ADJ_OFFSET_SINGLESHOT) to
do the job.
Note that ntpdate does not stop slewing when it reaches the zero offset,
but voluntarily overshoots by 50%. That's why ntpdate -b (forced step)
or ntpd -q (exact slew until zero) are so much better.
A prudent response would be to measure the initial offset and compute
the time to wait.
Thanks! That's exactly what does the slew_sleeping script:
#!/bin/sh
function slew_sleeping() {
awk '
{print}
/^ntpd: time slew .*s$/ {
sleep = $4 * 2000
if (sleep 0)
sleep = -sleep
sleep = int(sleep + 0.99) # rounded by excess
success = 1
}
/^ntpd: time set .*s$/ {
success = 1
}
END{
if (sleep) {
printf wait for the end of time slew, sleeping %d seconds\n, sleep
system(sleep sleep)
}
exit success
}
'
}
# echo ntpd: time slew -0.003000s | slew_sleeping; exit
while ntpd -gq | slew_sleeping; do :; done; ntpd
Serge.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
Serge, Interesting script - thanks. Would you like me to put it in the distribution? This brings up an underlying question. It is possible for events to unfold in a way that while in state 4, events will be such that there will be future wiggles. Some of them may even take us out of state 4. Agreed? If so, what benefit do we get by using the script to delay things while we are waiting for a slew to finish while in state 4? What difference does it make if the system in question is an client as opposed to a 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] GPS with PPS without any soldering requirements?
Dag-Erling, Correct. That was the plan for my latest Intel motherboard. Problem is, Intel wired the motherboard header backwards. My SIIG serial port card comes up COM5, COM6,..., but my favorite old program requires COM1 or COM2. Dave Dag-Erling Smørgrav wrote: [EMAIL PROTECTED] (Chris Adams) writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: The moral is: don't buy a computer without a serial port :) Well, I have a serial port, but it is the serial console. Not many PC type systems (including servers) come with _two_ serial ports anymore. Sure they do, the second is usually a header on the mobo, you just have to get an extension slot cover with a DB9 connector and a flat cable. DES ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
Guys, Just for clarity, neither the daemon nor kernel frequency is adjusted in any way with ntpd -q. Serge Bets wrote: On Monday, February 11, 2008 at 7:38:53 +, David Woolley wrote: Serge Bets wrote: the kind of slew (singleshot) initiated by ntpd -q comes *above* the usual frequency correction That assumes the use of the kernel time discipline Indeed: I sometimes forget this can lack or be disabled, sorry. Serge. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
Hello Harlan, On Monday, February 11, 2008 at 0:33:36 +, Harlan Stenn wrote: 1) what are you trying to accomplish by the sequence: ntpd -gq ; wait a bit; ntpd that you do not get with: ntpd -g ; ntp-wait Let's compare. I used a some weeks old ntp-dev 4.2.5p95, because the latest p113 seems to behave strangely (clearing STA_UNSYNC long before the clock is really synced). The driftfile exists and has a correct value. ntp.conf declares one reachable LAN server with iburst. There are 4 main cases: initial phase offset bigger than 128 ms, or below, and your startup method, or my method. -1) Initial phase offset over 128 ms, ntp-wait method: | 0:00 # ntpd -g; ntp-wait; time_critical_apps | 0:07 time step == the clock is very near 0 offset (less than a ms), | stratum 16, refid .STEP., state 4 | 0:12 ntp-wait terminates == time critical apps can be started | 1:20 *synchronized, stratum x == ntpd starts serving good time Timings are in minutes:seconds, relative to startup. Note this last *sync stage, when ntpd takes a non-16 stratum, comes at a seemingly random moment, sometimes as early as 0:40. -2) Initial phase offset over 128 ms, my slew_sleeping script: | 0:00 # ntpd -gq | slew_sleeping; ntpd | 0:07 time step, no sleep == near 0 offset (time critical apps can be | started) | 0:14 *synchronized == ntpd starts serving good time -3) Initial phase offset below 128 ms, ntp-wait method (worst case): | 0:00 # ntpd -g; ntp-wait; time_critical_apps | 0:07 *synchronized == ntpd starts serving time, a still bad time, | because the 128 ms offset is not yet slewed | 0:12 ntp-wait terminates == time critical apps are started | 7:30 offset crosses the zero line for the first time, and begins an | excursion on the other side (up to maybe 40 ms). The initial good | frequency has been modified to slew the phase offset, and is now | wildly bad (by perhaps 50 or 70 ppm). The chaos begins, and will | stabilize some hours later. -4) Initial phase offset below 128 ms, slew_sleeping script: | 0:00 ntpd -gq | slew_sleeping; ntpd | 0:07 begin max rate slew, sleeping all the necessary time (max 256 | seconds) | 4:23 wake-up == near 0 offset, time critical apps can be started | 4:30 *synchronized == ntpd starts serving good time Summary: The ntp-wait method is good at protecting apps against steps, but not against large offsets (tens or a hundred of ms). The daemon itself can start serving such less-than-good time. Startup takes more time to reach a near 0 offset, and can wreck the frequency. The ntpd -gq method does also avoid steps to applications, if all works well. But it's not a 100% protection, not the goal. It also protects apps against large offsets, never serves bad time, and never squashes the driftfile. It makes a much saner daemon startup, more stable, where the chaos situation described above (case #3) doesn't happen. It startups faster, outside of the cases where ntp-wait cheats by tolerating not yet good offsets. If necessary, slew_sleeping and ntp-wait can be combined, for a better level of protection. What about the following, that should survive even a server temporarily unavailable during startup, further delaying time critical apps: | # ntpd -gq | slew_sleeping; ntpd -g; ntp-wait; time_critical_apps One could also imagine looping ntpd -gq until it works, then sleep, then ntpd and time_critical_apps (the slew_sleeping scripts has to be modified to return success code): | # while ntpd -gq | slew_sleeping; do :; done; ntpd; time_critical_apps Serge. -- Serge point Bets arobase laposte point net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
Tom, With tinker step .001 in the configuration file, ntpd -q will step the clock, unless the residual offset is less than .001 s. This is probably more complexity than you can stand. Just keep using ntpdate and be happy. Dave Tom Smith wrote: ntdate -b steps the clock. That's the function under discussion. The one that's used nearly universally in boot sequences. -Tom David L. Mills wrote: Guys, There seems to some misinformation here. Both ntpdate and ntpd -q set the offset with adjtime() and then exit. After that, stock Unix adjtime() slews the clock at rate 500 PPM, which indeed could take 256 s for an initial offset of 128 ms. A prudent response would be to measure the initial offset and compute the time to wait. The ntp-wait script waits for ntpd to enter state 4, which could happen with an initial offset as high as 128 ms. The ntpd time constant is purposely set somewhat large at 2000 s, which results in a risetime of about 3000 s. This is a compromise for stable acquisition for herky-jerky Internet paths and speed of convergence for LANs. For typical Internet paths the Allan intercept is about 2000 s. For fast LANs with nanosecond clock resolution, the Allan intercept can be as low as 250s, which is what the kernel PPS loop is designed for. Both the daemon and kernel loops are engineered so that the time constant is directly proportional to the poll interval and the risetime scales directly. If the poll exponent is set to the minimum 4 (16 s) the risetinme is 500 s. While not admitted in public, the latest snapshot can set the poll interval to 3 (8 s), so the risetime is 250 s. This works just fine on a LAN, but I would never do this on an outside circuit. Dave snip ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS with PPS without any soldering requirements?
Evandro Menezes [EMAIL PROTECTED] writes: Doesn't the USB protocol have an isochronous mode that guarantees real- time, predictable communication? In theory, but once you throw a hub into the mix, it gets hairy. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
Harlan Stenn [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], Unruh [EMAIL PROTECTED] writes: Harlan In terms of the behavior model of ntp, state 4 is as good as it Harlan gets. You are in the right ballpark. Unruh And as has been commented on numerous times, ntp is state 4 is very Unruh slow to converge to the best possible time control. This was a Unruh deliberate design decision, as I understand it, so that in steady Unruh state the time is averaged over a large number of samples ( not Unruh helped by the fact that 85% of samples are thrown away), to reduce Unruh the statistical error in the clock control. Note that at poll 7 the Unruh number of actual samples averaged over in the time scale of the ntp Unruh feedback loop is only about 3, so the statistical averaging even with Unruh such a long time constant, is not very good. OK, and please don't take this the wrong way, but So What? For the general use case (LAN and/or WAN and/or jerky path) ntpd behaves well. The question is not does it work well, but does it work the best it can. As Dave recently replied, if you are only interested in LAN performance there are tweaks that can be made that will improve the performance. No, I am interested in the behaviour in general. That is why I am trying to test it on an ADSL link as well. The current setup will Just Work regardless of the network environment. This, to me, is the sign of a good piece of software. If somebody with extra knowledge can make a local optimization based on tighter specs, great. The question is whether or not it can be made better in general. I suspect that if Dave can be shown that whatever chrony is doing will behave in the wider space that NTP covers, he will be OK making changes to use those algorithms. There may even be a way to choose different algorithms based on the behavior in evidence. But you seem to be talking about how improvements can be made and I thought this original thread was about how there was a *problem*. This original thread was about how ntpdate had an too small a buffer for a given use-- a very easily fixable problem. It then wandered to whether or not ntpdate should be axed or not. And then as an aside I mentioned further experiments I was doing on the comparison of chrony and ntp-- mentioned because one of the reasons ntpdate is used is the slow convergence of ntp to the true time. I mentioned that chrony has much faster convergence. So as sometimes happens in threads, they wander, and in this case I was at least partially responsible for part of the wander. If you want something else, something you consider better than state 4, please make a case for this and lobby for it. Unruh I think many people have lobbied for faster response. In the Unruh discussion of the chrony/ntp comparison, chrony is much faster to Unruh correct errors, and at least on a local network, better at Unruh disciplining the clock as well ( in part I think because on such a Unruh minimal round trip network, the frequency fluctuations dominate over Unruh the offset measurement errors-- Ie, the Allen intercept is much lower Unruh than the assumed 1500 sec. in that kind of situation-- also the drift Unruh model on real systems is not well modeled by 1/f noise.) So, what I Unruh think the point is that using ntpdate, one can rapidly bring the Unruh clock into a few msec of the correct time, rather than waiting for Unruh the feedback loop to finally eliminate that last 128msec of offset. OK, and again, I'm seeing you lobby for an enhancement/improvement here (and I'm all for that). David (I think) was talking about a *problem*. I agree with you that we can do better. I am trying to see if there is also a problem. Too many potential problems. I am confused about which one. Harlan If folks have suggestions for improvements I welcome them. Harlan If folks want something different I invite them to make a case for Harlan it. Please remember the scope and complexity of the problem case. Harlan It's much easier to have a simpler solution if one is prepared to Harlan ignore certain problems. Another case in this point is Maildir. Harlan If somebody is in the situation where they know they have specific Harlan requirements for time, they are in the situation where they have Harlan enough altitude on their requirements to know the costs/benefits of Harlan what is involved in getting there. Unruh Well, I disagree. The sign of a good piece of software is that it Unruh does what it needs to do despite the user having a bad idea of how to Unruh accomplish the task. Sounds like NTP. Folks often have pretty bad ideas about what they need to do or what problems they think they are solving by doing strange things and the code works anyway. Mine was a specific response to the comment that Harlan made. But more to the point, what is the *problem* you are trying to solve? You are still communicating to me that we can do *better* and I agree with you. You
Re: [ntp:questions] ntpdate.c unsafe buffer write
I've tried to keep quiet and bite my tongue at this whole ntp vs chrony thing... But something has been nagging me in the back of my head that i juat have to know the answer to... How are you measuring your results? From what I've skimmed over you are simply using each program's own generated statistics... Wouldn't a more correct way be to use an external (and calibrated) device to measure / compare to ensure the results are actually valid? Otherwise you are in essence comparing apples to oranges... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS with PPS without any soldering requirements?
[EMAIL PROTECTED] (Chris Adams) writes: The way I finally got mine working in a stable setup was to use USB for the NMEA statements and put the PPS signal over a pin on the parallel port (using shm_splc2 to get the PPS from there to ntpd) since I didn't have an available serial port. The moral is: don't buy a computer without a serial port :) This way I also don't need another power source. You can also draw power from a USB port without actually connecting a USB device or transferring any data over it. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS with PPS without any soldering requirements?
Folkert van Heusden wrote: Hi, Are there any cheap GPS receivers which emit a PPS signal and can be used directly without any soldering? E.g. usb or rs232. Forget the USB. USB has unpredictable latencies that make it a poor choice for timing. If you can't, or won't, use a soldering iron, you can pay someone to do it for you. It's possible that someone could be persuaded to buy a case at a time, add a DB-9 or DB-25 connector and 5V power supply and resell them as Plug-N-Play. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] UML/architecture picture of NTP?
Harlan Stenn wrote: [] This is the first request I have see for them, and leaves me with two questions: 1) how many folks want UML diagrams of the (protocol) architecture of NTP? 2) how much are how many folks willing to pay for their creation and maintenance? Not wanted here, thanks. David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpdate.c unsafe buffer write
So, no, I am comparing apples to apples ( the offsets as determined from the ntp packet exchange mechanism which both use and both report). Another approach is to setup a 3rd machine to watch both. -- 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] ntpdate.c unsafe buffer write
Guys, There seems to some misinformation here. Both ntpdate and ntpd -q set the offset with adjtime() and then exit. After that, stock Unix adjtime() slews the clock at rate 500 PPM, which indeed could take 256 s for an initial offset of 128 ms. A prudent response would be to measure the initial offset and compute the time to wait. The ntp-wait script waits for ntpd to enter state 4, which could happen with an initial offset as high as 128 ms. The ntpd time constant is purposely set somewhat large at 2000 s, which results in a risetime of about 3000 s. This is a compromise for stable acquisition for herky-jerky Internet paths and speed of convergence for LANs. For typical Internet paths the Allan intercept is about 2000 s. For fast LANs with nanosecond clock resolution, the Allan intercept can be as low as 250s, which is what the kernel PPS loop is designed for. Both the daemon and kernel loops are engineered so that the time constant is directly proportional to the poll interval and the risetime scales directly. If the poll exponent is set to the minimum 4 (16 s) the risetinme is 500 s. While not admitted in public, the latest snapshot can set the poll interval to 3 (8 s), so the risetime is 250 s. This works just fine on a LAN, but I would never do this on an outside circuit. Dave Unruh wrote: Harlan Stenn [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes: David Harlan Stenn wrote: Why would ntpd be exiting during a warm start? David Because we are discussing using it with the -q option. If you just David use -g, it will take a lot longer to converge within a few David milliseconds, as it will not slew at the maximum rate. If you use David -q, you need to force a step if you want fast convergence. I still maintain you are barking up the wrong tree. In terms of the behavior model of ntp, state 4 is as good as it gets. You are in the right ballpark. And as has been commented on numerous times, ntp is state 4 is very slow to converge to the best possible time control. This was a deliberate design decision, as I understand it, so that in steady state the time is averaged over a large number of samples ( not helped by the fact that 85% of samples are thrown away), to reduce the statistical error in the clock control. Note that at poll 7 the number of actual samples averaged over in the time scale of the ntp feedback loop is only about 3, so the statistical averaging even with such a long time constant, is not very good. If you want something else, something you consider better than state 4, please make a case for this and lobby for it. I think many people have lobbied for faster response. In the discussion of the chrony/ntp comparison, chrony is much faster to correct errors, and at least on a local network, better at disciplining the clock as well ( in part I think because on such a minimal round trip network, the frequency fluctuations dominate over the offset measurement errors-- Ie, the Allen intercept is much lower than the assumed 1500 sec. in that kind of situation-- also the drift model on real systems is not well modeled by 1/f noise.) So, what I think the point is that using ntpdate, one can rapidly bring the clock into a few msec of the correct time, rather than waiting for the feedback loop to finally eliminate that last 128msec of offset. For the case I'm describing the startup script sequence is to fire up 'ntpd -g' early. If there are applications that need the system clock to be on-track stable (even if a wiggle is being dealt with), that's 'state 4', and running 'ntp-wait' before starting those services is, to the best of my knowledge, all that is required. David State 4 means within 128ms and using the normal control loop, which David has a time constant of around an hour. OK, and so what? Is State 4 insufficient for your needs, or are you just splitting hairs? David For a cold start, it won't reach state 4 for a further 900 seconds David after first priming the clock filter. If the system has a good drift file, I disagree with you. David The definition of cold start is that there is no drift file. OK, now I know what the definitions are. I don't recall offhand the expected time to hit state 4 without a drift file. 1) This should not be the ordinary case 2) How does this have any bearing on the ntpdate -b discussion? And what is the big deal with using different config files? The config file mechanism has include capability so it is trivial to to easily maintain common 'base' configuration with customizations for separate start/run phases. David You are now talking about using -q. The difficulty is that people David have enough trouble getting the run phase config file right. I mention it because it's what you seem to be insisting on talking about. I was providing a way to address the problems you describe with
