Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen writes: >The derivatives of sine/cosine are of course +/- cosine/sine, so they >stay smooth at all levels. The point is that it is not smooth where it joins on to the regular passage of time... It is possible to do this in an infinitely smooth way, but using the cos formula just gives a few continuous derivatives. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen writes: >One of the good points about Google's smear is the fact that they use a >half cosine to distribute the offset, which means that they have a time >function which is both continuous and monotonic, as well as having an >infinite number of defined derivatives, i.e. it is maximally smooth. Doesn't it only have two smooth deritives at the end points or [-w:w]? The usual function is constant 1 with all derivatves zero, and so this is what the derivative should be at the endpoints. They use (1.0 - cos(pi * t / w)) / 2.0, which is 1 at both end point, has first derative zero, but the second deritive is -pi*pi/w/w. (It should be possible to stitch together something that is infinitely smooth, probably using exp(-1/(x*x)), but it would requite a bit more work.) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh writes: >General relativity assures us that time exists and is measured by a >metric. Take that metric and define a proper time say at the center of >the earth. Now one can ask whether TAI or UTC is a function of that >time. As Mike points out, you've subtracted things in a way that doesn't really make sense to make this argument. Warner Losch has a good way of describing this as "variable radix". For example, we don't describe the calendar as discontinuous, because months have 28, 29, 30 or 31 days. If you "subtract" Feb 27th from Mar 3rd, you need to know if it is a leap leap year, rather than say the answer is 7 days by assume all months have 31 days because most months do. My personal way of viewing the topology of the space labels, is that some second labels have multiple possible successor labels, and the leap seconds look like little loops around which UTC may or may not pass. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh writes: >Note UTC differs from TAI by an interger number of seconds, AND that >integer changes with the leap second. Ie, it cannot be continuous if TAI >is continuous. That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] MSF Anthorn, UK down
David Taylor writes: >It looks like the UK MSF 60 KHz signal from Anthorn is down. I've seen >one report that a clock stopped at 00:04 this morning (but I don't know >whether that was UTC or UTC+01:00). I haven't got a sample from it for about 21h that made it to the NTP server. The last minute that the decoder managed to process was: uninverted A: 00010110110010101000110 uninverted B: 11100101010 uninverted Raw: 25/5/2014 0:04 Sun -300 DST uninverted Ctime: Sun May 25 00:04:01 2014 David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap seconds
David Taylor writes: >Talking of leap seconds, I see not indication here from any of my >servers, or their peers, of a leap-second, which is as it should be. >Checking reminded me that I did write a simple program with which you >can check your own NTP PCs, and it can be downloaded here: I've added a graph showing the fraction of servers advertising leapbits here: http://www.maths.tcd.ie/~dwmalone/time/leaps/ It doesn't look like there's too many confused servers this time. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
David Taylor writes: >Could you not use something like the timestamp of some file (e.g. the >drift file) or other system file to get the approximate year? I haven't >studied the code (I find C not easy to read or navigate) so perhaps it >already does this. Then you would only need to set the real time once? Possibly - this was a handy timestamp to use, but there may be a better choice. It's also possible that this should be an optional flag to the driver, so that people with perfectly good GPS units won't ever trip over the code ;-) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
unruh writes: >Surely if the receiver is delivering the wrong date, it is the receiver >manufacturer that needs to make the changes, not ntp, including sending >you a new receiver if necessary. Warrenty limits notwithstanding, this >fails that "fitness for purpose" test, and you could hardly have >detected it when you bought it. Certainly - though the company I bought mine from is long gone, and I wanted more time to think about replacement options. >Except of course if the rd_timestamp.l_i is way out (that is why one >would want to use a gps clock to fix it-- eg on bootup with the >Raspberry Pi say), Indeed - you need to have a timestamp within about ten years of correct before you start up, otherwise the problem will be worse. Ntp has the same problem in figuring out the ntp epoch, though we've yet to see an ntp timestamp wrap around. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
Terje Mathisen <"terje.mathisen at tmsw.no"> writes: >Nice! >You've replaced the 1024-week epoch with a +/- 512-week window around >the "current" time. :-) Indeed - ntp already sort of has to do a similar, because the timestamps are mod 2^32 seconds from 1900, so using a trick like this is only marginally distasteful ;-) >> I'm trying to adjust the timestamp given by NMEA might be slow by >> some multiple of 1024 weeks, and so tries to adjust it so that it >> is reasonably close to the system time associated with the read of >> the NMEA data. I'm not sure if I've got the code exactly bang-on, >> but it has got ntp running with the unit again. >Looks good. On Harlan's recommendation, I've opened a feature request with the patch. If anyone notices any issues, I can log them there. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Start of new GPS 1024 week epoch
Magnus Danielson writes: >Remember that any Sunday, it is likely that a GPS reciever have slipped >a multiple of 1024 weeks. NTP drivers should be able to recognice it and >compensate for it, as it is a re-occuring bug in many recievers. >This issue have been discussed over and over again at time-nuts. It seems my ancient GPSclock 200 has recently slipped back to December 1993 too. Resetting it hasn't helped and I doubt I will be able to do a firmware update, so I've made a hack to refclock_nmea.c (version ntp-4.2.6p5), by replacing: reftime.l_ui += caltontp(&date); with reftime.l_ui += caltontp(&date); while (reftime.l_i + 512*7*86400 < rd_timestamp.l_i) reftime.l_i += 1024*7*86400; I'm trying to adjust the timestamp given by NMEA might be slow by some multiple of 1024 weeks, and so tries to adjust it so that it is reasonably close to the system time associated with the read of the NMEA data. I'm not sure if I've got the code exactly bang-on, but it has got ntp running with the unit again. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Another invalid leap second
Chris Adams writes: > remote refid st t when poll reach delay offset jitter >== >-216.180.99.1152.2.21.1 3 u 75 128 3778.750 -3.704 2.198 >-216.180.122.1 173.255.232.93 3 u 100 128 377 10.6931.763 2.047 >*198.58.100.237 216.218.254.202 2 u 112 128 377 33.1760.153 2.465 >+199.195.193.200 203.117.180.36 2 u 61 128 377 271.8177.875 22.267 >+66.162.15.6564.236.96.53 2 u 105 128 377 25.8807.921 4.795 >-50.116.38.157 130.207.244.240 2 u 88 128 377 23.243 -2.734 1.810 > 127.127.8.0 .GPS.0 l 392 1600.0001.016 0.000 >x127.127.22.0.GPS.0 l2 16 3770.000 -4.524 0.684 Unfortunately, there isn't much overlap between the servers I'm monitoring and the servers you're using, so I can't add much. From the refids, I have info for machines in UNC, gatech and he.net, and none of them were advertising leap seconds. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Another invalid leap second
Chris Adams writes: >I have a Linux (Fedora 18) system running ntp-4.2.6p5-8.fc18.x86_64. I >have a GPS receiver connected (old Trimble SVeeSix in TSIP mode). I >have some pool servers plus my ISPs servers configured. After some >discussion on a mailing list, I checked, and I got a leap second Sunday. >I see this in my log (my local time is CDT, UTC-0500): I've been monitoring the leap second advertisment on a bunch of NTP servers for the last few years. I've plotted some of the results at: http://www.maths.tcd.ie/~dwmalone/time/leaps/ If you let me know the list of peers/servers you're using, then I could see if any are in the list I'm monitoring, and if they were advertising a leap. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Do I have a lock to my NMEA GPS?
Terje Mathisen <"terje.mathisen at tmsw.no"> writes: >David Woolley wrote: >> Terje Mathisen wrote: >> >>> >>> I don't know exactly how much power it needs, but since it runs easily >>> on USB power, it has to use less than 500 mA @ 5V (2.5W), and probably >>> significantly less. >> >> If you are using Linux, you can use lsusb to find the declared current >> consumption for the device, which should give you an upper bound on the >> power consumption. >FreeBSD, I don't know if that OS has something similar? You can do something like this, I think: usbconfig -d ugen1.4 dump_all_config_desc | grep -i power It gives you a value in hex, something like this: bMaxPower = 0x00fa Which, I think, is the max current in 2mA units. 0x00fa is 250, or 500mA. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leapsecond on FreeBSD or Windows - no showstopper bugs, but ...
My FreeBSD machines did fine, including the on connected to the Sure Electronics board. I think the Sure GPS board repeated the 59th second, from the looks of the NMEA outout, but I need to check that more carefully. I will check and see if I saw any kind of reload later. I took some other measurements at: http://www.maths.tcd.ie/~dwmalone/time/leap2012/ David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Effect of Gigabit Interrupt coalescence on ntp timing
Terje Mathisen <"terje.mathisen at tmsw.no"> writes: I was thinking of sometime similar for the improved timestamping. >They will hardware timestamp both transmit and receive for all timing >packets, enabling sub-us level transit time measurements. FWIW, I think the Intel NICs in question support some 1588 features, but I don't think you can get a timestamp for every packet. Or, when I looked at the code/docs, I couldn't figure out how to do it. If someone knows otherwise, I'd like to be corrected ;-) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Effect of Gigabit Interrupt coalescence on ntp timing
unruh writes: >I have posted a web page >www.theory.physics.ubc.ca/scatter/rt.html Should the "rx-users" setting be "rx-usecs"? It would be nice if some of these cards actually timestamped the frames when received and then the timestamp provided by SO_TIMESTAMP or similar could be corrected. It seems only a few cards can do this though. (On FreeBSD these interrupt mitigation techniques should be tweakable using the sysctls under the dev.em sysctl tree.) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
"David J Taylor" writes: >Thanks, David. Those don't seem to be in ntpq.c (at least 4.2.7p134), so >no wonder I couldn't find them. Ah - I'm looking at a slightly older verion (4.2.4p8), but I'd guess there is similar code lurking. >But if the control messages are limited >to microseconds, this problem is deeper than I first thought. I suppose >that's saving on bandwidth by a few bytes? I think the sending code might be in ntp_control.c - there seem to be a bunch of variables that are sent with a fixed precision (search for 1e3 or 1e6). My guess is that because a bunch of variables are often packed into a UDP packet, a decision to keep them a modest size was probably taken. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
"David J Taylor" writes: >2164 needs discussion, unless altering the number of significant digits in >the ntpq output wouldn't break anything. Do we need to have this >discussion? I have looked through ntpq.c, but I can't see where the >number of decimal digits in the output for offset is set. It seems that the types of different variables are stored in a table, and "offset" has type FL. Latter on, there is a block of code like this: case FL: output(fp, name, lfptoms(&lfp, 3)); break; case FU: output(fp, name, ulfptoms(&lfp, 3)); break; case FS: output(fp, name, lfptoms(&lfp, 3)); break; Here, the lfptoms()/ulfptoms() functions convert NTP's internal fixed point format into a string. I think that the 3 is the number of significant figures. You can change these, but it seems that the control messages are such that they only have 3 significant figures included in them. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
r...@panix.com (Rod Dorman) writes: >I dont see anything to support the claim that "UDP is treated as >guaranteed by WiFi" It says unicast frames are retransmitted - that's as close as you'll get. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
r...@panix.com (Rod Dorman) writes: >Isn't 802.11 a physical layer specification? Why would it be defining >transport layer behaviour? No - it's a MAC and PHY layer. It doesn't care about TCP or UDP, only MAC layer things like unicast and multicast, and the required management/control glue to make it all work. Have a look at section 6.1.1.3, which notes that most unicast traffic is ACKed, but broadcast and multicast is not. Section 9 describes a good bit of the MAC, and 9.2.8 the ACKing procedure. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
r...@panix.com (Rod Dorman) writes: >I did a quick scan of 802.11-2007.pdf and didn't see any requirement >that UDP is treated as guaranteed by WiFi. >Could you give a page number or section reference? Look for the handling of unicast traffic. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
Dave Hart writes: >I recognize I'm suggesting a layer violation in wishing 802.11 devices >treated UDP differently from TCP, or even worse in terms of layer >violation, UDP 123 differently from UDP 53. It's not pretty, but it >would make a positive difference. The ideal number of retries for NTP >may be zero, assuming the radio layer loss rates are less than 87.5% >in practice. All QoS choices that are made at a low layer involve some amount of layering violation, so I don't actually find this objectionable. If the PHY rate selection algorithm is any good, then the loss rate will be less that 87% unless the network is really clogged up with a lot of busy stations and there are a lot of collisions. >> An alternative would >> be to use NTP's broadcast mode on a LAN, which would eliminate >> retries. >Right. There is one other cool thing you can do with timing and 802.11 broadcasts. Broadcasts really are broadcasts - you're not seeing copies of a packet as you would on a switch. If you can timestamp the arrival of a broadcast, it should provide you with a common reference point in time between a bunch of devices. It can be a fun way to watch the drift on the clocks on a bunch of devices. (The 802.11 cards often have relatively good time counters on them too, for backoff and "TSF" calculations. I've a version of the Atheros driver for FreeBSD that can work as the system timecounter. I've still to check how it compares to other hardware.) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
Danny Mayer writes:
>No you don't want to do DNS over TCP if you can avoid it. It would be a
>major hit on the resolver servers and with the kind of high volume that
>you get as mobile devices make increasing use of such networks. You want
>WiFi to drop UDP packets if they are lost rather than attempting to
>retransmit them.
\begin{ramble}
All unicast MAC layer traffic is retransmitted on WiFi if not
recieved correctly, probably for the same reason that Ethernet also
retransmits packets that collide. If NTP can handle 10base2 Ethernet,
then it should be able to handle WiFi.
The maximum number of retries depends somewhat on the hardware
(usually between 7 and 11 tries), and is subject to backoff, in a
similar way to traditional Ethernet. Determining if a packet was
successful depends on on a MAC-layer ACK, because you can't easily
do collision detection in the same way as Ethernet. The reason that
only unicast packets are retransmitted is because it's tricky to
figure out who sends the ACK if it is multicast or broadcast. I
suspect that if the 802.11 guys could figure it out, multi-/broadcast
traffic would also be retransmitted as needed.
Modern hardware that supports 802.11e (or 802.11n, which requires
much of the QoS part of 11e) can control things like the number of
retries, and you could hack the driver to inspect the packets and
if it is NTP to reduce the number of retires. An alternative would
be to use NTP's broadcast mode on a LAN, which would eliminate
retries. However, I suspect that bufferbloat and asymetric delays
on DSL is probably a much bigger problem for NTP than 802.11 retries.
\end{ramble}
David.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Configure FreeBSD or Linux to use stepping clock?
Dave Hart writes: >I did a bit of searching but of course this is an odd request: "help >me degrade the precision of my system clock, please" hasn't come up >much. If you have any suggestions, please speak up here, or privately >if you prefer. On FreeBSD you could try selecting the "dummy" timecounter. I think this will produce a counter that steps in a rather clunky way. Something like: sysctl kern.timecounter.hardware=dummy should probably work. (Running "sysctl kern.timecounter" will output various information about the available timecounters.) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
Danny Mayer writes: >> For traditional TCP (single flow), you need bandwidth*latency as >> sockbuf at both ends plus the same at the bottleneck router. Some >> of the new TCP congestion control systems can do with less, and >> still fill the link if they are the only flow. >Since NTP only uses UDP the packet handling will be different. I'm not >sure why you are talking about TCP here. Oh - I though we'd drited onto the topic of how much buffering was sensible in a network. The bandwidth*latency rule of thumb, which Terje mentioned, is basically derived from the amount of buffering required for a TCP flow to fill a link. I agree this has nothing to do with ntp, except that NTP packets will often share a buffer with TCP packets. >It would be more useful to discuss what happens with UDP flows since >that is what NTP uses. For ntp, I suspect the required amount of buffering is (number of peers)*(largest number of packets sent in burst modes), and probably less in practice? David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Detecting bufferbloat via ntp?
Terje Mathisen <"terje.mathisen at tmsw.no"> writes: >The end points needs at least bandwidth*latency buffers simply to keep >the flow going, while routers in between should have very little buffer >space, simply because that will allow the end points to discover the >real channel capacity much sooner. For traditional TCP (single flow), you need bandwidth*latency as sockbuf at both ends plus the same at the bottleneck router. Some of the new TCP congestion control systems can do with less, and still fill the link if they are the only flow. >You might claim that a little intermediate buffer space is a good thing, >in that it can allow a short-term burst of packets to get through >without having to discard other useful stuff, but only as long as most >links have spare capacity most of the time. There was some work a few years ago that suggested that you needed about bandwidth*latency/sqrt(n) buffering at a link with n bottlenecked TCP flows, in order to make sure that the flows could actually use the link. There was also a suggestion that you could get away with less, but that neemed to require a quite large n in practice. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Use ntpd as a daemon so that it continuously disciplines clock, no
"David J Taylor" writes: >Have you ever measured the resources used by ntpd on a modern CPU? >Absolutely negligible - at least when serving a dozen clients and serving >as a stratum-1 PPS clock. Perhaps a little more with thousands of >clients, of course. Not running ntpd continuously will ruin its accuracy. Checking our server here with, probaly over 1000 clients, which also monitors a GPS refclock, ntpd seems to have used about 0.1% CPU over the last month on an oldish P4 box. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] MSF outages
David Lord writes: >Anyone else having problems receiving MSF? >Today the modulation level appears to less than 50% >rather than on-off modulation. Looks like I have been getting new samples all day: http://www.dwmalone.net/mrtg/ntp/rugby-offset.html I just plotted a spectrogram, and the signal strength looks OK here in Dublin: http://www.maths.tcd.ie/~dwmalone/rugbytest.png (Scroll down to 60kHz). David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
"David J Taylor" writes: >Thanks for that. Interesting, as it seems that you /may/ be able to get >access to a serial I/O (needed for the GPS) according to the diagram here: > http://www.marvell.com/platforms/Marvell_PlugComputer_DevKit.pdf >I wonder whether anyone has ported NTP to this platform, and what accuracy >they have seen? I believe FreeBSD has been ported to that platform: http://wiki.freebsd.org/FreeBSD/arm Though I'm not sure of the exact status of the port. Warner would probably know. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP absolute accuracy?
David Woolley writes: >David Malone wrote: >> The Rugby unit was built by Ian Dowse, and is described here: >> >> http://www.maths.tcd.ie/~dwmalone/time/rugby.html >> >This is a simple AM detector for the slow code (I don't know if the fast >code is still transmitted). It doesn't phase lock onto the carrier. Yep - It just delivers the pulses to DCD on a serial port. The driver uses the PPS API and averages the second marks over the minute before delivering the dates to NTP via the SHM driver. I do have some software radio stuff that looks at various long wave signals. Where I am, we can hear MSF, DCF, BBC 4 and TDF, all of which carry time signals. I have some plots of the phase here: http://www.maths.tcd.ie/~dwmalone/phase.png You can clearly see the phase-modulated timecodes on top of BBC 4 and TDF. Josh Tobin did some work with me to write software decoders for these over the summer, and had the TDF signal working as an NTP refclock. We haven't cleaned the code up yet, but hope to soon. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP absolute accuracy?
"David J Taylor" writes: >Thanks, David, David and Jan. A few milliseconds is what I had expected, >so if you are on a consumer line, what implications does that have for >unruh's comment? I've been plotting the offset reported by "ntpq -p" for my Rugby receiver and a GPS-based server over DSL at: http://www.dwmalone.net/mrtg/ntp/ (Appologies if you're using IPv6, the link to the machine is a bit wonkey right now.) I take a sample every 64s from the Rugby peer, and "lanczos" is the other peer uses ntp's standard polling. The Rugby unit was built by Ian Dowse, and is described here: http://www.maths.tcd.ie/~dwmalone/time/rugby.html It was calibrated to be within about 1ms of the GPS unit when they were connected to machines on the same LAN. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP absolute accuracy?
"David J Taylor" writes: >"Unruh" <> wrote in message news:34jgm.50898$ph1.36...@edtnps82... >[] >> Note that chrony will give you a factor of 2 or three improvement over >> ntp in the errors, assuming that the roundtrip is equally split on >> Linux or BSD. >For those without wide-bandwidth academic connections - those folks on >cable or ADSL - how good is an "equal split round trip" assumption? I have a machine with Rugby reciever that also syncs (over DSL) to a machine with a GPS unit. Based on that, it looks like the asymetry is small (not more than a handful of ms, on a path of 32ms). David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
"David Hawkins" writes: >They are running Sues Linux from a read only flash drive, all identical >clones other than host names and IP addresses. Aren't there stories of recent Linux kernels miscalibrating the kernel timer against the hardware? I guess you could check the dmesg at boot to see what frequency it thinks the timers are running at. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
"nemo_outis" writes: >I beg to differ. There are a number of programs (truecrypt, ntp, pgp, >etc.) which, despite claiming (to varying degrees) to be open-source, >are neither fish nor fowl. Ntp, for instance, limits use of the name >for publicity/advertising in commercially derived works. The NTP lisence has been approved by OSL as an open source lisence: http://www.opensource.org/licenses/alphabetical I think most people consider OSL to be the arbitor of what is open source and what is not. As you point out, IP is thorny, which is why OSL approves lisences, saving us the trouble. >As for something being open-source "without the source," that is a >laughably self-contradictory proposition. I was just pointing out that a piece of software being copyrighted or public domain does not determine if it is open source or not, which is how I read your original comment. >PS However, we are being drawn rather far afield from the original "500 >ppm" question. Indeed - to push us back on track a little, here's a graph of the drift values from a few hundred machines: http://www.maths.tcd.ie/~dwmalone/time/drifts.png There's almost 600 machines in that list, but it included machines from two big clusters, so there is a certain uniformity of hardware. Most machines are Linux, but there are also some versions of FreeBSD. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
"nemo_outis" writes: >First, it seems somewhere between naive and disingenuous to pretend that >ntp, despite being (quasi-)open source (It *IS* copyrighted!), does not >have a significant "political overhead" from a dominant figure that has, >for instance, inhibited such aspects as updating the RFC. [This is a bit off topic, but...] Open source can be copyrighted or public domain. Public domain software could also be non-open source, if (say) binaries were put in the public domain without the source. Wikipedia has a long article with the details... David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] What to do about broken IPv6 sites
Steve Kostecke writes: >>> Since RFC-compliant behavior is to try the IPv6 address first, I >>> have to timeout on every page element before switching to IPv4. >I have an IPv6 tunnel through Hurricane Electric and have _no_ problems >with IPv6 to *.ntp.org FWIW, I saw www.ntp.org not responding over IPv6 about a week ago and (apparently) had no problems with other IPv6 sites. I was going to report the problem, but it seemed to have fixed itself by the time I got back to it. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] How bad is USB?
"David J Taylor" writes: >I know it's off-topic, but how far apart in time does two singers, or >choir, have to be before you notice? (No, I'm not suggesting a spoken ref >clock ). If you have an small orcestra between a conductor and choir, the choir can be a good bit behind the conductor unless they watch rather than listen. This is probably only a matter < 10m (though I suspect the effect is not just due to the speed of sound, but also due to the compounding of people's reaction times). David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
David Woolley writes: >Uwe Klein wrote: >> The hardware does automatic resend on collision using an >> exponential+random backoff algorithm. >Properly functioning ethernet has minimum packet lengths that guarantee >that it one receiver sees a collision, all of them see the collision. >Therefore collisions should never result in duplicate packets at the >application layer. (Though this is possible, but rare, on 802.11 if the packet transmission is successful, but the MAC layer ACK is corrupted.) David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] False Reports of Leap-Seconds
"David E. Ross" writes: >Per my earlier reply, they should be set only during the same day that >ends with a leap-second. Note that while some of the current RFCs say "current day" the draft of the NTPv4 spec at: http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-11.txt says "end of the current month". I guess this is to bring the spec inline with existing practice. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] False Reports of Leap-Seconds
Unruh writes: >No I meant one in a thousand would read this post of yours and repent and >change their ways. Ah - sorry - I misunderstood! >Why not publish a list of the errant servers and shame them into good behaviour I suspect that the stratum 2 and pool servers that are still advertising leaps are doing so because they have learned about it from an upstream server that is advertising it, so there's not much point in nagging about it. From the stratum 1 list, I've only seen ntp2.remco.org and ubitaneous.cpsc.ucalgary.ca advertise leap bits in the last couple of days. I guess that when the newer version of ntpd that takes a vote on the forthcomming leap second is more widely deployed, then the number of stratum 2 and pool servers advertiting leaps will be more tame. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] False Reports of Leap-Seconds
Unruh writes: >>Since I have not (and will not) test all NTP servers, operators reading >>this newsgroup should check their own servers to ensure they are not >>reporting false leap-seconds. >Well, maybe you will catch 1 in a thousand of them. I'm still monitoring a slice of them and updating the graphs at: http://www.maths.tcd.ie/~dwmalone/time/leap2008.html#ntpleapflag The number of stratum 1 servers advertising the leap is almost zero now. The number of pool and stratum 2 servers is still somewhat higher, David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] leap_add_sec still being advertised ?
Ronan Flood writes: >Current ntp-stable has this comment in ntp_proto.c > * combining algorithm. Consider each peer in turn and OR the > * leap bits on the assumption that, if some of them honk > * nonzero bits, they must know what they are doing. >This has been changed in ntp-dev into a weighted vote. Yep - that's what I had in mind, combined with the possibility of some people having a copy of the leapseconds file installed manually or via autokey. Once most people are using the majority vote version, I suspect that the number of people advertising the leap will go down more quickly. (The effective graph of who believes whose leap bits will also be important - if it is ending up with cycles then the leap bits could hang around for ever, even with the majority vote rule.) David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] leap_add_sec still being advertised ?
Unruh writes: >Well, the leap standard actually says that a leap second is possible at the >end of any month, with June/dec being prefered, AprSep being next on the >list and the rest being down there. Indeed - though that's not likely in the near future. >Now, ntp has code to say that only June or Dec are accepted, but that is >contrary to the standard. So, none of them should say that there is leap >second coming. Exactly - I think this lingering-leapbits thing is a problem that probably needs to be looked at, but it unlikely to cause many problems in the near future. The rules for passing on leap bits have gradually changed, and I guess what we are seeing is a mix of different sets of rules being applied in different places. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] leap_add_sec still being advertised ?
"Q" <@..> writes: >Is it me or are a *lot* of servers still advertising the leap from December >? 2 examples from one of my boxes, but most of the ones in the list are >showing leap_add_sec. I've been graphing this since late November: http://www.maths.tcd.ie/~dwmalone/time/leap2008.html#ntpleapflag the number of servers advertising the leap is gradually comming down. I believe it shouldn't matter too much as long as it gets to zero in the next couple of months. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Leap Second
morsupil <[EMAIL PROTECTED]> writes: >It seems that since the LI flag is set on some servers, some NTP >clients problems. >Here is a problem reported by a nagios server on some ntp servers: >/usr/local/nagios/libexec/check_ntp -H xxx.xxx.xxx.xxx >NTP CRITICAL: Offset unknown The first link I see when I search for check_ntp says it is depricated. Could it be a bug in check_ntp? Are the servers running an unusual ntp daemon? >I also see since 3 day problems on some Set Top Box that doesn't >understand the answer from an ntpd server causing those STB hanging at >boot... The workaround solution for the moment is to shutdown >synchronisation with Public NTP server pool... too bad... You probably need to complain to the STB vendor... Who makes them? Any idea who did the NTP implementation? David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
Unruh <[EMAIL PROTECTED]> writes: >weekends. Lots of power at 10^-5 Hz and harmonics, and .7 10^-8Hz.-- more >than would be predicted by 1/f 10^-5Hz is about once per day. I'm not sure what .7 10^8Hz is - it seems to be about once every 4.5 years? I would have assumed you'd get power around 10^-5Hz (daily), 10^-6 Hz (weekly) and maybe 3x10^-8 (yearly) based on a mix of enviromental factors (air conditioning/heating) and usage? David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Bizzare half second disagreement between ntp hosts
Unruh <[EMAIL PROTECTED]> writes: >>not, suppose you have an assymetric roundtrip to tick.usask.ca, due to a >>long downloading being done at your site. If the downloading is at your >>site, you'll have the same assymetric roundtrip to all the remote >>servers configured in your ntpd (and the same conditions apply for the >>three servers you post). >Except there was no large download, and this situation seems to have >continued for about 30 min. I think that the "delay" field would also need to be large (at least half a second, if you saw an offset of half a second) to accomodate this, and that wasn't the case (if I remember right). David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Leap second bug?
"David L. Mills" <[EMAIL PROTECTED]> writes: >The intended behavior if the servers do correctly signal a leap and the >kernel is unaware of that, is that the step interval will be exceeded >for about 15 minutes and then the time will be stepped. During that >interval your clock will appear one second slow relative to the server >that has correctly inserted a second. There will be no slew, onlly the >step. The fact that your time showed otherwise suggests either the step >has been disabled or something else comes unstuck. Our clocks here >showed no such behavior as yours. During the 2005 leap second, I did see some of our peers show an offset of 0.5 seconds for reasons that I don't understand. For example, see the last graph on this page: http://www.maths.tcd.ie/~dwmalone/time/leap2005_peers.html It wasn't the only example - several other peers showed an offset of near 0.5 seconds after the leap - you can find those through the "more graphs of other peers" link at the bottom of the page. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
