Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
On Tue, Jan 18, 2011 at 09:48:08PM +, David Woolley wrote:
That was my point. Unruh's main issue is that, on modern LANs, the
dominant low frequency error is in the local clock, rather than the
measurements.
That's the theory behind NTP.
It's more complicated. I don't think the current version ages the
samples,
It still does, see clock_filter() in ntp_proto.c:
dtemp = clock_phi * (current_time - peer-update);
I
think the filter will take out more like 7 in 8 for gaussian input,
but the expected input pattern isn't actually gaussian, either.
I think the delay is assumed to be exponentially distributed (and
that's what I use in my simulations). It would be interesting to
analyse real data from rawstats.
Also, to answer the question whether PLL has a good lock, you can use
the runs tests. Run this command on your loopstats and we'll see if
the offset is random or not.
awk '{ n++; r += $3 * l 0; l = $3 } END { print r / n }'
--
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
At 10:35 PM 1/18/2011, Dave Hart wrote... On Wed, Jan 19, 2011 at 02:47 UTC, Mike S mi...@flatsurface.com wrote: At 02:18 PM 1/18/2011, unruh wrote... Especially as ntpd uses only one of every 8 polls, Is this relatively recent behavior? No. See the Clock filter algorithm slide 13 in: http://www.eecis.udel.edu/~mills/database/brief/arch/arch.pdf That's dated Jul2007. My point of reference is whatever version of NTP was used in Debian Lenny (4.2.4p4, from Aug2007, it seems) which is what I was running before changing to Squeeze (4.2.6p2) a couple of months ago. Perhaps a change was made about that time? Maybe I'm just getting old and feeble, but I swear ntpq -p used to update the offset with almost every poll - I would watch it after making a change to get a feel for how the offset and drift were adjusting (watch ntpq -p; ntptime). Or, perhaps, NTP used to report the most recently _measured_ offset/jitter, and was changed to reporting the most recently _used_? Another change I've noticed with very recent versions (maybe a 4.2.7p?), I didn't keep track) is that the polling interval seems to add a random time to what's expected. If watching ntpq -p, I will often see when count significantly beyond the current poll value. It doesn't indicate a missing response when it finally does seem to poll. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntpd on AIX6.1 does not start
Hello i have following problem under AIX6.1, ntpd compiles OK, but when i start the ntpd,then this error occurs : 18 Jan 17:36:33 ntpd[6357216]: init_socket_sig: ioctl(I_SETSIG, S_INPUT) failed: Operation not supported on socket can anybody help ? Thanks Dieter # some Information : NTP 4.2.6P3 DCF77 RAWDCF Clock on tty2 /temp/ntp-4.2.6p3 $ ls -l /dev/refclock-0 lrwxrwxrwx1 root system9 04 Jan 19:58 /dev/refclock-0 - /dev/tty2 AIX6.1 : /temp/ntp-4.2.6p3 $ uname -a AIX duffy-aix61 1 6 005F215D4C00 Patchlevel : /temp/ntp-4.2.6p3 $ oslevel -s 6100-06-03-1048 /temp/ntp-4.2.6p3 $ rpm -qa | grep gcc gcc-4.2.4-2 gcc-cpp-4.2.4-2 libgcc-4.2.4-2 content of /etc/ntp.conf # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. # !!! server 127.127.1.0 # local clock # !!! fudge 127.127.1.0 stratum 10 # fuer die DCF77 Clock server 127.127.8.0 mode 12 ntp was compiled with these options: ./configure --disable-ipv6 --enable-debugging --enable-all-clocks error on startup: /temp/ntp-4.2.6p3 $ ./ntpd/ntpd -4 -n -d -d ntpd 4.2.6p3@1.2290 Sun Jan 16 21:34:03 UTC 2011 (3) 18 Jan 17:41:35 ntpd[6226166]: signal_no_reset: signal 3 had flags 48 18 Jan 17:41:35 ntpd[6226166]: signal_no_reset: signal 10 had flags 48 18 Jan 17:41:35 ntpd[6226166]: set_process_priority: Leave priority alone: priority_done is 2 18 Jan 17:41:35 ntpd[6226166]: proto: precision = 1.000 usec loop_config: item 1 freq 0.00 Finished Parsing!! create_sockets(123) 18 Jan 17:41:35 ntpd[6226166]: ntp_io: estimated max descriptors: 2000, initial socket boundary: 48 18 Jan 17:41:35 ntpd[6226166]: init_socket_sig: ioctl(I_SETSIG, S_INPUT) failed: Operation not supported on socket ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
Dave Hart wrote: On Tue, Jan 18, 2011 at 19:18 PM, unruhun...@wormhole.physics.ubc.ca wrote: On 2011-01-18, David Woolleydavid@ex.djwhome.demon.invalid wrote: wander, and you set a very fast poll, you could get low offsets but a high error, because the real error is in the wander.  Increasing the No. a fast poll also corrects wander faster. ntpd is horribly slow at correcting wander, but doing it quickly corrects it faster. I would agree if you said perceived wander with measurement-induced error. In other words, while turning the slew knob faster reduces your offsets faster, doing so risks following measurement noise rather than the underlying trend. What it does not do  is to give a good estimate of wander. The drift correction flops around much more with faster polls, because of the short baseline. That does not matter if you have constant connectivity, but becomes important if you loose connectivity for any time period. It matters to me. I want my frequency slewing to ignore measurement noise, not react quickly to it. This may be complicated in that I'm not sure that the loop time constant is actually clamped by the poll rate, so it is possible that setting a high rate over samples without changing the overall behaviour.  Maybe it is clamped by maxpoll? No, it is determined by the number of readings, not by time. More readings in a given time means shorter time constant. Fewer readeings, longer. ntpd throws away 7 out of 8 readings, so the actual poll interval of used reading is 8 times as long as the set poll interval, and the time constant is about 5 times that if I remember correctly. You do not understand NTP's clock filter. As each new sample is pushed in, only one of the prior 8 samples is used for the moment, but each sample has 8 chances to be that favorite. That is not equivalent to throwing away 7 out of 8 readings on my planet. There's also the fact that for refclocks ntpd will measure/save the PPS signal that arrives every second, a larger poll interval just means that there are more samples to choose from. I.e. with minpoll 4 my Oncore or Garmin refclocks will deliver 16 samples into the core engine for every poll period. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd on AIX6.1 does not start
Dieter Geyer wrote: 18 Jan 17:41:35 ntpd[6226166]: init_socket_sig: ioctl(I_SETSIG, S_INPUT) failed: Operation not supported on socket You need to add AIX6.1 to the list of systems with broken SIGPOLLs in the configure script. There are two variables, one for UDP and one for terminal I/O. This will the the UDP one. search for SIGPOLL should get you to the right part. Please submit the resulting patch. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling interval in FreeBSD vs. Windows
Miroslav Lichvar wrote: On Tue, Jan 18, 2011 at 09:48:08PM +, David Woolley wrote: That was my point. Unruh's main issue is that, on modern LANs, the dominant low frequency error is in the local clock, rather than the measurements. That's the theory behind NTP. I should probably have said mid frequency. The specific problem with NTP that he complains about is that it sets it loop time constant too long (or more precisely fails to adapt it down fast enough) such that mid-frequency clock errors are removed from the error measurement by the loop filter and the time drifts badly in response to them. This is the behaviour you would want in respect of mid-frequency network delay variations, e.g. the sort of problem I was describing where the delay jumps up for a couple of ours around 1pm when everyone is browsing during their lunch break. (As the temperature variations (and network delay variations) often have squarish shapes, they actually have a broad spectrum.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
