Re: [ntp:questions] Adjust serial device speed in ACTS refclock driver?
Replying to Brian Inglis: Modem cards would run at whatever interface rate the system set, e.g. 19,200 or 115,200, and use the remote connect info to set the line speed. I would normally expect a sane modem to act as you described. But this TrendNet TFM-561U appears to be tying the telco line speed to be the same as the system serial port speed. The NIST ACTS supported range is 1,200-9,600. . . . I have tried connecting manually (via the cu command), and if I use any local serial port speed other than 1200 bps, I am completly unable to connect to the NIST ACTS -- the modem noise cycles through several different tones, apparently trying to negotiate a mutually acceptable speed, but eventually it times out and hangs up. I tried both init strings you quoted from the Amazon review, but no luck unless I used a local speed of 1200 (cu -l /dev/acts0 -s 1200). As for the modem connects to my ISP just fine but was really slow -- remember, I'm not trying to use this TrendNet modem to connect to an ISP -- I'm only trying to use it to connect to the NIST ACTS. Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ACTS refclock is way off w.r.t GPS refclock
Replying to William Unruh: 1200 bps is 120 characters per second. Thus the time it takes for the clock to deliver a line of characters representing the time to the computer is about a second. Makes it pretty hard to get ms accuracy, when that is far smaller than the time it takes to deliver even one character. Understood. I can't really do anything about the speed of the NIST ACTS (it appears to be fixed at 1200 bps as best I can tell) -- and I realize I'm not going to get really high accuracy here (but that's OK, this is just a fallback time source for my home LAN in the event my local GPS and my Internet connection both fail simultaneously). You could try fudging the ntpd refclock source to correct the time. . . . and you fudged time1 to .021 why? I used a fudged time1 of 0.021 because I thought the 021.3 part of the NIST ACTS data lines meant my delay should be set to around 21.3 msec. I changed the time1 fudge to 0.222 just now, and my modem refclock has an offset of -17 msec now -- not nearly as good as my local GPS, or even my link over the Internet to a collection of stratum-1 servers on my university's campus -- but given what I wanted the modem refclock for, it's OK. Thanks for suggesting that I fiddle with time1 some more. Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Does ntpq have an equivalent to ntpdc's fudge command?
Does the ntpq program have an equivalent to ntpdc's fudge command? I know ntpdc is deprecated, and I understand ntpq is supposed to be able to do everything that ntpdc can do, but I simply can't find any way to set a reference clock's flags in ntpq. I want to be able to set flag1 in an ACTS refclock (in order to schedule an immediate dialup attempt). I know how to do this with ntpdc, but I haven't been able to find the corresponding command in ntpq. Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Adjust serial device speed in ACTS refclock driver?
Is there any way, in the ACTS refclock driver, to specify the speed at which the modem's serial port should be opened? The source code (ntpd 4.2.7p475) appears to use a hard-coded speed of 19,200 bits/sec (ntpd/refclock_acts.c, line 138). I was unable to connect to the NIST time service at all -- the service picked up the line, but I heard a lot of chaotic noise (suggesting a futile attempt to negotiate a connection) until the driver eventually timed out and hung up. I can connect without any problems at all, however, if I dial up manually (using cu -s 1200 -l /dev/acts0). I changed B19200 to B1200 in the ACTS driver, and the resulting ntpd was able to connect and get valid time info from NIST. But I'd prefer a solution, if at all possible, that doesn't require changing the source code. Any thoughts? Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Adjust serial device speed in ACTS refclock driver?
Replying to Harlan Stenn: The docs say it connects at 9600, so there is a discrepancy there... Agreed. I know several folks have been using the current driver without problems, so I'm curious about what's going on here. I also know that some modems will auto-baud, but that might not matter. Some will allow the modem connect speed to be different from what is used by the serial connection to the modem. I'm using a TrendNet TFM-561U USB modem -- one of the very few modems I was able to find that is not a softmodem / winmodem and will work in a Linux system without driver software. I suspect this modem's telco line speed may be tied somehow to the serial connection speed. TrendNet didn't supply any documentation for the AT command set used by this modem, so I tried a standard telco line speed command (ATS37=5) -- this command didn't generate an error, but it had no discernible effect in ntpd. Again, when I made the driver open the serial port at 1200 bps, everything worked. The NMEA refclock uses mode bits 4/5/6 to control the baudrate, but I don't know if 8 baudrate values will be enough. Should be OK, but we might be using all the values. I assume the following speeds should be more than sufficient: 300, 1200, 2400, 9600, and 19200; maybe also 38400 and 57600. I'm not sure anyone would ever really need to use 300, but why not. So three mode bits should be fine -- probably use zero (default if no mode is set) for 19200, and 1-6 for the others. Unless at least one of the known modem time services supports or requires a very high baud rate, BTW, I'm unconvinced that supporting anything higher than 9600 is really necessary for this application. Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ACTS refclock is way off w.r.t GPS refclock
I'm running ntpd 4.2.7p475 on a server in my home LAN, with refclock_acts.c patched to open the serial line at 1200 instead of 19,200 bits/second (see my earlier e-mail Re: Adjust serial device speed in ACTS refclock driver?). The modem refclock, syncing to NIST, appears to be about 200 msec off with respect to a GPS refclock which has been running for a long time on another server in my home LAN. Here is the output of ntpq -c 'hostnames no' -c peers on the server with the modem: remote refid st t when poll reach delay offset jitter == 127.127.18.0.NIST. 3 l 83 51210.000 -204.85 0.000 *10.0.229.16310.0.229.2 2 s 27 32 170.169 -0.056 0.036 +10.0.229.2 .GPS.1 s 10 32 170.1190.056 0.024 10.0.229.11710.0.229.2 2 s 60 643 22.1330.553 0.116 Here are the relevant refclock configuration lines from the ntp.conf file: server 127.127.18.0minpoll 9 maxpoll 16 fudge 127.127.18.0stratum 3 time1 0.021 flag1 1 flag2 1 (I fudged the stratum to 3 in order not to risk having the modem refclock take over my home LAN while I'm still experimenting with it.) And here is the last line from the clockstats file: 56936 8840.501 127.127.18.0 56936 14-10-06 02:27:19 28 0 -.4 021.3 UTC(NIST) * In case it matters, I'm using a TrendNet TFM-561U USB modem. Any ideas why the modem refclock is so far off? Is there anything I can do about it? Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ACTS modem advice?
I'm running ntpd 4.2.6p5 on an Ubuntu 14.04.1 system (kernel version = 3.13.0-36-generic). I'm thinking of setting up the ACTS_MODEM driver to give me a backup time reference in case my GPS loses its signal. I have an old Conexant HSF modem card, which I was able to install on an old Linux box many years ago, but I can't seem to get it to work on my current system. The main company (Linuxant) that used to supply Linux drivers for this and similar cards has apparently lost interest, and all the web sites I can find that mention Conexant HSF modem cards are ancient (no updates in 4-5 years, claim Linux 2.6 or 2.4 is the latest kernel, etc.). Has anyone out there succeeded in getting a Conexant HSF modem to work with a current Linux system? If so, I'd be grateful for pointers to any up-to-date drivers and documentation. If getting this hardware to work today is a lost cause, what current Linux-compatible modem hardware would people suggest? It would be nice if a new modem could handle fax (so that I can use it for more than just occasional time service calls). Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Replying to Charles Elliott: The offset may be a function of distance. Try this experiment: Set up your ntp.conf file to have three servers . . . : 1. A relatively unused stratum 1 or 2 server as close to you as possible 2. A relatively unused stratum 1 or 2 server about 1,000 miles away 3. A relatively unused stratum 1 or 2 server more than 2,000 miles away OK, here is information taken from two local servers under my control. == This first machine (171.67.203.16) is on the Stanford University campus. The first two peers listed below are located on the Stanford campus; the third peer is also run by Stanford but is about 50 miles east of the campus. +171.64.7.105.PPS.1 u 1012 1024 3770.465 -0.045 0.076 +171.64.7.67 .PPS.1 u 217 1024 3770.584 -0.043 0.081 *204.63.224.70 .PPS.1 u 737 1024 3771.803 -0.031 0.252 This next peer is my home machine (the one I described earlier as being connected to the Internet via a cable modem), with its own local GPS clock. -68.65.164.12.PPS.1 u 13 16 3728.168 -2.126 4.585 Finally, these two servers are in Utah (Xmission) and Poland. -198.60.22.240 .GPS.1 u 721 1024 377 18.9310.239 0.045 -213.222.200.99 .PPS.1 u 833 1024 377 172.099 -4.083 1.167 == Now, here is the info from my home machine (68.65.164.12). First, my local GPS reference clock: *127.127.28.1.PPS.0 l 14 16 3770.000 -0.003 0.025 x127.127.28.0.GPS.8 l7 16 3770.000 -37.762 13.399 Next, my campus machine (see above for details): -171.67.203.16 204.63.224.702 u2 16 3339.6892.146 3.930 And finally, the same two remote servers (in Utah and Poland) that I used on my campus machine: +198.60.22.240 .GPS.1 u 45 64 377 35.2226.542 2.864 +213.222.200.99 .PPS.1 u 18 64 377 191.1924.890 8.968 == Any thoughts? Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Is there a way to compensate for asymmetric delay to/from one specific peer or server? My home LAN is connected to my school's network via a cable modem. There appears to be a consistent asymmetry of 2-3 msec between my home and the school's network. I can see this by comparing the time on my home server (which is synced to a local GPS) with the time on the school servers (which are synced to on-campus GPSes). I would like to be able to use the campus network as a backup time source for my home LAN, but only if I can somehow compensate for the asymmetry introduced by the cable modem infrastructure. The asymmetry does not appear to be traffic-dependent; I see pretty much the same offset (between 2 and 3 msec) at any time, day or night. I'm running NTP version 4.2.6p5@1.2349-o. Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Replying to Rob: Yes, you can use: fudge 1.2.3.4 time1 -0.002 or similar. see the manual. This didn't work. And the following error message appeared in my syslog: inappropriate address 10.0.229.163 for the fudge command, line ignored As best I can tell from the online manual, the fudge command is defined only for local reference clocks and has no effect on peers or servers. I checked the manual before asking my question but couldn't find anything. If there is something there that will help me with this problem, I'd be grateful if someone could tell me exactly where to look. Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] cgps command question
If you aren't seeing any right-hand data from cgps, I would guess this is most likely because your GPS isn't currently configured to report which satellites it can see (via $GPGSV sentences). I don't believe the output of cgps shows PPS info. Questions about gpsd and cgps should really be directed to the gpsd-users list (gpsd-us...@lists.berlios.de), so if this answer isn't sufficient, you should ask again on that list. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Fudge time offset on client/peer?
I suggest you don't want that. What you need is a fudge on the interface, not the association. In this situation, I think I really do want a fudge on the association. Consider the issue from the POV of my work desktop. My work desktop has a single network interface, connected to a conventional 100BASE-TX ethernet network. It has fast (and, for my purposes, sufficiently symmetric) connectivity over my school's campus network to stratum-1 and stratum-2 servers run by the campus IT services. In order for my work desktop to see the stratum-1 server I'm running at my home, however, it has to go over the campus network to the cable-modem network servicing the townhouse complex where I live. As I previously mentioned, this cable modem network appears to have an asymmetry, which I would like to fudge away for the benefit of my work desktop (but *not* for my home LAN). If I were to fudge the network interface of my work desktop, this would presumably affect not only its view of my home stratum-1 server, but also my work desktop's view of the campus tickers. What I think I want/need is a way to fudge my work desktop's view of one peer/server, but not another peer/server. That's why I wanted to be able to fudge an association. Rich Wales / ri...@richw.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Fudge time offset on client/peer?
A per-association fudge is not possible unless the peer mobilization code is overhauled. . . . A command might be introduced that could affect a specified association, but it would have to be given via ntpq after mobilization. Suppose I were to move the refclock to my (dual-homed) firewall -- where (in theory) a per-interface fudge could be specified for the interface to my cable modem (but *not* for the interface to my LAN). Would that make it more feasible to do what I need? Or, alternatively, could some sort of filter application be devised that would sit on my firewall (currently a Linux box) and fudge the NTP packets going between my stratum-1 server and the outside? (Yes, I agree this could easily end up being a messy kludge, but . . . .) Rich Wales / ri...@richw.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Fudge time offset on client/peer?
My home network is connected to the outside world via a cable modem. I'm running a refclock at home (on a FreeBSD server running ntpd 4.2.5p215), which I want to refer to both at home and elsewhere. The cable modem system appears to be introducing an offset of about 2 msec (compared to a refclock on my work network, which I have reason to believe is trustworthy). I would like to be able to tell ntpd (4.2.5p181) on my work machine to fudge the offset it gets from my home clock by about 2 msec, in order to counter the cable modem assymetry. However, I do *not* want to fudge the offset on the refclock itself, because I want the hosts on my home network to see the server as is. I'm not sure what to do, because as best I can tell, I can specify a fudge time1 only in connection with a refclock. Is there any way to fudge the offset on a peer or (non-refclock) server configuration command? If not, can this be considered as an enhancement? Or am I missing some very good reason why this is a Really Bad Idea that should (and will) never be implemented? Rich Wales / ri...@richw.org ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Fudge time offset on client/peer?
you might experiment with the new interleaved mode to see how it handles the asymmetry. You could peer your home and work refclock ntpds . . . . Actually, I tried that some time back, but it didn't help a bit. I eventually came to understand that xleave mode is designed to reduce the effect of processing delays inside a server's network stack. Sadly, it doesn't do a thing to alleviate asymmetries. Indeed, my current impression (someone please correct me if I'm wrong!) is that NTP is *inherently incapable* of measuring (or even detecting) network latency asymmetries -- the NTP protocol assumes that traffic comes and goes with equal speed, and it has no way to detect situations in which this is not true. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Correct; the interleaved modes, both symmetric and broadcast, are in the development version now. OK, thanks for clearing that up. Am I correct in understanding that interleaved symmetric mode would be useful if peers are on opposite sides of a cable or DSL modem infrastructure? -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP stops when client address changes?
My understanding is: - The router's WAN address can and does change. - The PC's address should not change as long as it is switched on I'm not sure it's really advisable to assume the second of the above points. On the cable modem system at my home, the host that is connected directly to the cable modem could very possibly get a different IP address when the lease runs out -- and I assume many ISP's offering only dynamic addresses (or static addresses for an extra fee) may change the address gratuitously on a new lease, just to emphasize that they can. Obviously, a host which is stuck with using a dynamic IP address in such a situation won't be of much use as a server to the outside world -- but if ntpd is syncing to external servers, it really needs to be able to use whatever address happens to be assigned to a NIC at any given time. And yes, I realize that many cable or DSL modems (unlike the one given to me for use at my home) have a builtin NAT router/firewall that will shield a user's computer from external address changes -- but this shouldn't be assumed if it doesn't have to be. In my own case, I sidestepped the problem by arranging for a static IP address (which my ISP gave me at no extra charge) -- but not everyone may be able to do this. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
The only thing interleaved modes avoid is the queuing, buffering and transmission latencies on the local operating system, driver and interface card. It doesn't suppress errors due to network latencies. Hmmmph. Yes, I see this now. Sorry I was confused earlier. As for the mysterious 8- to 10-msec discrepancy between my GPS clock and Stanford's campus NTP infrastructure, it turns out that Stanford's existing TrueTime GPS clock is old and is being phased out. My clock agrees very closely with a new Meinberg GPS clock which will become the new campus refclock soon. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
You misunderstand the usage of the xleave option which is still experimental. It requires (currently) IEEE-1588 hardware to work and it needs to be set up to send additional time-delay information down the same path as the ntp packet. I'm confused now, because the description of interleaved symmetric mode in http://www.eecis.udel.edu/~mills/onwire.html clearly claims that the NTP reference implementation does handle interleaved mode via software timestamps. Quoting from the introduction of the above page: The interleaved modes described in this section have been implemented and tested in the NTP reference implementation. In its present form only software timestamps (softstamps) are used, with the advantage that the actual transmit timestamp is captured upon return from the I/O routine and more accurately represents the on-wire hardware timestamp (hardstamp). Future plans include using driver timestamps or NIC timestamps as the opportunity arises. Thus, I assumed that if I had two servers, running ntp-dev and peering with each other, with the xleave option specified on each server for its association with the other server, they would use the two-step interleaved symmetric mode protocol described in the above web page (with software-generated time stamps) -- and that doing this should do a decent job of correcting automatically for asymmetry in the network connection, without needing to fudge the asymmetry explicitly -- and that the end result would be good as long as I wasn't expecting to get super-accurate, sub-microsecond sync (for which I admittedly would need special network cards with hardware timestamp capabilities). Am I mistaken here? -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Why is your PPS at stratum 9? It should be stratum 0. I intentionally fudged the PPS refclock to stratum 9 so it wouldn't get picked. I wanted to force the server to pick the GPS_NMEA refclock. Actually, with PPS support enabled in the GPS_NMEA driver (flag1 = 1), I finally realized I don't need the separate PPS refclock anyway -- the GPS_NMEA driver deals with the PPS just fine all by itself -- so I took it out a couple of days ago. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
My experimental stratum-1 server (using a Garmin GPS as its reference clock) continues to run stably -- albeit with an offset several msec different from the rest of my home LAN (which is synced to Stanford University's time server infrastructure). remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l28 3770.000 -0.001 0.002 PPS(0) .PPS.9 l68 3770.0000.000 0.002 *iknow.richw.org 171.64.7.115 3 u 10 16 376 10.058 -9.249 3.871 In an attempt to compare my results with something (and get some idea of which of us -- the campus server or my own -- is more likely correct), I set up a second test server here at home, using a Conexant HCF modem (a PCI device) phoning NIST in Colorado. The results from this setup appear disappointingly unstable (several msec jitter even after running all night), but the modem refclock seems to be more in agreement with the campus clock than with mine. Here are a few ntpq -p outputs from this second system (I've omitted some of my home LAN systems from the peer list to reduce clutter somewhat). remote refid st t when poll reach delay offset jitter == *sixeyes.richw.o .GPS.1 u 13 16 3760.1030.327 0.018 +iknow.richw.org 171.64.7.115 3 u 60 64 376 10.593 -8.087 1.696 ACTS_MODEM(0) .NIST. 0 l 273 512 2770.000 -5.147 3.674 remote refid st t when poll reach delay offset jitter == *sixeyes.richw.o .GPS.1 u5 16 3770.0970.127 0.014 +iknow.richw.org 171.64.7.115 3 u9 64 3779.888 -10.077 2.085 ACTS_MODEM(0) .NIST. 0 l 185 512 3770.000 -16.325 10.689 remote refid st t when poll reach delay offset jitter == *sixeyes.richw.o .GPS.1 u4 16 3770.0990.158 0.057 +iknow.richw.org 171.64.7.77 3 u2 64 3778.919 -9.841 1.103 ACTS_MODEM(0) .NIST. 0 l 120 512 3770.000 -5.147 5.961 The 171.64.7.* hosts in the above are stratum-2 servers at Stanford, which are in turn syncing to 171.64.7.87, a stratum-1 server with a TrueTime GPS receiver. Also, the delay reaching iknow.richw.org (on campus) is because I'm going through a cable modem -- but all my boxes are running ntp-dev and using xleave, which is why jitter to iknow.richw.org is low. I also checked the clockstats data on the server with the modem, and it reported timestamps ending in # (delay correction valid). I can post some of this data if anyone thinks it would matter. So, at this point, what basis (if any) would I have to conclude that my test server is or isn't accurate? And if it isn't accurate, what should I do to fix the problem? Or, if the campus server is likely to be the falseticker, how would one go about establishing that fact? In case it might matter, I checked the geographical coordinates being output by my GPS against a satellite photo from Google Maps, and it's showing my exact location to within a few feet. And the GPS claims to be consistently seeing at least seven satellites. So I would assume my GPS unit is working properly -- except for the above evidence that seems to suggest its time is off. Any thoughts or suggestions welcomed. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Kevin Oberman wrote: I don't know what the path is from your location to Stanford's NTP server . . . . I'm in a Stanford-built housing complex immediately adjacent to the campus. The extra (and likely asymmetric) delay in my case is most likely happening because my residence is connected via a cable modem infrastructure run by the Stanford campus's IT services people. NTP assumes the same delay for the return packet that it had for the request packet. If that is not the case, you will see a fixed offset. The only fix is a 'fudge' of the time for that server. If the path is unstable, even that will not work. I thought the xleave feature in ntp-dev was supposed to compensate for asymmetric paths. All my systems are running ntp-dev and peering with one another with xleave specified. The Stanford campus tickers are running production versions of ntpd (and thus not using xleave, and I'm not peering to them anyway), but I assumed I could minimize the effects of the cable modem asymmetry by syncing to the campus NTP infrastructure from iknow.richw.org (which is in my office on the main campus network and connected to my home LANvia a VPN link), and then peering between iknow and my other hosts (located physically at home) using the xleave feature in ntp-dev. In any case, when I did my experiment last night with a second server (using a modem refclock), both of my stratum-1 servers were at home -- sitting next to each other on the same table and plugged into the same 100baseT switch -- so there shouldn't have been any network delays to speak of between them -- and they still appeared to differ by several milliseconds. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Dave Hart wrote: The GPS refclock is using end-of-line timestamps . . . . If you configure the GPS to send only one sentence, or increase the serial bitrate, the offsets should come closer to zero. Rather than change the GPS to send a single sentence, you could configure the NMEA refclock to ignore all but the first one it sends, in this case $GPMRC, using mode 1 on the server 127.127.20.1 line. Thanks. I've done this, and the clockstats file shows it is now using the $GPRMC sentences. However, the offset is basically unchanged -- still around -670. How do I change the baud rate on this device? I tried a $PGRMC command with the tenth parameter equal to 5 (19200 baud), but it had no effect. I also tried connecting (via cu) at different baud rates, and issuing commands (thinking it might autodetect the speed of received data), but that also didn't change anything. The jitter figures you quoted were larger than the corresponding offsets for the Stanford associations. Wait for the jitter to be substantially less than the offset, and consider the offset to have an error band as wide as the jitter, before comparing the Stanford offsets with the PPS. OK, I'll wait and see what it's looking like in the next day or two. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
After instructing it to use a different baud rate, you have to reset the device for it to take effect, either by issuing a reset command, or by power cycling it. OK, thanks. I'll try that. I gather that the Garmin GPS has some flash RAM (or a builtin backup battery), so it retains its settings even if power is removed? Also, once you have it talking at a rate other than 4800 bps, you'll need to inform ntpd to open the port at that rate by using an appropriate mode value on the server 127.127.20.1 line. Right. I saw that in the NTP documentation. I tried it early on, thinking that perhaps the driver would use the mode value to set the GPS's baud rate -- but, of course, that didn't work. Before I try resetting the baud rate, here's what the GPS currently looks like on my test server (sixeyes.richw.org). The jitter values have gone way down, but the GPS offset is still high (even with the mode set to look at only $GPRMC), and the PPS offset still differs by several msec from Stanford's clock. remote refid st t when poll reach delay offset jitter == xGPS_NMEA(0) .GPS.9 l9 16 3770.000 -629.69 4.781 xPPS(0) .PPS.8 l6 16 3770.0003.811 0.055 +liberation.rich 10.0.229.53 5 u3 16 3772.196 -0.244 0.695 +whodunit.richw. 10.0.229.114 4 u 12 32 3772.211 -0.264 0.423 *iknow.richw.org 171.64.7.55 3 u9 32 3779.242 -1.457 4.772 And on iknow.richw.org (the box my test server, sixeyes, is syncing to): remote refid st t when poll reach delay offset jitter == liberation.rich 10.0.229.53 5 u 10 3207.3880.785 0.000 whodunit.richw. 10.0.229.114 4 u 208 256 3767.1260.948 2.469 sixeyes.richw.o 127.0.0.1 13 u 16 32 3769.3751.419 1.033 +Avallone.Stanfo 171.64.7.87 2 u 241 1024 3770.756 -0.648 0.192 *caribou.Stanfor 171.64.7.87 2 u 150 1024 3770.796 -2.838 0.265 +dusk.Stanford.E 171.64.7.87 2 u 696 1024 3770.774 -0.560 0.273 In case it matters here, iknow is on the campus network (in my office), and it's linked via OpenVPN to my home LAN. I'm using interleaved mode to compensate for the fact that Internet service to my home goes through a cable modem infrastructure. And, finally, the view from grandfather.stanford.edu (the stratum-1 server which Stanford's stratum-2 boxes are syncing to): remote refid st t when poll reach delay offset jitter == *TRUETIME(1) .GPS.0 l8 64 3770.000 -0.741 1.203 +bigben.cac.wash .USNO. 1 u 678 1024 377 21.6879.502 0.177 +clock.isc.org .GPS.1 u 688 1024 3774.7062.829 0.131 You might remember I brought up the issue, some time ago, of how the University of Washington's server (bigben) appears to be way off. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
OK, I reset my GPS to 19200 baud and configured it to emit only $GPGGA sentences, along with a 100-msec-wide PPS. I also changed ntp.conf to poll GPS and PPS every 8 (instead of 16) seconds. It's been running for about an hour now, and the jitters are pretty low. Here's a current result of running ntpq -p. remote refid st t when poll reach delay offset jitter == xGPS_NMEA(0) .GPS.9 l78 3770.000 -604.42 11.346 xPPS(0) .PPS.8 l68 3770.0004.354 0.017 +liberation.rich 10.0.229.53 5 u 15 16 3762.121 -4.407 0.527 +whodunit.richw. 10.0.229.114 4 u 15 64 3762.142 -4.146 0.345 *iknow.richw.org 171.64.7.55 3 u 56 64 3768.176 -4.002 1.650 Even with the baud rate increase, the GPS offset is still almost as big as it was before. And the difference between my local PPS's offset and that of one of my systems (iknow) which is on our campus network and is synced to one of our campus stratum-2 servers still seems significant, even after letting my server run long enough that the jitter is really small. In case it might help, here's the rl 0 output for my test server: associd=0 status=00f8 leap_none, sync_unspec, 15 events, no_sys_peer, version=ntpd 4.2.5p...@1.1934-o Tue Jul 28 05:47:52 UTC 2009 (1), processor=i386, system=FreeBSD/7.2-RELEASE, leap=00, stratum=13, precision=-19, rootdelay=0.000, rootdisp=5.000, refid=127.0.0.1, reftime=ce1f0d49.d72897dd Sat, Aug 1 2009 11:51:53.840, clock=ce1f0e0a.62d9013b Sat, Aug 1 2009 11:55:06.386, peer=0, tc=6, mintc=3, offset=-4.244, frequency=91.117, sys_jitter=1.548, clk_jitter=5.218, clk_wander=0.441, tai=34, leapsec=20090101, expire=20091228 and a peer listing from my system iknow.richw.org (mentioned above): remote refid st t when poll reach delay offset jitter == liberation.rich 10.0.229.53 5 u2 1607.3880.785 0.000 whodunit.richw. 10.0.229.114 4 u 70 256 3766.857 -0.267 0.779 sixeyes.richw.o 127.0.0.1 13 u 19 64 3778.1293.979 1.684 +Avallone.Stanfo 171.64.7.87 2 u 249 1024 3770.8081.907 0.932 *caribou.Stanfor 171.64.7.87 2 u 284 1024 3770.9520.456 1.109 +dusk.Stanford.E 171.64.7.87 2 u 806 1024 3770.8161.740 0.897 and the result of rl 0 from iknow.richw.org: associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version=ntpd 4.2.5p...@1.1881-o Tue Jun 16 21:48:24 UTC 2009 (1), processor=i686, system=Linux/2.6.28-13-generic, leap=00, stratum=3, precision=-21, rootdelay=1.303, rootdisp=70.961, refid=171.64.7.55, reftime=ce1f0bc0.d5482987 Sat, Aug 1 2009 11:45:20.833, clock=ce1f0f62.afaa1862 Sat, Aug 1 2009 12:00:50.686, peer=63920, tc=10, mintc=3, offset=0.456, frequency=-120.794, sys_jitter=1.109, clk_jitter=1.432, clk_wander=0.073, tai=34, leapsec=20090101, expire=20091228 and a peer listing from our campus stratum-1 server (171.64.7.87, grandfather.stanford.edu): remote refid st t when poll reach delay offset jitter == *TRUETIME(1) .GPS.0 l 46 64 3770.000 -1.435 1.402 +bigben.cac.wash .USNO. 1 u 480 1024 377 21.6249.756 0.045 +clock.isc.org .GPS.1 u 488 1024 3774.7363.071 0.122 and the result of rl 0 from grandfather.stanford.edu: associd=0 status=0444 leap_none, sync_uhf_radio, 4 events, freq_mode, version=ntpd 4.2@1.1585-o Sun May 10 16:52:30 UTC 2009 (1), processor=i686, system=Linux/2.6.18-6-686, leap=00, stratum=1, precision=-20, rootdelay=0.000, rootdispersion=5.384, peer=11864, refid=GPS, reftime=ce1f0d2b.007d3962 Sat, Aug 1 2009 11:51:23.001, poll=10, clock=ce1f0d53.390640e8 Sat, Aug 1 2009 11:52:03.222, state=4, offset=-1.871, frequency=91.237, jitter=1.968, noise=1.791, stability=0.000, tai=0 -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
I found the solution to my large GPS offset. It turns out that I needed to enable PPS signal processing in the GPS driver: fudge 127.127.20.0 flag1 1 I had somehow gotten the misimpression that if I was using the separate PPS driver (server 127.127.22.0), that meant I didn't need or want to deal with PPS in the GPS driver. But no. My ntpq -p output is much saner now: remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.9 l68 3770.000 -0.008 0.002 xPPS(0) .PPS.8 l38 3770.000 -0.008 0.002 +liberation.rich 10.0.229.53 5 u8 16 3772.131 -5.080 3.003 +whodunit.richw. 10.0.229.114 4 u 12 16 3762.325 -4.996 8.129 *iknow.richw.org 171.64.7.89 3 u 14 16 3769.099 -6.797 8.415 I still seem to be several milliseconds different from the Stanford campus time source; this is going to require further investigation. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Seeking help configuring GPS refclock
I recently bought a Garmin GPS 18x LVC and am trying to set it up as a reference clock, but I'm running into some strange results. Specifically, the GPS time seems to be way off, and the PPS is several milliseconds different from what I thought was a pretty accurate local stratum-1 server. I've hooked up the GPS signal lines as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm (I'm pulling the required +5VDC power from a USB port.) I've configured the unit to utter $GPRMC and $GPGGA sentences at 4800 baud, with a 100-msec PPS signal. I'm using ntpd 4.2.5p195 on an 800-MHz Dell box running FreeBSD 7.2 (using a custom kernel with PPS support enabled). This system is really not doing anything else other than running ntpd; top shows it to be 99+% idle, using no swap and almost no RAM. The relevant lines from ntp.conf are as follows. (For the moment, I'm intentionally specifying a high stratum to prevent any host on my LAN from syncing to this experimental system.) The 10.0.229.* hosts are on my LAN; they're all Ubuntu 9.04 (Jaunty) boxes running ntpd 4.2.5p181 and syncing to Stanford University's NTP servers. server 127.127.20.0 minpoll 4 maxpoll 4 version 4 fudge 127.127.20.0 refid GPS stratum 9 server 127.127.22.0 minpoll 4 maxpoll 4 version 4 fudge 127.127.22.0 refid PPS stratum 8 peer 10.0.229.29 minpoll 4 maxpoll 6 key 2 xleave peer 10.0.229.53 minpoll 4 maxpoll 6 key 2 xleave peer 10.0.229.114 minpoll 4 maxpoll 8 key 2 xleave Now . . . here's some output from ntpq -p on my experimental box. remote refid st t when poll reach delay offset jitter == xGPS_NMEA(0) .GPS.9 l5 16 3770.000 -655.20 2.257 xPPS(0) .PPS.8 l3 16 3770.0005.844 0.004 +liberation.rich 10.0.229.53 5 u 15 64 3772.208 -0.652 0.769 +whodunit.richw. 10.0.229.114 4 u 16 64 3772.219 -0.195 0.665 *iknow.richw.org 171.64.7.89 3 u 41 128 3758.1470.756 2.690 I'm confused about two things here. First, why is the GPS refclock's offset so big (-655.20)? And second, why is the PPS offset off by several milliseconds from the Stanford-synced hosts? Does this mean that Stanford's campus NTP infrastructure is misconfigured and measurably off, and I'm right? Or is it possible that I'm somehow set up wrong? In case it might help, here is a bit of sample output from my GPS (from a cu session). If I'm interpreting this right, it looks like I'm seeing 8 satellites and ought to be getting high accuracy. $GPRMC,013257,A,3726.2063,N,12210.8019,W,000.0,000.0,010809,015.0,E*65 $GPGGA,013257,3726.2063,N,12210.8019,W,2,08,0.9,38.1,M,-32.4,M,,*45 $GPRMC,013258,A,3726.2063,N,12210.8019,W,000.0,000.0,010809,015.0,E*6A $GPGGA,013258,3726.2063,N,12210.8019,W,2,08,0.9,38.0,M,-32.4,M,,*4B $GPRMC,013259,A,3726.2063,N,12210.8019,W,000.0,000.0,010809,015.0,E*6B $GPGGA,013259,3726.2063,N,12210.8019,W,2,08,0.9,38.0,M,-32.4,M,,*4A Any thoughts? -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Local (own site) NTP servers.
You might try logging into the FreeBSD computer as root and reading the mail using the 'mail' command. And if you really, REALLY don't want to ever see ANY e-mail from this box -- no matter what it is -- you could edit the mail alias file (/etc/aliases or /etc/mail/aliases, not sure which file name FreeBSD uses nowadays), delete any existing line starting with root:, and add a line saying root: /dev/null, and then do newaliases to create a new hashed version of the alias file. This will cause all e-mail for root to be silently thrown away. It would be a lot better, of course, to redirect that root mail to some other account on a different box, but . . . . To redirect your syslog messages to the console instead of a file, edit the '/etc/syslog' file and point all of the entries to 'dev/console'. It is not a good idea to stop the log outputs by directing things to '/dec/null'. You might want to read some of them. And just for the benefit of those who might not know enough about Unixoid systems to catch the typos, those path names should be /dev/console (with an initial slash) and /dev/null, respectively. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
(I have seen it but have no references to give you. Ie, a group altered ntp to use the computer temperature to predict the rate changes, and found that they got a significant improvement in the clock discipline doing that. Some references for this: http://dx.eng.uiowa.edu/dave/ntptemp.php https://lists.ntp.org/pipermail/hackers/2009-March/004046.html http://www.ijs.si/time/temp-compensation/ -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP - best practice if there is a local stratum 2 server
[Summary: One of my servers ended up synching on a pool server of questionable quality at stratum 1. How to protect against this?] A few days ago, Rob wrote the following in this discussion thread: What you get from the pool may be a stratum-1 server locked to GPS time on a fast unloaded connection, or it may be a slow box on a saturated ADSL line and synchronized to time.windows.com. Your local server will be better to depend on. You at least know what you get, and/or you can ask the department it belongs to what quality you can expect. You can never do that with the pool. Is there any general way to avoid stratum-1 servers from a pool? I recently had a situation where one of my three boxes grabbed onto a stratum-1 server from the US pool, even though this server was about 8 msec off in relation to closer (Stanford campus) stratum-2 servers, and even though my other two boxes (I have my three peering with each other) were marked with prefer in the afflicted box's ntp.conf. tos floor 2 would seem to preclude synching directly to any stratum-1 server, but this could present its own problems if I were ever to want to set up my own local stratum-1 server. What I would prefer would be some way to make a stratum floor apply only to a single pool -- not to the entire configuration (as appears to be the case with tos floor). Or is there a better solution to this overall issue -- short of simply shunning pools entirely, even as a backup strategy? -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] TomTom ONE GPS as refclock?
Is it possible to use a TomTom ONE portable GPS unit as a time reference with ntpd (without breaking the unit, voiding its warranty, etc., etc.)? The unit can connect to a PC via a USB cable, but I have no idea regarding the capabilities or limitations of its software interface. -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Hi, Dave -- Replying to: As you can see, bigben is on the order of 10ms off from the consensus, at least from ntp.davehart.net's perspective on a verizon business-class DSL. I had also considered that the offset could be due to asymmetric routing, but given the same ~10ms offset seen from Stanford, and that bigben's backup sources are .INIT., I'm guessing bigben's clock-winder has left the building. OK, thanks for looking into this. My association with ntp3.isc.org is using interleaved mode, and so should be correcting for asymmetric delays. Interleaved mode is a feature of ntp-dev (soon to be released as 4.2.6), right? I'll be looking forward to being able to use this new goodie -- though, if I read the documentation right, it apparently works only with peer or broadcast associations and won't help me when I talk to servers (but it might be a reason for me to encourage my campus timekeepers to adopt 4.2.6 as soon as it comes out, and have them encourage THEIR peers to do the same). -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Can or should the NTP protocol eventually serve timezone data?
Richard B. Gilbert wrote: I have a couple of radio controlled digital clocks and a wrist watch that do it automagically. The VLF broadcast from WWVB provides the necessary info. Yes, but all the WWVB broadcast says about DST is whether it is in effect or not, or about to start or end, according to the rules currently in effect in the USA. And all your digital clocks know is which of the four continental-US time zones they are in, and whether or not DST is ever observed locally at all. This is wholly inadequate for the worldwide summer time situation. Even if WWVB could be received in other parts of the world, its DST info would be unusable, because it wouldn't be able to take into account the different rules for when DST starts and ends in different parts of the world. In order for me to know if I should follow DST info offered to me by an NTP server, I would need to know where that server is and which locality's DST rules it is following. In my view, it makes far more sense for NTP to keep hands off the whole DST question and confine itself to time-zone-independent issues (such as UTC, leap seconds, and TAI offset). -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Richard B. Gilbert wrote: The Delay values for some of the servers you have configured are large enough to suggest that they are poor choices! Agreed. Please note, though, that I didn't explicitly choose these particular servers -- they came from pools. This does suggest that even servers randomly picked from my own country's pool (*.us.pool.ntp.org) might not be good choices. When 4.2.6 comes out, will the pool command with the preempt option do a better job of weeding out pool servers that are far away, and thus possibly of doubtful reliability? -- Rich Wales / ri...@richw.org / richwa...@gmail.com Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
