Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen terje.mathi...@tmsw.no 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 terje.mathi...@tmsw.no 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 un...@invalid.ca 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 un...@invalid.ca 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 david-tay...@blueyonder.co.uk.invalid 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 david-tay...@blueyonder.co.uk.invalid 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
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
David Taylor david-tay...@blueyonder.co.uk.invalid 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] Another invalid leap second
Chris Adams c...@cmadams.net 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 c...@cmadams.net 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 un...@invalid.ca 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 david-tay...@blueyonder.co.uk.invalid 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] Any chance of getting bugs 2164 and 1577 moving?
David J Taylor david-tay...@blueyonder.co.uk.invalid 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] 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?
Dave Hart daveh...@gmail.com 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?
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?
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?
Danny Mayer ma...@ntp.org 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 h...@ntp.org 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?
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] Detecting bufferbloat via ntp?
Danny Mayer ma...@ntp.org 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] Use ntpd as a daemon so that it continuously disciplines clock, no
David J Taylor david-tay...@blueyonder.co.uk.invalid 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] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
David J Taylor david-tay...@blueyonder.delete-this-bit.and-this-part.co.uk.invalid 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 da...@ex.djwhome.demon.invalid 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 david-tay...@blueyonder.not-this-bit.nor-this.co.uk.invalid 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 david-tay...@blueyonder.not-this-bit.nor-this.co.uk.invalid 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 david.j.hawk...@btinternet.com 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 a...@xyz.com 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 koste...@ntp.org 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 david-tay...@blueyonder.not-this-part.nor-this.co.uk.invalid 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 G). 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 da...@ex.djwhome.demon.co.uk.invalid 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
Unruh unruh-s...@physics.ubc.ca 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
David E. Ross nob...@nowhere.not 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 unruh-s...@physics.ubc.ca 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 use...@umbral.org.uk 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 ?
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_add_sec still being advertised ?
Unruh unruh-s...@physics.ubc.ca 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 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] 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
