Re: [ntp:questions] CVE-2013-5211 and xntpd
On 6 Feb, 2014, at 07:39 , Danny Mayer wrote: > On 2/6/2014 9:26 AM, Brian Utterback wrote: >> I recently received a question from a customer about CVE-201305211, the >> monlist amplification attack. Specifically they asked if the attack >> affected xntpd. They had another vendor that said no, that the attack >> only affects ntpd. This surprised me since as far as I know the monlist >> mechanism is the same in xntpd. I thought the vendor was merely >> incorrect. However, I then read the CERT and NIST versions of the CVE >> and there is no mention of xntpd. Indeed, a literal reading of the CVE >> does indeed imply that xntpd is not vulnerable. >> >> I don't think I am wrong about xntpd being vulnerable. If I am, please >> correct me. But if I am not, we should probably see about getting the >> CVE amended. >> > > If this is about NTP v3 then that version hasn't been supported in > something like 15 years. I believe that it is very likely vulnerable but > noone is going to go into the code to look assuming that they can find > the source for something like that. I believe it was Dennis who wrote > the mode 7 code and tools, so NTP v2 is likely vulnerable as well but > that's not in the CERT either. xntpd claimed to be NTP v3 from its inception, and had both xntpdc and ntpq by the time anyone other than me saw it. It was implemented from a moving-target draft of the NTP version 3 standard that was available as early as 1988 (i.e. before the NTP version 2 RFC was published; that was done late since there was resistance to the postscript format). Fuzzballs also claimed to be version 3 by then too, though there was an existing Unix daemon called "ntpd" implementing NTP v2 only, this being the reason that xntpd got an 'x'. The mode 7 protocol was implemented as a debugging tool during development, the mode 6 protocol was implemented after that got added to the version 3 draft and supported by the fuzzball servers, so you could ask fuzzballs about their peers too. That said, when I stopped work on xntpd there was no "monlist" query since there was no monitor list. If you wanted to know who your clients were it used a much heavier duty (but cheaper to implement) method, a knob telling it to keep peer state for all peers rather than just the configured ones. When I left it, I don't believe there were any queries in either protocol which would result in more than one response packet per query packet, and I had tried to keep responses under 520 bytes of payload (or whatever the number was which guaranteed no fragmentation then) for mode 7 since I lived at the end of a very overloaded Internet connection and it worked better with single packet request/responses. I had less control over mode 6, though. If there's something called xntpd which supports monlist it must have been added after me, but before the name of the program was changed to ntpd. I don't know when that was. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trying to use Dimension 4 time keeper
On 25 Sep, 2013, at 12:04 , John Hasler wrote: > I wrote: >> I'm suggesting adding an open-collector driver rather than adding a >> network of resistors and diodes. Fewer parts and better results. > > unruh writes: >> Probably. I'm a bit worried if the base voltage is higher than the >> collector. > > A single transistor with a base current limiting resistor would work > fine but I had in mind an IC such as the 7407. If you are doing it with an IC a 3.3V buffer with overvoltage tolerant inputs would be better. A 74HC4050 run at 3.3V would probably do it, if you don't need input protection (against >15V or <0V inputs) it needs no additional external components. Dennis Ferguson signature.asc Description: Message signed with OpenPGP using GPGMail ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 19 Dec, 2012, at 13:49 , Brian Utterback wrote: > On 12/19/12 14:05, unruh wrote: >> On 2012-12-19, Hal Murray wrote: >>> >>> Doesn't the PPS signal to the kernel have to go over the same PCI bus? ... > Generally, the PPS signal does not go over the PCI bus. The kernel gets its > PPS signal via the serial port. You would therefore like the controller to > have its own PPS signal input, but I don't see one in the datasheet. The interrupt from the serial port is transmitted across some bus (often by message signalling these days), and it seems to me that a PCIe-attached serial port is probably one of the better situations you could hope for now. The "legacy I/O" peripherals on many Intel/AMD motherboards, including the serial ports, are instead often attached to the processor support chipset via an LPC bus connection and the latter, being designed as an economical replacement for the ISA bus, is just dead slow. Hardware PPS sampling, and synchonising pairs of internal clocks with PIO operations, is much, much better than anything involving interrupts. > So you are back to worrying about the sync of the kernel clock and the > controller clock. It might not matter too much, but it will kind of depend on > how the receive timestamp is obtained from the card. The receive timestamp > and transmit timestamp have got to be on the same time source or you could > run into problems. The size of the problem with multiple time sources is limited by the precision with which one clock can be synchronised with another. With a good arrangement for sampling those clocks against each other this problem can be minuscule compared to NTP's requirements. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 19 Dec, 2012, at 11:05 , unruh wrote: > On 2012-12-19, Hal Murray wrote: >> >> Doesn't the PPS signal to the kernel have to go over the same PCI bus? >> >> I'd guess that you would get better results from a network card. >> That's assuming it has a good clock. All you have to do is read >> a counter. There is no interrupt latency. You can also read it >> several times and pick the best one. > > Pick the best one? How would you know what the best one was? If you can sample both the system clock and the network card clock with a read of the counter you can sample with this instruction sequence (though it may take some work to find the magic instructions which do the operations in the order written): Better, less noisy samples will be associated with smaller values of (A_after - A_before). You can eliminate the source of the largest errors in individual samples if you can disable interrupts on the processor core while doing that. You can also take independent samples as often as you need to, if that improves the filtered result. That is, you aren't limited to one sample per second the way the PPS signal is, if 5 or 20 samples per second improve the accuracy of the filtered result you can just take that many. The biggest problem with this isn't jitter, which can be mitigated by taking and filtering additional samples. It is instead the fact that the minimal value of (A_after - A_before) is probably going to be on the order of 100 ns if clock_B is a PCIe peripheral and it will be difficult to know exactly where in that interval clock_B is sampled, leading to a (constant) ambiguity of +/- 50 ns. When I did an FPGA implementation of this for PCI-X I had the part capture two timestamps instead, one captured speculatively at the very start of the bus cycle, which was returned to the read, and one at the very end of the bus cycle, which was stored so that it could be read later. That reduced the ambiguity to about +/- 7 ns for that card (though even +/- 50 ns is pretty good). This is a very good way to do time transfers between a pair of clocks. What is needed is a system call interface which recognises that systems often have more than one clock, only one of which will be the system clock, and which provides an API to compare these clocks and independently adjust them. > Not sure what you mean by a "good clock". It certainly will not be an > accurate clock. It may be one whose drift rate is not too bad, although > I suspect it will change with temperature. There are two contributors to the ultimate synchronisation quality of a clock, the stability of the frequency source driving it and the speed/accuracy with which you can measure that frequency and adjust for the errors. Dr. Mills's book calls this the "Allan intercept"; lower is better. The frequency source on the network card may be no better than your system clock but the hardware PPS timestamps allow a speedy and precise determination of that frequency which allows you to adjust for changes in that frequency before a big time offset accumulates (it moves the Allan intercept lower and to the left). A clock which can be kept more accurate is a "good clock" whether that accuracy is achieved by a more stable frequency source driving the clock or by more accurate frequency measurements against a good reference. Don't fixate on the quality of the crystal alone, there is more to it than that. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using ntpd with custom clock
On Oct 17, 2012, at 4:30 PM, David Woolley wrote: > Kennedy, Paul wrote: >> Forgive me if I am wrong, but this is a very odd request. As far as I >> can tell, the request is for the NTP corrections to the system clock to >> be used to correct a different clock. >> I cannot quite understand how this is of practical use. It is like >> diagnosing the faults on your car engine and then applying the >> corrections to a train engine. > > The alternative clock has a much more stable oscillator than the motherboard, > would be one good reason. Another reason might be that packet timestamps are being taken from a clock other than the system clock, e.g. from a clock residing in the Ethernet interface hardware which is sampled in hardware to obtain packet arrival and departure times (Ethernet interfaces supporting PTP in hardware often have one like this). In this case the best approach can be to let NTP synchronize the (non-system) hardware clock that the packet timestamps are being taken from, and then to separately discipline the system clock hardware into synchronization with the NTP clock for the benefit of time-consuming applications running on the same machine. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ANN: UK GPS Jamming update
On 28 Mar, 2012, at 08:26 , David J Taylor wrote: >> Just wondering: >> >> 1) Is the UK govt doing this? > > The notice is from a UK Government agency. > >> 2) Is the USA doing anything similar? > > I would be surprised if they were not, but they may have more remote areas to > carry out such tests. White Sands Missile Range, maybe. You can't fly over it, and a friend who lives in New Mexico and owns a plane tells me there is a standing warning for pilots flying around it to avoid relying on GPS for navigation. He has also heard of pilots doing that who have seen their position, as reported by GPS, suddenly shift by 50 miles. >> 3) What's the purpose? > > I understand that it's for the military to see how they would work without > GPS or on the event of GPS jamming. That sounds so unlikely. If they wanted to see what it was like without GPS they could just turn their GPS receivers off. More than this, a lot of your reports have them jamming the GPS L1 frequency alone and I don't think that would deny positioning to modern dual-frequency military GPS receivers. My guess would be that what they are practicing isn't jamming, which seems like it would require little practice, but rather is the much more high tech GPS spoofing, with the jamming being done to cover that up. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 21 Mar, 2012, at 11:36 , unruh wrote: > On 2012-03-21, Ron Frazier (NTP) wrote: >> >> I noticed that Dave Hart later posted this reply to your question. I'll >> reference that below. >> >> NTP's jitter is root mean squares of offsets from the clock filter >> register (last 8 responses, more or less). > > Strange, because ntp then takes that entry of those 8 with the shortest > roundtrip time and uses only it to drive the ntp algorithm. Thus on the > one hand it is using it as a measure of jitter and on the other hand > saying it does not trust most of those values, with a distrust so deep > it throws them away. Why would you be reporting anything for a set of > data you distrust so deeply. I see you keep pointing this out in various ways, but I really don't understand the point. If you are measuring data with non-guassian, non-zero-mean noise superimposed you need to find a statistic which is appropriate for the noise to produce the best noise-free estimate of the quantity you are interested in measuring. If someone takes `n' samples with a (slightly different) non-gaussian noise distribution and finds the median of the `n' (which is an individual sample) to use for further processing would you really call that "throwing away 'n-1' of the samples" rather than just computing the measure of central tendency which is most appropriate for the noise distribution? And if he went back over the data to compute a measure of variability (perhaps computing the median square deviation would be more appropriate) would that really be reporting something "for a set of data you distrust so deeply"? Unless I'm missing something this seems like a rather bizarre point of view. If you are looking for something to complain about in this particular bit of machinery in ntpd I think there are much more interesting aspects you might consider. The best might be that this code causes ntpd to sometimes process offsets which are quite old, in that they were measured at a time well into the past. In theory PLLs and other feedback control mechanisms are unconditionally destabilized if there is any delay in the feedback path. This is why ntpd makes no use of knowledge of when an offset was measured; it is feeding those offsets to a PLL and a PLL has no way to deal with data measured at any time other than "right now". In practice (as opposed to theory) approximating stability while using data which is significantly delayed requires making the time constant of the PLL large enough that the delay in the feedback path can be assumed to be approximately zero in comparison. The time constant of ntpd's PLL, and hence the stately pace at which it responds to errors, is hence directly related to the worst case delays between the measurement and the processing offset data which is caused by this filter. There are so many things to complain about that actually make sense (in reality everything can be justified in terms of tradeoffs, but people can differ about which tradeoffs produce the most attractive result) that I don't see why you keep harping on something which seems more like nonsense. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] site with lots of GPS's and accessories
On 19 Mar, 2012, at 13:58 , Alby VA wrote: > Compared to this history of Atomic Clocks at NIST > and this chart of accuracy, I'd say my NTP Server is > in the 50yrs behind the curve. lol At least its portable. > > History: http://www.nist.gov/pml/div688/grp40/nist-clocks.cfm > Chart: http://upload.wikimedia.org/wikipedia/commons/9/9a/Clock_accurcy.jpg You could do a lot better with hardware designed to timestamp an edge. The timestamp-in-an-interrupt-routine thing is a hack that has never been outgrown. This can be done with a peripheral interface designed for the purpose, though this still leaves one with the problem of transferring the peripheral clock's time to the computer (the latter also seems to be the problem with IEEE 1588). A better way would be for Intel (or someone) to devote a CPU pin to receiving signal transitions, along with the logic to sample in hardware and deliver to software the contents of the TSC at the time of an edge. Then there'd be a market for "timekeeping" motherboards, with that pin wired to an appropriate receiver with an input connector and maybe with a better quality crystal (with a synchronization frequency input?) clocking the CPU complex. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ESR looking for good GPS clocks
On 5 Mar, 2012, at 18:33 , Terje Mathisen wrote:
> Chris Albertson wrote:
>> How to measure? You need to modify the interrupt handler to raise a
>> pin on a (say) parallel port. then measure the time from PPS to that
>> pin going high with a time interval counter. Such counters are cheap
>> now on eBay.
>
> What I'm asking for is GPS unit with such an interval timer embedded on it,
> said counter to be restarted on every PPS signal.
>
> The query protocol then becomes, as seen from the host:
>
> while (1) {
> before = gethirestime();
> gps_time = poll_gps();
> after = gethirestime();
> if (after - before < MAX_LATENCY)
>use_timestamp(after, gps_time);
> sleep(1);
> }
>
> I.e. polling the GPS (at any time) returns the current time in NTP 32:32
> format directly. There is no need to ever interrupt anything with a clock
> source you can poll at any time.
Note that the problem with the above is that you are asking poll_gps()
to complete a transaction which is going to require more than 100 bits
to be exchanged on a full-speed USB interface (I've not seen a GPS chipset
that provides higher speed USB than that) which only delivers
12 bits per microsecond. (after - before) is nearly certain to
exceed 10 microseconds, so you are going to get no where near
sub-microsecond timing unless you have some idea of where in the
(after - before) interval the gps_time timestamp was actually acquired.
More than this, the nature of the transaction is such that the gps_time
timestamp is much more likely to be acquired earlier in the (after - before)
interval rather than later, so using the `after' timestamp as a match probably
maximizes the error. The best arrangement is to have the GPS device
acquire the timestamp just as early in the transaction as it can (ideally
by acquiring a timestamp speculatively when it sees the first bit of
any incoming transaction), use the `before' timestamp for comparison
and forget about 'after'.
The two timestamps will still allow you to do error filtering, you just
need to acquire more samples and compare them to each other. That is,
any additional delays which occur will cause the difference
gps_time - before
to increase, never decrease, so if you take multiple samples the best
of them will be the ones with the relatively smallest (i.e. most negative)
values of that difference. Figuring out which samples are the best is
more complicated if you also need to assume there might be a significant
frequency offset between the GPS clock and the host clock, but even
this can be handled with a least median of squares filter if it can
be assumed that less than half the samples suffered a significant
additional delay. You needn't limit the sample rate to once per second,
either, if more frequent sampling helps.
Dennis Ferguson
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ESR looking for good GPS clocks
device. The only way to get a device like that now is to build it yourself, but it would be nice if GPS chipset manufacturers would provide this for computer synchronization. The PPS output is a poor way to transfer time to a computer. > The problem with USB is the large uncertainty in the time data goes in > to when the interrupt happens. The serial port works well because it > is very simple with no buffering. If you are timing interrupt latency you are incorporating a large uncertainty compared to what you could do with a well-done polling interface. > How to measure? You need to modify the interrupt handler to raise a > pin on a (say) parallel port. then measure the time from PPS to that > pin going high with a time interval counter. Such counters are cheap > now on eBay. Which also has you measuring interrupt latency, not to mention dealing with the difficulty (depending on the computer's clock source) of arranging for an interrupt at the on-time second. If you have an output available, however, you could forget about both the interrupt and the time interval counter if you bought a uBlox GPS timing chipset, since I think these will timestamp transitions on an input pin. When you feel the urge to acquire a timestamp just take a local clock timestamp, toggle the output pin and ask the GPS unit for its timestamp. Absent special purpose I/O, however, having the device timestamp bus transitions isn't a bad way to do it. If the device is carefully done you can certainly get sub-microsecond time sampling with USB. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how do I lock in average frequency correction
On 15 Feb, 2012, at 22:53 , Terje Mathisen wrote: > Dennis Ferguson wrote: >> I have had very good results with the following procedure. If `tc' >> is the 64 bit output of a counter which is continuously incremented >> at the rate of some oscillator then the time can be computed as follows: >> >> t = r * (tc<< s) + c > > This is a reasonable way to get a nice clock... >> >> The value of `s' is selected so that a second's worth of advance of >> tc causes a change to bit 32 of (tc<< s); that is, `s' is a constant >> pre-computed from the nominal frequency of tc's counter and an assumption >> about how far from the actual frequency of the oscillator that might > > The main/only problem with this assumption is that it breaks as soon as your > tick counter (like the one you get from RDTSC) runs at more than 4.2 GHz! > (Maybe you intended to say that the shift was such that the top bit of a > 64-bit value would be set?) No, the requirement is just that s be selected so that in one second (tc << s) advances by more than 0x1ull (which ensures that bit 32 in (tc << s) will change at least once every second). For frequencies higher than 2^32 GHz `s' is 0, for frequencies lower than that but higher than 2^31 GHz it is 1, for frequencies lower than that but higher than 2^30 it is 2, and so on. At very high frequencies (above 8 GHz) `r' begins to lose resolution, one bit for each doubling, but 64 bits is enough that this is of no practical importance. > It also breaks if/when the tick counter rolls over, doesn't it? > > With a full 64-bit counter that happens slightly less often than the NTPD > clock rolls over, as long as the increment rate is less than 2^32 > ticks/second, but if you are limited to (say) 40 bits, which is the > resolution of most of the non-TSC counters in an x86 cpu, you do need a > dependable way to handle rollovers. My implementation distinguishes between a "time count", which is always 64 bits long, and a "tick count", which carries the number of bits (<= 64) which are convenient to sample from the hardware with the instruction set.. "Tick counts" are converted to 64 bit "time counts" by maintaining the high order bits to extend the "tick count" to 64 bits in software (this does require periodic maintenance, but doesn't incorporate interrupt scheduling jitter into the times). Time counts are used for the computation above. Time count (i.e. 64 bit) roll-overs, both of tc and of (tc << s) are handled by the implementation. The implementation assumes in another spot that the system will be rebooted no less frequently than once every 60 years, however, so if tick counters increment at no more than 8 GHz and reset to zero across reboots I expect the code to handle rollovers to never run. I'm not proud of 60 year thing, but I wanted to stick to a 64 bit format for internal time computations until there is compiler support for doing 128 bit integer math; the code gets too ugly if even just basic shifts and adds require function calls. > Finally, all of this does of course require either a single, very stable) > frequency for said counter, or some driver support that will know about any > changes and modify the r and c values at the same time as the frequency > changes. The rate at which the counter is incremented needs to have a fixed relationship to the output of the oscillator from which its timing is derived; there are theoretical arguments I like to make (related to the ntpd PLL, or any feedback controller, being an implementation choice but not a requirement to guarantee the basic stability of clock adjustments) which depend on this somewhat. On x86 machines I prefer the TSC if it works like this (it does on recent processors, and very old ones, but there is a vintage of processors where it doesn't), but pick one of the other counters on machines where it doesn't. >> be. The multiply (r * (tc<< s)), where `r' is a 64 bit value, returns >> the high order 64 bits of the 128 bit product. In my case, `t' (and >> hence 'c') was picked to be the time of day computed in the NTP fixed >> point format, i.e. a 32 bit integer seconds part and a 32 bit fractional >> part, so given a tc from the counter the above converts it directly to >> a time of day. The computation itself takes nanoseconds, or less, on >> a modern processor. > > It does take nanoseconds even on the very fastest (IBM Power7/8?) available > cpus: The 64x64->128 multiplication requires about 7 clock cycles, while the > shift and add will each require at least one cycle. I think it was a Power CPU I computed the 1 ns for, though I could have
Re: [ntp:questions] how do I lock in average frequency correction
On 14 Feb, 2012, at 22:04 , Garrett Wollman wrote: > All of these have issues, starting with the fact that they run at > inconvenient rates. For a clock implementation which works well in the presence of time synchronization software there are (i.e. must be) no inconvenient rates. That is, even when the frequency written on the oscillator's package is a nice round number the actual frequency of the oscillator is going to be different and is unlikely to be "convenient" at all. Yet if you want the clock to keep accurate time you must be able to program the clock to operate at the oscillator's actual rate no matter what that is. > Modern operating systems are moving towards "tickless" operation to > improve power efficiency. This requires an on-board timing device > that has sufficient range and stability to accurately determine the > amount of time that has elapsed between two non-periodic interrupts, > so that the clock can be advanced by the correct amount. I'm having trouble with this because it implies that the system's clock must be advanced in an interrupt service routine which samples a counter. If the system provides a continuously incrementing counter then I think the last thing you want to do with it is to use it in a way which incorporates the jitter and other inaccuracies that come from interrupt processing into the system clock. System clocks maintained by counting interrupts should be reserved for situations where there are is no other means of measuring the advance of time. If you have a continuously incrementing counter you are way better off just deriving the system clock directly from that (which I guess makes the system clock "tickless" as well). There is nothing you can do in an interrupt service routine which helps, in fact trying to do anything there usually just makes the result worse. I have had very good results with the following procedure. If `tc' is the 64 bit output of a counter which is continuously incremented at the rate of some oscillator then the time can be computed as follows: t = r * (tc << s) + c The value of `s' is selected so that a second's worth of advance of tc causes a change to bit 32 of (tc << s); that is, `s' is a constant pre-computed from the nominal frequency of tc's counter and an assumption about how far from the actual frequency of the oscillator that might be. The multiply (r * (tc << s)), where `r' is a 64 bit value, returns the high order 64 bits of the 128 bit product. In my case, `t' (and hence 'c') was picked to be the time of day computed in the NTP fixed point format, i.e. a 32 bit integer seconds part and a 32 bit fractional part, so given a tc from the counter the above converts it directly to a time of day. The computation itself takes nanoseconds, or less, on a modern processor. Clearly the adjustment interface operates to produce values of `r' and `c' that minimize the error in the result. Phase adjustments are implemented by adding an offset to 'c', and hence have a precision of 233 picoseconds. Rate (i.e. frequency) adjustments are implemented by modifying the value of 'r', with a corresponding change to 'c' to ensure phase continuity at the time of the change, and have a precision of better than 10^-19. Slews, a la adjtime(), can be implemented by making a rate change for a fixed interval, at the end of which `r' is returned to its previous value with 'c' precisely offset. The only time `r' and `c' change is when the time synchronization software makes a system call to adjust the clock; there is no need to do anything in an interrupt service routine (the latter assumes that the system call interface is not ntp_adjtime() or adjtimex(); while that code can be supported as well there are good arguments for why you can expect better results, even from ntpd, if you don't include that code in the kernel, though that's a different topic). If your TSC counter is reliable then making the sets of (s, r, c) constants available to user space on a shared page allows user space processes to obtain accurate time without system calls. There are no "inconvenient" clock rates and the clock precision and jitter is the same as the precision and jitter of the underlying hardware counter. If you want a "tickless" kernel the best way to do that might be to start with a "tickless" system clock. If you have a continuously incrementing counter there is nothing that an interrupt service routine needs to do. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Visualization of clock control
On 4 Jan, 2012, at 22:54 , Miroslav Lichvar wrote: > Here are some example runs of the tool captured to animated gifs: > http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_10us.gif > http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_100us.gif > http://mlichvar.fedorapeople.org/clknetsim/chrony_ntp/vis/visclocks_1000us.gif > > The simulations were done with a clock wandering at 1 ppb/s, > 10/100/1000us network jitter with exponential distribution and the NTP > clients were configured to use 64s polling interval. That's pretty neat. I think, however, that the clock wander of 1 ppb/s is about an order of magnitude too large for real life, at least for machines kept in an air conditioned room (and the behavior of clocks in machines subject to environmental variations probably can't be modeled by "wander" at all). My measurements against precise hardware tended towards a value of 1ppb/10s, which is also consistent with the 10^-8/1000s which sometimes shows up on Allan variance plots (I think there's a square root relationship in there if the wander is a truly random walk). The other difficulty with respect to real life may be modeling network jitter as exponential, since I believe the probability distribution for network delays is heavy-tailed (i.e. with extreme values way over-represented; this is a problem when using statistics which assume the underlying error distribution is gaussian). I don't know how to fix that, though. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 29 Dec, 2011, at 23:26 , Terje Mathisen wrote: > Danny Mayer wrote: >> No, they use synchronized Cesium atomic clocks for time accuracy. GPS is >> only used to get a fix on the location and I'm not sure that 10's of >> centimeters is good enough for what they are trying to prove. I'd have >> to look closely at the methods used and the data to even have a clue as >> to what is needed and I have touched that stuff in years. > > Danny, how do you think they keep those atomic clocks synchronized? > > How do they _verify_ that they actually stay in sync (to a single-digit ns > level) over the entire length of the experiment(many months)? > > Even Hydrogen Masers won't give you that performance over a year or so, you > have to have some way to sync them either to each other or to UTC. Yes, they use GPS to compare the clocks to each other. One of the articles I read even identified the GPS receiver they use. I think it was a Septentrio PolaRx3eTR PRO (or maybe the older model which that one replaced). Those receivers take a 10 MHz and 1 PPS reference in from the atomic clock so that they can produce GPS carrier phase measurements with respect to the local clock's time. Making these measurements simultaneously at both locations gives you data you can post-process to determine the time difference between the two clocks, independent of the GPS system time. The GPS signals are used only as markers that can be measured at both locations. BIPM Circular T lists GPSPPP (that's two-frequency, all-in-view carrier phase measurements) as being accurate to 0.3 ns. The bigger error is the equipment calibration, which they estimate as 5 ns. The traveling atomic clock would have been used for the equipment calibration. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
th a 16 second polling interval. Note that I haven't tested this with ntpd yet, mostly because I don't like the way I had to jam support for the NTP system call interface into an otherwise very clean kernel time implementation but haven't yet had the time to try converting ntpd to use the native adjustment interface. I would note, however, that ntpd probably has some additional burden that it bears which makes this harder. In particular, while ntpd operates by essentially making a series of frequency adjustments to the system clock to bring it into synchronization, it also makes the assumption that the frequency adjustments it is asking the kernel to make may not be accurately implemented by the kernel. This is the fundamental reason it implements the control process as a PLL/FLL; it assumes it needs to correct not only the errors the underlying hardware clock is making but also the additional errors caused by unpredictably inaccurate implementation of the adjustments it is telling the kernel to make. This is why, even though it is possible to determine the system clock's frequency error as accurately as it is possible to know it in 10 or 15 minutes (according to the Allan variance typical of the process), ntpd can take hours and hours to work through a large frequency error. When ntpd does get to a point where it has integrated out this correction it should track better (assuming the changes in system clock frequency are small), but I haven't been able to test whether it does as well as a more straight forward procedure that takes advantage of the fact that the operating system makes accurate adjustments. In any case, if you want fine timing I think you need to work on your operating systems first. That is the low hanging fruit. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trimble Resolution T
On 17 Oct, 2011, at 15:14 , Hal Murray wrote: > In article , > unruh writes: > >> In fact it is really hard for a computer to keep to 1us accuracy because >> of the delays in interrupt processing. > > It's not the delay that is the problem. It's simple to correct for a > fixed delay. (at least in theory) The problem is variations in the delay. > > Jitter can easily be caused by cache faults or jitter in finishting the > processing of the current instruction, or having interrupts disabled. > (There are probably other sources.) I actually would have said just the opposite. Jitter is less of a problem because you can see it. That is, if you take a series of samples you can see the variation in delay reflected in the variations of the offsets you compute, and you have some basis for filtering out the samples which are most severely effected (assuming, for example, that those with less delay, and hence a more positive offset, are "better" than those with more delay). Even if you can't eliminate the effect of jitter entirely you at least have the data to develop an expectation of the error residual error it is causing. The problem with a constant delay is that it is invisible. You can't see any sign of it in the data so, while it would be easy to correct this if you knew how big it was, the only way to determine its magnitude is to calibrate it by some entirely independent measurement. In this case it is hard to see how one would do that. To see why that is a bigger problem, note that the 1 us being talked about here must in fact be a measure of jitter, or delay variation, since that is what ntp can see. Assuming the time error must be on the order of 1 us because the jitter is of that order is, however, unjustified because that ignores the effect on your time of the constant delay that ntp can't see, and hence can't even estimate. If the constant latency were in fact on the order of 10 us (that may be unlikely, but without actually determining a number by some means other than ntp there is no way to preclude the possibility) then worrying about the 1 us jitter isn't going to improve the precision of your time much. The fact that you could correct the constant delay by subtracting a constant doesn't help if you have no idea of that constant's value. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] OT: UK - NOTIFICATION OF GPS JAMMING EXERCISES
On 11 Oct, 2011, at 05:59 , John Hasler wrote: >> I presume, to ensure that the military can continue to function (at >> some level) in the absence of usable GPS. > > They coud do that by turning off their receivers. More likely they are > testing anti-jamming techniques (and jamming techniques as well). Yes, they aren't necessarily jamming their own receivers, I suspect they are practicing jamming other people's receivers while keeping their own working. Military GPS receivers (owned by those friendly with the US military owners of GPS, at least) use an additional service (PPS, for "Precise Positioning Service") at a second frequency which is much harder to jam than the GPS L1 band service (the C/A service, originally for "Coarse Acquisition") that the rest of us are limited to. This isn't just a European thing, either. A friend who regularly flies himself from California to New Mexico gets frequent FAA notifications concerning GPS jamming at White Sands Missile Range. And, I guess, what they are practicing might not just be jamming of (i.e. denying service to) GPS receivers. I read somewhere that a decade or so ago a Chinese GPS-guided missile test fired near Taiwan went in a dramatically different direction than was expected, suggesting an ability to not only deny civilian GPS service but also to actively spoof it (something which probably prompted China's current enthusiasm for launching their own satellite navigation system). That would be a far more complicated trick which might, in fact, require considerable practice to get good at. All this might also hint at the reason that many countries have rules prohibiting critical services, like telecommunications infrastructure, from depending on GPS for anything important despite the technical advantages this might otherwise provide. That's too bad. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] POSIX leap seconds versus the current NTP behaviour
just an extra chunk of code operating where the system call interface would be to maintain the fiction. Of course I do want to adjust the system's clock too, I just can't do it the way the NTP code was doing it. What could be done, however, was design a system call interface which allowed time and frequency adjustments (which are done solely with arithmetic as well), but did so in a way which returned enough information about what was done to allow one to precisely compute the time one would have gotten from the unadjusted clock as a function of the adjusted clock's timestamps. This is also just a math problem that can solved quite precisely by taking care when doing the arithmetic. If I can arbitrarily adjust the system's clock without losing track of the unadjusted time, and if I can use the unadjusted time to determine the time ntpd's adjustments would have resulted in had it made them, then I can have my full-precision cake and eat it too (and there are other interesting side effects, like being able to compute the Allan deviation from data collected from a clock which is being simultaneously adjusted since I can always precisely determine what the same measurements would have been if the clock were left unadjusted). So I'm at a point where I can define a policy for adjusting the system clock which is independent of what ntpd would like the clock to do without any effect on ntpd, but which can use ntpd's estimates of the time and frequency errors with respect to the unadjusted clock to inform what it does. The system's time is still determined by ntpd, but can be way more loosely coupled than the current implementation has it. What is the best thing to do for the system time, now that it doesn't necessarily need to serve ntpd, is something I'm still trying to figure out. And as for results transferring time from the card to the system clock, I have found that if it samples the offset 4 times per second and processes that data to determine time and frequency errors (using a least squares fit, after outlier filtering) then, if an adjustment is made only when it computes a time or frequency result which differs from the current clock setting at an 80% confidence level, it will typically end up making an adjustment roughly every 10 seconds or so with the time adjustments tending to be about 10 nanoseconds in size and the frequency adjustments being very roughly on the order of 10^-9. If I haven't made a mistake I think those numbers (10 seconds and 10^-9) should characterize the thing you call the Allan intercept, though I haven't calculated that yet. I think it is possible to claim that this system's clock is typically within 20 ns of the GPS receiver. I'm also thinking that if an adjustment rate of once every 10 seconds is all that is necessary to achieve this precision with this system's clock and this fine a time source, then when you have the same system clock but a much sloppier time reference source (e.g. time samples from the network) the adjustment rate justifiable by the achievable timekeeping accuracy is going to be significantly lower (say once every few hundred seconds, like the Allan intercept with a good NTP source). This is a good result, if it can be implemented this way, since being able to keep the clock as accurate as it can be with a rate of adjustment which is typically quite small has some side benefits with respect to the implementation of kernel timestamping of packets or other events, or of system-call-free user space time stamping. Dennis Ferguson On 5 May 2011, at 04:10 , David L. Mills wrote: > Dennis, > > Holy timewarp! Are you the same Dennis Ferguson that wrote much of the > original xntpd code three decades ago? If so, your original leapseconds code > has changed considerably, as documented in the white paper at > www.eecis.udel.edu/~mills/leap.html. It does not speak POSIX, only UTC. This > applies to both the daemon and the kernel. > > Dave > > Dennis Ferguson wrote: > >> Hello, >> >> A strict reading of the part of the POSIX standard defining "seconds >> since the epoch" would seem to require that when a leap second is added the >> clock should be stepped back at 00:00:01. That is, the second which should >> be replayed is the second whose "seconds since the epoch" representation is >> an even multiple of 86400. Right now the NTP implementation doesn't do that, >> it instead steps the clock back at 00:00:00 and replays the second which is >> one before the even multiple of 86400 in the "seconds since the epoch" >> representation, to match what seems to be required for the NTP timescale. >> >> For a new implementation of this is there any reason not to do the kernel >> timekeeping th
[ntp:questions] POSIX leap seconds versus the current NTP behaviour
Hello, A strict reading of the part of the POSIX standard defining "seconds since the epoch" would seem to require that when a leap second is added the clock should be stepped back at 00:00:01. That is, the second which should be replayed is the second whose "seconds since the epoch" representation is an even multiple of 86400. Right now the NTP implementation doesn't do that, it instead steps the clock back at 00:00:00 and replays the second which is one before the even multiple of 86400 in the "seconds since the epoch" representation, to match what seems to be required for the NTP timescale. For a new implementation of this is there any reason not to do the kernel timekeeping the way POSIX seems to want it? I thought I preferred the NTP handling since it seemed to keep the leap problem on the correct day (for an "all days have 86400 seconds" timescale, which describes both the NTP and the POSIX timescales), but I've since decided that might not be all that important and I appreciate the symmetry of the POSIX approach (leaps forward occur at 23:59:59, leaps back at 00:00:01, and both leaps end up at 00:00:00) as well as the fact that the POSIX approach yields a simple equation to determine the conversion from time-of-day to seconds-since-the-epoch which is always valid, even across a leap (and even if the inverse conversion is ambiguous) while I'm having difficulty finding a similar description of NTP's behaviour. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
