Re: [ntp:questions] PPS via USB-to-serial adapter
In article Miroslav Lichvar writes: >On 2019-08-14, Per Hedeland wrote: >> Anyway, back to the FreeBSD post, it seems there are actually two >> questions: >> >> 1) Is the ~ 200 usec offset reported by ntpd really semi-constant (and >>thus "easy to deal with")? > >My understanding is that the error in the measurement is moving in an >interval at a speed which depends on a hidden frequency offset. ntpd >uses a median from multiple samples for controlling the clock. If the >frequency offset is large enough and the polling interval long enough, >the median should be stable and close to the middle of the interval. Hm, I guess that could be an alternate explanation (FWIW, the ntpd poll interval was clamped to 16 s via minpoll=maxpoll=4), but... - The test used one USB 1.1 and one USB 2.0 adapter, which should supposedly poll at nominally 1 kHz and 4 kHz, respectively. I.e. "middle of the interval" ought to be 500 usec and 125 usec, respectively, plus some "really constant" offset, while ntpd reported close to 200 usec for both. And, I would expect such a drifting offset to be reflected in a higher jitter. --Per ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS via USB-to-serial adapter
In article Miroslav Lichvar writes: >On 2019-08-11, Per Hedeland wrote: >> https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html >> >> TL;DR^2 The author carried out a pretty sophisticated (IMHO) test with >> two different USB-to-serial adapters feeding PPS to ntpd, and found an >> offset of some 200 usec with 20-30 usec jitter. You can of course tell >> ntpd to correct for the offset (once you know how large it is...), and >> the jitter doesn't seem too bad to me, although it is of course higher >> than for more "direct" connections. > >An offset of 200 microsecond is much larger than a typical error of NTP >in a local network, so maybe that's why people don't like refclocks over >USB. Just to avoid sounding like a broken record, I quote from the post you point to below: "The USB PPS has a ~125us static offset which is possibly from the USB hub buffering the data. Static offsets are easy to deal with, so I removed it for this graph." >However, with a custom driver and firmware it's possible to reduce the >offset and jitter to few microseconds. See this great post from Dan >Drown: > >https://blog.dan.drown.org/pps-over-usb/ Very interesting, although I suspect that having a USB "adapter" where you can modify the firmware, *and* modifying that firmware, is a bit "out of reach" for most users... Anyway, back to the FreeBSD post, it seems there are actually two questions: 1) Is the ~ 200 usec offset reported by ntpd really semi-constant (and thus "easy to deal with")? 2) If it is semi-constant, why? Interestingly, Dan's post above shows exactly the sawtooth pattern across 1000 usec for the USB latency that I would expect if the USB polling was done with a frequency that wasn't exactly an integral number of periods per second. And he determines that this matches the system clock error of 2.215 ppm, concluding "This probably means USB on this system shares the same clock as the system clock". And, in the FreeBSD post, the system a.k.a. kernel clock is actually generated from the 10 MHz clock that is used to generate the PPS signal, in order to achieve the "ideal world": In an ideal world, there would be no measurement jitter, or frequency drift in the kernel clock, and thus all PPS measurements made would be directly comparable to each other without having to ascribe any part of the differences between sources to the kernel clock. So it seems the answers are 1) yes, and 2) because apparently on this system too "USB shares the same clock as the system clock", and thus the USB polling frequency is actually locked to the 10 MHz clock (which is essentially what Jakob suspected in the other subthread, I guess). I.e. a *real* setup using the normal kernel clock would *not* have a semi-constant offset. --Per ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS via USB-to-serial adapter
In article Jakob Bohm writes: >On 11/08/2019 15:44, Per Hedeland wrote: >> Hi, >> >> Since the idea of using a USB-to-serial adapter for PPS is often >> dismissed here as more or less pointless/useless, (due to the inherent >> delays in the USB communication AFAIU), I found this recent post to a >> couple of FreeBSD mailing lists quite interesting: >> >> https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html >> >> TL;DR^2 The author carried out a pretty sophisticated (IMHO) test with >> two different USB-to-serial adapters feeding PPS to ntpd, and found an >> offset of some 200 usec with 20-30 usec jitter. You can of course tell >> ntpd to correct for the offset (once you know how large it is...), and >> the jitter doesn't seem too bad to me, although it is of course higher >> than for more "direct" connections. >> >> In subsequent discussion he pointed out that it is significant that >> the test was done on FreeBSD - while he would expect similar results >> on Linux, performance on Windows would be "all bets off" due to >> varying driver quality. >> >> --Per Hedeland >> > >One of the hard parts is that the USB protocol is essentially polling at >either 1kHz (USB 1.1 speeds) or 4kHz (USB 2.0 ~280Mbps speed). This may >be suitable for syncing around ms range. > >Thus if the USB controller clock in the computer is running close to >its nominal speed, the delta between actual PPS pulse and USB event >reaching the computer will be almost constant, varying only by the >jitter and speed error of the USB controller clock, wrapping at 1000 or >250 usec. Hm, I certainly don't know much about these details, but I have a hard time seeing how this "almost constant" delta could explain the results in the linked message. I'm not sure I'm getting the math right here, but as far as I can see, assuming a clock that is only 1 ppm off, (e.g.) the 1kHz clock would accumulate a full period of "offness" in 1000 seconds, and during those 1000 seconds the delta would vary across the whole 1000 usec interval. If this is really the case, wouldn't this show up as a very high jitter from ntpd's point of view? And/or an offset that was at least half the 1000 usec interval, or possibly varying across that interval? >I haven't checked the iMX.6 datasheet for its USB controller internals >(for example, does it take the frame clock from the 24MHz-derived bit >lock or the from another clock that is closer to the PPS-synced clock in >his experiments). A subsequent message in the FreeBSD list thread (https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016082.html) states that the USB clock in the test case is not *derived* from the 10 MHz clock that was used to generate the PPS signal, which could otherwise explain the low jitter I guess - per above, I can't see how the clock being "close" could do it. >I also haven't grabbed a copy of the serial port adapter USB subclass >specification to check if there is something not happening at frame >boundaries somehow. This sounds very interesting, but again my knowledge is limited... --Per ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS via USB-to-serial adapter
In article Jakob Bohm writes: >On 13/08/2019 13:24, Per Hedeland wrote: >> In article Jakob Bohm > writes: >>> On 11/08/2019 15:44, Per Hedeland wrote: >>>> Hi, >>>> >>>> Since the idea of using a USB-to-serial adapter for PPS is often >>>> dismissed here as more or less pointless/useless, (due to the inherent >>>> delays in the USB communication AFAIU), I found this recent post to a >>>> couple of FreeBSD mailing lists quite interesting: >>>> >>>> https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html >>>> >>>> TL;DR^2 The author carried out a pretty sophisticated (IMHO) test with >>>> two different USB-to-serial adapters feeding PPS to ntpd, and found an >>>> offset of some 200 usec with 20-30 usec jitter. You can of course tell >>>> ntpd to correct for the offset (once you know how large it is...), and >>>> the jitter doesn't seem too bad to me, although it is of course higher >>>> than for more "direct" connections. >>>> >>>> In subsequent discussion he pointed out that it is significant that >>>> the test was done on FreeBSD - while he would expect similar results >>>> on Linux, performance on Windows would be "all bets off" due to >>>> varying driver quality. >>> >>> One of the hard parts is that the USB protocol is essentially polling at >>> either 1kHz (USB 1.1 speeds) or 4kHz (USB 2.0 ~280Mbps speed). This may >>> be suitable for syncing around ms range. >>> >>> Thus if the USB controller clock in the computer is running close to >>> its nominal speed, the delta between actual PPS pulse and USB event >>> reaching the computer will be almost constant, varying only by the >>> jitter and speed error of the USB controller clock, wrapping at 1000 or >>> 250 usec. >> >> Hm, I certainly don't know much about these details, but I have a hard >> time seeing how this "almost constant" delta could explain the results >> in the linked message. I'm not sure I'm getting the math right here, >> but as far as I can see, assuming a clock that is only 1 ppm off, >> (e.g.) the 1kHz clock would accumulate a full period of "offness" in >> 1000 seconds, and during those 1000 seconds the delta would vary >> across the whole 1000 usec interval. >> >> If this is really the case, wouldn't this show up as a very high >> jitter from ntpd's point of view? And/or an offset that was at least >> half the 1000 usec interval, or possibly varying across that interval? No comment on that? >>> I haven't checked the iMX.6 datasheet for its USB controller internals >>> (for example, does it take the frame clock from the 24MHz-derived bit >>> lock or the from another clock that is closer to the PPS-synced clock in >>> his experiments). >> >> A subsequent message in the FreeBSD list thread >> (https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016082.html) >> states that the USB clock in the test case is not *derived* from the >> 10 MHz clock that was used to generate the PPS signal, which could >> otherwise explain the low jitter I guess - per above, I can't see how >> the clock being "close" could do it. > >Hence my note that I don't know if the iMX.6 chip uses the USB bit clock >crystal or the rubidium reference clock to control the USB frame rate. OK, but now you know that the rubidium reference clock is *not* used for that... >>> I also haven't grabbed a copy of the serial port adapter USB subclass >>> specification to check if there is something not happening at frame >>> boundaries somehow. >> >> This sounds very interesting, but again my knowledge is limited... >> > >Also note that the original post essentially argues that "if you only >want 0.2ms accuracy, this is plenty good" (paraphrased), which could >have been concluded without that experiment. I'm not sure that I would call 0.2 ms "ms range", but of course it's not *really* good - but as I noted earlier, ntpd can correct for a (semi-)constant known offset (via 'fudge time1'), and the reported jitter is definitely *not* "ms range". --Per ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] PPS via USB-to-serial adapter
Hi, Since the idea of using a USB-to-serial adapter for PPS is often dismissed here as more or less pointless/useless, (due to the inherent delays in the USB communication AFAIU), I found this recent post to a couple of FreeBSD mailing lists quite interesting: https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html TL;DR^2 The author carried out a pretty sophisticated (IMHO) test with two different USB-to-serial adapters feeding PPS to ntpd, and found an offset of some 200 usec with 20-30 usec jitter. You can of course tell ntpd to correct for the offset (once you know how large it is...), and the jitter doesn't seem too bad to me, although it is of course higher than for more "direct" connections. In subsequent discussion he pointed out that it is significant that the test was done on FreeBSD - while he would expect similar results on Linux, performance on Windows would be "all bets off" due to varying driver quality. --Per Hedeland ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Synchronizing contrived time
In article caazntxhzopyu_dwcpvmye-wpacmnmxzx3wk+rkgdpnul0lw...@mail.gmail.com Amit Dor-Shifer amit.dor.shi...@gmail.com writes: $ cat ~/test_ntpd/ntp.conf server 127.127.1.0 minpoll 4 maxpoll 4 $ sudo ntpd -g -f ~/test_ntpd/ntp.conf ^^^ Mar 11 19:54:06 ntpd[31081]: format error frequency file /home/amit/test_ntpd/ntp.conf $ man ntpd ... ntpd [-aAbDdgLmnPqx] [-c conffile] [-f driftfile] [-k keyfile] [-l logfile] [-p pidfile] [-r broadcastdelay] [-s statsdir] [-t key] [-v variable] [-V variable] I.e. you need '-c' to give an alternate config file. --Per Hedeland ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Help with cross-compiling NTP for the Raspberry Pi requested
In article lfcomm$at5$1...@dont-email.me David Taylor david-tay...@blueyonder.co.uk.invalid writes: There's a discrepancy here I am unsure about. When I run the script: sntp/libevent/build-aux/config.guess on the Raspberry Pi, for host I get: armv6l-unknown-linux-gnueabihf but, as you will see, the prefix above is: arm-bcm2708hardfp-linux-gnueabi- You don't need to worry a whole lot about that, these names/prefixes are somewhat arbitrary. I did try adding the directory in front of the existing PATH, but I still got the wrong sized executables. Let me try with: --host=arm-bcm2708hardfp-linux-gnueabi- Did you actually manage a successful run of 'configure' with that argument? I don't have a Linux cross-compilation environment for RPi, but I happen to have a FreeBSD one (for FreeBSD on RPi of course:-) - it doesn't use the prefix you have but I arranged that, downloaded the stable ntp-4.2.6p5, and ran ./configure --host=arm-bcm2708hardfp-linux-gnueabi- with the result: ... checking host system type... Invalid configuration `arm-bcm2708hardfp-linux-gnueabi-': machine `arm-bcm2708hardfp-linux-gnueabi' not recognized configure: error: /bin/sh ./config.sub arm-bcm2708hardfp-linux-gnueabi- failed Obviously, at this point it is futile to try to run 'make'. The correct --host option for your case is --host=arm-bcm2708hardfp-linux-gnueabi - note the absence of the trailing '-'. When I use that with 'configure' and my tweaked cross-compilation environment, it succeeds. The subsequent 'make' fails when building 'tickadj', I haven't tried to look into why, but 'ntpd' was sucessfully built (on a x86 host): $ file ntpd/ntpd ntpd/ntpd: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for FreeBSD 10.0 (1000510), not stripped I haven't tried running it though, since my Pi currently runs Linux... --Per Hedeland ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Why can't clocks do inital synchronization?
In article 9bca36-5p@mail.specsol.com j...@specsol.spam.sux.com writes: Unruh unruh-s...@physics.ubc.ca wrote: j...@specsol.spam.sux.com writes: Have you never heard of calling ntpdate before starting the NTP daemon? uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. Uhh, lots of mainline 'nix's don't have a -g option to ntpd and still have ntpdate, e.g. Solaris 10. FWIW, and still quite irrelevant to the original question, while the version shipped with Solaris 10 (xntpd actually) is indeed based on ancient code, it does have a -g option: # uname -sr SunOS 5.10 # /usr/lib/inet/xntpd -v /usr/lib/inet/xntpd: option requires argument -v usage: /usr/lib/inet/xntpd [ -abdgmx ] [ -c config_file ] [ -e e_delay ] [ -f freq_file ] [ -k key_file ] [ -l log_file ] [ -p pid_file ] [ -r broad_delay ] [ -s statdir ] [ -t trust_key ] [ -v sys_var ] [ -V default_sysvar ] It's not documented, and may not do exactly what the current version of -g does, but something pretty close. --Per Hedeland p...@hedeland.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
In article 6zydnasrfpna1dbunz2dnuvz_qrin...@megapath.net hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes: In article ywn94p108yb7@ntp1.isc.org, Harlan Stenn st...@ntp.org writes: I'm glad it is working for you and I'd be even happier if we could figure out why the NULL string got where it did earlier, as ntpd should never drop core like that. It might be just a simple bug. The code in that area says: if ((len = readlink(device,buffer,sizeof(buffer))) == -1) return(0); buffer[len] = 0; if ((nmea_host = strtok(buffer,:)) == NULL) return(0); nmea_port = atoi(strtok(NULL,:)); The idea is that if you are using the nmead, then /dev/gps0 will be a synbilic link to someting like server:port so nmea_host will be the server and nmea_port will be the port number. And if it isn't, but rather a link to (say) /dev/ttyS0, nmea_host will get the whole /dev/ttyS0 (the first colon-separated token), the second strtok() will return NULL since there are no more tokens, and atoi(NULL) shouldn't be expected to do anything more meaningful than crash. Better code would be char *p; ... if ((p = strtok(NULL,:)) == NULL) return 0; nmea_port = atoi(p); --Per Hedeland p...@hedeland.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Generating keys for ntpdc control
In article [EMAIL PROTECTED] Bob [EMAIL PROTECTED] writes: Per Hedeland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In article [EMAIL PROTECTED] Bob [EMAIL PROTECTED] writes: Steve Kostecke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] None of the following is germane to your symmetric key issue, but ... keys C:\Program Files\NTP\etc\ntp.keys enable auth Auth is enabled by default. It can be disabled on the command-line. The worst that can happen is this line will generate an extra log entry. I disabled auth earlier this week, and promptly got attacked. I did an enable auth with the intention of reversing my disable auth. Unless someone has done something really bad to current versions of the code, enable/disable auth has nothing to do with ntpdc control commands - those *always* require authentication, and if you haven't configured a key file, they just cannot be done. If (as you claimed earlier) your config got changed by someone else, you have bigger problems to chase (as in someone has broken into your system). I suspect that you were just seeing a badly-behaved client trying to get time from your server, though. There was no change to my config file. No, there is no code in ntpd to write to the config file, but of course changing the running config is serious enough. I noticed that I was frequently polling a single server in addition to my normal list, which were being polled at their normal rate. How did you determine that you were polling that server, and not just sending replies to requests? I looked at my server list, via ntpdc, and there was about 15 entries for the same IP. What exact ntpdc command did you use for this? --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Unauthorized remote server configuration
In article [EMAIL PROTECTED] Bob [EMAIL PROTECTED] writes: It's happened again. I disabled auth last night after my previous post, and let it run overnight with Wireshark capturing I've now got two IP addresses listed as peers that I did not add. They are listed as sym_passive. I see requests from these sites listed as mode 1 in monlist. Looking at the Wireshark packet captures, the packet from the remote that seems to make me start polling the remote contains a flag of Symmetric Mode Active. I got a number of packets from this same remote that I began polling, that when looked at with Wireshark, did things like changing polling frequency. All had Symmetric Mode Active set. My polls all have Symmetric Mode Passive set. OK - I'll defer to others about whether 'disable auth' is supposed to have this effect or it's a bug, but I think it's clear that they aren't actually changing your config as ntpdc commands may do (they are mode 7 IIRC). I believe that what you see is the equivalent of other systems having you configured as peer rather than server. --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Generating keys for ntpdc control
In article [EMAIL PROTECTED] Bob [EMAIL PROTECTED] writes: Steve Kostecke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] None of the following is germane to your symmetric key issue, but ... keys C:\Program Files\NTP\etc\ntp.keys enable auth Auth is enabled by default. It can be disabled on the command-line. The worst that can happen is this line will generate an extra log entry. I disabled auth earlier this week, and promptly got attacked. I did an enable auth with the intention of reversing my disable auth. Unless someone has done something really bad to current versions of the code, enable/disable auth has nothing to do with ntpdc control commands - those *always* require authentication, and if you haven't configured a key file, they just cannot be done. If (as you claimed earlier) your config got changed by someone else, you have bigger problems to chase (as in someone has broken into your system). I suspect that you were just seeing a badly-behaved client trying to get time from your server, though. --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ACTS Problem with Internal Modem
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: ATB1C0D2E0L1M1Q0V1 OK --THERE WAS AN ATZ ISSUED HERE OK ATB1C0D2L3M1Q0V1 -- SAME SETUP STRING MINUS THE E0 AS I WANTED TO SEE THE STRING I have long since forgotten what most of that stuff does, I just thought that I should point out that you didn't just remove E0, you also changed L1 to L3 - might be significant? --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
In article [EMAIL PROTECTED] Tom Smith [EMAIL PROTECTED] writes: Per Hedeland wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] (Danny Mayer) writes: Per Hedeland wrote: In article [EMAIL PROTECTED] Tom Smith [EMAIL PROTECTED] writes: Rick Jones wrote: Rick Jones [EMAIL PROTECTED] wrote: Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 Scratch that - I commented-out the last two servers. rick jones I think you may have problems, even in the mythical zero-latency network, getting the skew consistently below double the clock tick of the system with the largest clock tick interval. Hm, if you were a newbie here, I'd assume that you simply don't know what you're talking about, but since you aren't, I must be misunderstanding you as you appear to be saying that two Unix hosts with the traditional 100 Hz clock (on the same LAN) couldn't achieve a skew consistently below 20 ms - while (at least) sub-millisecond offsets in such setups are commonplace and discussed here every other day. Apparently not even Windows has the kind of problem you suggest anymore. While Rick may be a relative newbie to NTP he has had years of conducting performance analysis of applications and systems. His performance testing of BIND9 is probably *the* seminal reference on DNS testing. Uh, your point being? I'm sure your description is correct even though I have no knowledge of that subject (which doesn't seem to be relevant here), and I specifically said that I *didn't* consider Rick a newbie to NTP - based on the very limited knowledge of *that* subject that I have, namely past postings in this forum. Which is why I found his statement surprising, and assumed that I must be misunderstanding it. Are you saying that you agree with that statement? Or maybe you can explain how I'm misunderstanding it? Well, lets see if we can reduce the confusion a little. ;-) Rick (Jones) is the author of netperf. He deals with quite a large number of platforms, releases of those platforms, and combinations thereof. Tom (Smith) happens to work for the same company as Rick, also deals with quite a large number of platforms, releases, combinations, and with customers with large heterogeneous and problematic NTP networks, among other things. Per's question was to Tom's comment, not Rick's, and Tom's comment was to Rick, not Per. I imagine Rick may be just sitting on the sidelines scratching his head at this point wondering what he did wrong. Thanks for that - I actually knew that I was responding to Tom initially:-), and will blame Danny's message (which then seems even more pointless) for making me mix up the names...:-) Now I'm just wondering if Tom Smith at alum.mit.edu is the same person as Tom Smith at cag.zko.hp.com?:-) Well, I guess I'm also still wondering whether the latter is actually saying that it won't be possible to get the skew below 20 ms with Unix hosts with 100Hz clocks, but it's not really important - the important thing is that such a statement (if made) is not correct. --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
In article [EMAIL PROTECTED] [EMAIL PROTECTED] (Danny Mayer) writes: Per Hedeland wrote: In article [EMAIL PROTECTED] Tom Smith [EMAIL PROTECTED] writes: Rick Jones wrote: Rick Jones [EMAIL PROTECTED] wrote: Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 Scratch that - I commented-out the last two servers. rick jones I think you may have problems, even in the mythical zero-latency network, getting the skew consistently below double the clock tick of the system with the largest clock tick interval. Hm, if you were a newbie here, I'd assume that you simply don't know what you're talking about, but since you aren't, I must be misunderstanding you as you appear to be saying that two Unix hosts with the traditional 100 Hz clock (on the same LAN) couldn't achieve a skew consistently below 20 ms - while (at least) sub-millisecond offsets in such setups are commonplace and discussed here every other day. Apparently not even Windows has the kind of problem you suggest anymore. While Rick may be a relative newbie to NTP he has had years of conducting performance analysis of applications and systems. His performance testing of BIND9 is probably *the* seminal reference on DNS testing. Uh, your point being? I'm sure your description is correct even though I have no knowledge of that subject (which doesn't seem to be relevant here), and I specifically said that I *didn't* consider Rick a newbie to NTP - based on the very limited knowledge of *that* subject that I have, namely past postings in this forum. Which is why I found his statement surprising, and assumed that I must be misunderstanding it. Are you saying that you agree with that statement? Or maybe you can explain how I'm misunderstanding it? --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
In article [EMAIL PROTECTED] Tom Smith [EMAIL PROTECTED] writes: Rick Jones wrote: Rick Jones [EMAIL PROTECTED] wrote: Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 Scratch that - I commented-out the last two servers. rick jones I think you may have problems, even in the mythical zero-latency network, getting the skew consistently below double the clock tick of the system with the largest clock tick interval. Hm, if you were a newbie here, I'd assume that you simply don't know what you're talking about, but since you aren't, I must be misunderstanding you as you appear to be saying that two Unix hosts with the traditional 100 Hz clock (on the same LAN) couldn't achieve a skew consistently below 20 ms - while (at least) sub-millisecond offsets in such setups are commonplace and discussed here every other day. Apparently not even Windows has the kind of problem you suggest anymore. With the skew you're looking for, you'd need systems with microsecond clock accuracy and resolution, and that probably means systems with one or another iterations on the way to the nano-kernel. Again I think I must be misunderstanding you, since virtually all Unix systems have had microsecond clock *resolution* for many years. --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
In article [EMAIL PROTECTED] Jan Ceuleers
[EMAIL PROTECTED] writes:
Jan Ceuleers wrote:
Per Hedeland wrote:
On Linux, a simpler way can be to look at /proc/interrupts - e.g.
(probably Linux-version- and possibly config-specific):
$ (cat /proc/interrupts; sleep 10; cat /proc/interrupts) | \
awk '/timer/{prev=now; now=$2} END{printf %dHz\n,
int((now-prev)/10)}'
This yields 41Hz on my Via C7 machine (which has frequency scaling and
runs a 2.6.22-based kernel) while it's idle, and a higher number (e.g.
90Hz) while it's doing something. It yields 100Hz on a Soekris 4801
running 2.4.31.
In other words, this method doesn't seem to be entirely reliable,
possibly as a side effect of frequency scaling.
Yeah, so add another (rather obvious I think) caveat to the two I
already gave. But unless the system is quite broken, i.e. a 'sleep 10'
doesn't actually last for 10 seconds, it does produce the average number
of clock interrupts per second during those 10 seconds - and as
mentioned elsewhere, if that number varies wildly, ntpd may not be very
happy anyway. FWIW, Hal's method is likely to get a value closer to the
nominal or max HZ on such a system, as it will keep the CPU/kernel
somewhat busy - maybe firing up a 'while :; do :; done' before running
the above will give a better value too.
Found this method:
# getconf CLK_TCK
100
Works on both machines.
Are you sure?:-) It's not universal in any case, here's a typical
semi-recent Linux (FC5 with 2.6.20-mumble):
$ (cat ... ) | awk ...
1000Hz
- which is the correct number, but
$ getconf CLK_TCK
100
I wouldn't be surprised if that number is effectively a constant - hm,
no need to guess when strace is around... - yes, that seems about right,
the only thing the program does by way of active syscalls is a
readlink() on /usr/libexec/getconf/default.
Actually, what it tells you is not HZ but (as the param name indicates)
the number of clock ticks per second - this is an abstract number
required for interpretation of the result of a times() call, and need
not be the same as the actual clock interrupt frequency - it obviously
*mustn't* be on a system where the latter varies over time. 100 is the
correct value for the 1000Hz system above - but of no interest to ntpd.
--Per Hedeland
[EMAIL PROTECTED]
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd stuck at default minpoll on stratum one
In article [EMAIL PROTECTED] Terje Mathisen [EMAIL PROTECTED] writes: Dennis Hilberg, Jr. wrote: Hi, I have a stratum one server running ntpd [EMAIL PROTECTED] with a Garmin GPS 18 LVC as a refclock. I use the shmpps driver from http://time.qnan.org/ . Since this driver only provides the PPS signal, I need to have a few other servers defined in my ntp.conf so that my ntpd knows what time it is. Here's my concern: the poll interval on those servers is always stuck at the default minpoll (64sec), even though I have not specified so. I would rather not poll those servers at such a rapid rate, but ntpd seems to be doing this on its own, as far as I know. I think this is a known problem/bug/feature: The prefer peer responsible for naming the PPS ticks is clamped at minpoll. In fact, if you adjust minpoll to 4 (i.e. 16 seconds), which can be a good idea for a GPS-class PPS signal, then you'll also lock your prefer peer at the same rate. AFAIK it's not limited to the prefer peer - note that Dennis' ntp.conf didn't have 'prefer' on *any* of the remote servers, I believe having one used to be a requirement for a PPS-only clock to work, but apparently that has changed. I.e. if you have a reference clock, *all* remote servers will be clamped at minpoll for the reference clock. --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is high jitter contagious?
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Node-1 is reporting a high jitter to ntp.xxx.com of 100 to 300 milliseconds. Node-1 is switching between using ntp.xxx.com and its local clock as its system peer. Thus the jitter is so high on a stratum 2 server than ntpd is deciding that its stratum 10 local clock is often a better time source. Regardless of node-1's time source, I expected the other nodes to be able to use node-1 as their peer. But that's not happening. All the other nodes are reporting jitters from node-1's time server from a few hundred milliseconds to maxing out at 4000 milliseconds. Only a few of the nodes have selected node-1 as a peer. The other nodes have no peer, and thus time between nodes are no longer syncing. Have you checked that ntpd on Node-1 doesn't actually keep stepping the time, due to being unable to keep in sync with ntp.xxx.com (which in turn could be due to excessive drift of the system clock)? --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Unresolved Symbol
In article [EMAIL PROTECTED] Maarten Wiltink [EMAIL PROTECTED] writes: Richard B. Gilbert [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Aggie [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] if ((pOpts-pzCurOpt != NULL) (*pOpts-pzCurOpt != NUL)) This sounds like one of those cases where the author should really have included the comment /* Check for an empty string */. ... The code says that already. If you need to take your readers by the hand and spoon-feed them the comments because the code itself is a bit chunky and hard to swallow... get better readers. I definitely agree that a comment to that effect isn't needed for anyone that is likely to be able to do anything useful with the code - in fact littering the code with comments stating the obvious makes it *harder* to maintain, since a) you will have trouble finding the comments that really *are* important for understanding the code (or they won't even be there with that style), and b) it makes it a lot likelier that the comments won't get updated along with the code. However I do think the use of NUL is unwise, having a plain '\0' there instead would avoid an initial potentially confusing misreading/misunderstanding (not incidentally, it is only the libopt code that uses NUL, the proper ntp code uses '\0' everywhere). --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
