Re: [ntp:questions] Slow convergence loopstats (but nice results)
schmidt.r...@gmail.com wrote: My new prototype driver refclock_phc() uses as its clock the PTP Hardware Clock (PHC) found on one of the newer LAN NICs which are PTP (IEEE 1588) aware. This driver is producing phenomenal results (under LINUX 3.12 with linuxPTP): the overlapping Allan deviation computed from loopstats phase offsets alone reaches a stability of 6e-12 in under 2e5 seconds, and the modified Allan deviation reaches 2e-13. This is quite useful, as eventually most all NICs will be PTP-enabled, and can be used as slaves as above, or even GrandMasters (with GPS, for example). Some time ago we at Meinberg have made some tests with hardware time stamping of incoming and outgoing NTP packets on our own NIC, and we saw that in this case the resulting accuracy with pure NTP is the same as with NTP. A major problem was that the standard NTP protocol doesn't support a way to send the captured time stamp of a previously sent packet to its client, as done by the so-called followup message in PTP. I don't know if new standard NIC chips which support PTP timestamping can also timestamp NTP packets, but even if they do then in practice there's still the problem with network switches, etc. There are network switches out there which are PTP-aware and also timestamp incoming and outgoing PTP packets to compensate the introduced packet delay in some way, but there are no switches (AFAIK) which can do this with NTP packets, so even if you used hardware time stamping of NTP packets on NTP end nodes the resulting accuracy would still be worse than with PTP. That's too sad. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
On Thu, Dec 12, 2013 at 09:59:03AM +0100, Martin Burnicki wrote: A major problem was that the standard NTP protocol doesn't support a way to send the captured time stamp of a previously sent packet to its client, as done by the so-called followup message in PTP. ntpd has the peer and broadcast interleave modes to send the followup time stamps. http://www.eecis.udel.edu/~mills/ntp/html/xleave.html Also, there is a feature called launch time, which is supported in some NICs, so the follow up message is not always necessary. I don't know if new standard NIC chips which support PTP timestamping can also timestamp NTP packets, but even if they do then in practice there's still the problem with network switches, etc. Some NICs can time stamp any packets. There are network switches out there which are PTP-aware and also timestamp incoming and outgoing PTP packets to compensate the introduced packet delay in some way, but there are no switches (AFAIK) which can do this with NTP packets, so even if you used hardware time stamping of NTP packets on NTP end nodes the resulting accuracy would still be worse than with PTP. That's too sad. Agreed. I think it's possible to implement a HW NTP support, but there is problem that the switch would have to keep some state about each NTP association. If there was a standardized extension field to store the processing delay in both directions, that wouldn't be necessary. I'm not sure what would have to be done to not break the NTP authentication. A major advantage NTP has over PTP is that it knows the delay for each measurement in the client/server and symmetric modes, which allows it to filter out bad measurements. In PTP the delay is measured independently (similarly to the NTP broadcast mode), so bad measurements can't be easily ignored and it's necessary to have all networking HW with PTP support to account for all processing delays. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
What about NTP's interleave mode (xleave)? H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
Harlan Stenn wrote: What about NTP's interleave mode (xleave)? Please see my reply to Miroslav. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
Miroslav Lichvar wrote: On Thu, Dec 12, 2013 at 09:59:03AM +0100, Martin Burnicki wrote: A major problem was that the standard NTP protocol doesn't support a way to send the captured time stamp of a previously sent packet to its client, as done by the so-called followup message in PTP. ntpd has the peer and broadcast interleave modes to send the followup time stamps. http://www.eecis.udel.edu/~mills/ntp/html/xleave.html Yes, but as you say above this is only supported in peer associations and broadcast mode, so I see no benefit for normal clients. :-( Also, there is a feature called launch time, which is supported in some NICs, so the follow up message is not always necessary. OK, but if I understand correctly then the sending ntpd would have to know that a specific interface supports this, and put the lauch time as transmit time into the NTP packet, and schedule sending of the packet at the predetermined point in time. I see some potential problems here if using this with ntpd. I'm assuming the process or task (launcher?) which has to send the packets at the predetermined launch time is located somewhere down in the lowest levels of the network stack. So the lanuch time determined by ntpd must be far enough after the current time so that the launcher has surely received the packet to be sent *before* the current time reaches the launch time. If the launch time is too near in the future then the launcher might receive a packet from ntpd after the launch time has already passed. If the launch time is too far in the future the launcher has to queue the packet for a long time before it can be sent, and there might be a limited queue size if a large number of packets have to be sent, e.g. to a large number of clients. To avoid this the launcher could be aware of special NTP packets, send each packet when a free slot is available on the wire, and put the current time into each sent packet. If this is not possible, then ntpd would have to keep track ot the packet is has scheduled to be launched at a given time on a given interface. Otherwise It could schedule 2 packets for different clients with the same launch time. And what happens if a different application schedules a different packet on the same interface with the same launch time? This sound pretty error-prone to me. :-( I don't know if new standard NIC chips which support PTP timestamping can also timestamp NTP packets, but even if they do then in practice there's still the problem with network switches, etc. Some NICs can time stamp any packets. OK, that's great. There are network switches out there which are PTP-aware and also timestamp incoming and outgoing PTP packets to compensate the introduced packet delay in some way, but there are no switches (AFAIK) which can do this with NTP packets, so even if you used hardware time stamping of NTP packets on NTP end nodes the resulting accuracy would still be worse than with PTP. That's too sad. Agreed. I think it's possible to implement a HW NTP support, but there is problem that the switch would have to keep some state about each NTP association. If there was a standardized extension field to store the processing delay in both directions, that wouldn't be necessary. I'm not sure what would have to be done to not break the NTP authentication. Yes, I know. Authentication is still another restriction which makes things even more difficult. A major advantage NTP has over PTP is that it knows the delay for each measurement in the client/server and symmetric modes, which allows it to filter out bad measurements. In PTP the delay is measured independently (similarly to the NTP broadcast mode), so bad measurements can't be easily ignored and it's necessary to have all networking HW with PTP support to account for all processing delays. Agreed. I'm very impressed how good NTP can determine and compensate varying network latencies over WAN connections with unknown network nodes on the route. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] GPS Weakness Could Sink Wireless
Interesting Light Reading article on the degree to which infrastructure (in casu wireless networks) is dependent on GPS timing signals, how little is needed to jam GPS (intentionally or otherwise), and what the impact of such jamming would be. It also talks about how PTP might or might not mitigate some of these issues. http://www.lightreading.com/mobile/mobile-security/were-jamming-gps-weakness-could-sink-wireless/d/d-id/706895 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
There are many things that could be done to mitigate the GPS jamming and interference problem. Unfortunately, few if any are being done by anyone outside the military. These include: 1) Better front-end selectivity 2) Better front-end dynamic range 3) Directional antennas for fixed sites such as cell towers -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
On 12/12/13 13:57, John Hasler wrote: 1) Better front-end selectivity 2) Better front-end dynamic range I don't really see how these help against all but the crudest jammers, which transmit pure CW carriers or are off frequency. 3) Directional antennas for fixed sites such as cell towers That might help a bit, if you rejected signals near the horizon (which are good for navigation, but may be bad for time). However, to get full benefit from directionality, you'd need to run large phased arrays and steer their beams to track the individual satellites. As most military users want the navigation data, they would be better off with steerable beams. The military also have the advantage of a broader, L2 signal, with a cryptographic chipping code. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
I wrote: 1) Better front-end selectivity 2) Better front-end dynamic range David Woolley writes: I don't really see how these help against all but the crudest jammers, which transmit pure CW carriers or are off frequency. Better dynamic range means that the jammer must be closer or more powerful. Both it and better selectivity help against out-out-band interference, which is one of the concerns (probably a more serious one than jamming) (and most jammers *are* going to be of the crudest sort). I wrote: 3) Directional antennas for fixed sites such as cell towers David Woolley writes: That might help a bit, if you rejected signals near the horizon (which are good for navigation, but may be bad for time). Signals near the horizon are weak and have gone through a lot of atmosphere. You don't really want them for any purpose if you can find better (and you can unless you are in the [ant]arctic). However, to get full benefit from directionality, you'd need to run large phased arrays and steer their beams to track the individual satellites. As most military users want the navigation data, they would be better off with steerable beams. 99.9% of jammers and 99.99% of interference sources are going to be on the ground. A well-designed fence (shielding, really) with a cutoff at, say, 30 degrees above the horizon can easily knock them down 100db or more. Due to the use of spread-spectrum jamming GPS has no effect as long as it stays within the dynamic range of the receiver (spoofing is a different issue entirely, and *much* more difficult to achieve). My point is that this weakness is more of a design weakness in commercial receivers than a fundamental weakness in GPS. In any case designers of things like cell towers should no more assume that GPS is always just there than they should assume that electric power is always just there. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
In article 87vbyugh88@thumper.dhh.gt.org, John Hasler jhas...@newsguy.com wrote: In any case designers of things like cell towers should no more assume that GPS is always just there than they should assume that electric power is always just there. So long as they're still running IS-2000 CDMA, GPS is at least a formal requirement. But for intermittent interference or signal interruptions, a receiver with a good oscillator will have enough hold-over accuracy to meet the actual protocol requirements. -GAWollman -- Garrett A. Wollman| What intellectual phenomenon can be older, or more oft woll...@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
Jan Ceuleers jan.ceule...@computer.org wrote: Interesting Light Reading article on the degree to which infrastructure (in casu wireless networks) is dependent on GPS timing signals, how little is needed to jam GPS (intentionally or otherwise), and what the impact of such jamming would be. It also talks about how PTP might or might not mitigate some of these issues. http://www.lightreading.com/mobile/mobile-security/were-jamming-gps-weakness-could-sink-wireless/d/d-id/706895 It depends on the structure of the network and the required accuracy. Remember that the usual GPS jamming methods are quite local in nature. You can jam my GPS but that won't take out my DCF77 receiver or the three GPS-synced servers I have configured as internet NTP sources. Nor will it take out my peer server that itself has DCF77 and some other internet time sources, that are again synced to different other servers. Of course it is possible to jam everything, just not very likely. In a mobile network, it should be possible to get time information both from the local GPS receiver and via the glass/microwave link as a backup. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
On 2013-12-12, Rob nom...@example.com wrote: Jan Ceuleers jan.ceule...@computer.org wrote: Interesting Light Reading article on the degree to which infrastructure (in casu wireless networks) is dependent on GPS timing signals, how little is needed to jam GPS (intentionally or otherwise), and what the impact of such jamming would be. It also talks about how PTP might or might not mitigate some of these issues. http://www.lightreading.com/mobile/mobile-security/were-jamming-gps-weakness-could-sink-wireless/d/d-id/706895 It depends on the structure of the network and the required accuracy. Remember that the usual GPS jamming methods are quite local in nature. You can jam my GPS but that won't take out my DCF77 receiver or the three GPS-synced servers I have configured as internet NTP sources. If they are in the same locality (or, depending on the strength of the jamming, local could mean within a few Km) they could also be jammed. Also, transmitting time via a network (whetehr wired or radio) can have a fair amount of jitter so it depends on the accuracy that the wireless towers need. If it is seconds no problem. If it is nanoseconds, you just won't get that. Nor will it take out my peer server that itself has DCF77 and some other internet time sources, that are again synced to different other servers. Of course it is possible to jam everything, just not very likely. The article talks about a truck driving by the airport (ie a few km) jamming the airport. And that was a trucker probably unwilling to spend more than a 100 dollars on his jamming gear. In a mobile network, it should be possible to get time information both from the local GPS receiver and via the glass/microwave link as a backup. But does it have the required accuracy? I do not know. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
unruh writes: The article talks about a truck driving by the airport (ie a few km) jamming the airport. And that was a trucker probably unwilling to spend more than a 100 dollars on his jamming gear. And the jammed receivers probably weren't worth much more than that (though the airport undoubtedly paid a lot more for them). -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS Weakness Could Sink Wireless
unruh un...@invalid.ca wrote: The article talks about a truck driving by the airport (ie a few km) jamming the airport. And that was a trucker probably unwilling to spend more than a 100 dollars on his jamming gear. Is this the incident? http://www.theregister.co.uk/2013/08/12/feds_arrest_rogue_trucker_after_gps_jamming_disrupts_newark_airport/ After Bojczak parked near the ground station for the system, FAA staff noticed jamming in the restricted 1559 to 1610MHz band. rick jones -- It is not a question of half full or empty - the glass has a leak. The real question is Can it be patched? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] NTP to multiple networks via one interface.
Hi, We have a xenserver host. We manage it via an interface on x.x.75.x which is the only network that is actually plumbed in on the host. It has other interfaces but they are virtualised by xen and don't have IP's. We have several VM's on this host on the same x.x.75.x network so we have set the xenserver to broadcast ntp (it syncs from network switches) and the VM's to be broadcast clients . NTP is working ok in this scenario. However we've added a new network to xenserver on x.x.69.x but VM's on this network don't receive the NTP broadcast packets as they don't have an interface on the x.x.75 network. Is there any way to get the NTP packets to all VM's without dual homing either the xenserver or the VM's. Thanks in advance, Scott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] FreeBSD recipe to setup for timekeeping
On 2013-12-11 11:35, unruh wrote: On 2013-12-11, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: On 2013-12-10 15:05, unruh wrote: On 2013-12-10, Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote: Does anybody have a URL for a page that describes how to setup a FreeBSD system for timekeeping? Use either chrony or ntpd. I've got a FreeBSD 9.1 system running on a 1.86 GHz Intel Atom chip. It reports TSC-low is running at 14.584185 MHz and uses it for timekeeping. I googled for a while, but didn't find what I was looking for. I think You have not told us what you are looking for either. it's tangled up with slowing down or stopping the CPU clock to save power. I'm looking for a page that says do XXX to save power or do XXX to get a Do NOT use TSC for timekeeping then. You need a clock (eg I believe hpet for example) that does not slow down. TSC counts cpu cycles. On Linux /proc/cpuinfo for each cpu on the power management: line there are features and outputs showing TSC status: constant_tsc nonstop_tsc tsc_reliable. In understand that dmidecode -t processor can display similar feature info on BSD as well asLinux. On Linux, tsc_reliable is based on whether all processor tscs are synced and each CPUreturns constant deltas for a series of calibration tests, within the limits of accuracy when you are trying to figure out what timer to use for your system. Most processors from the last five years should pass these tests (AMD started adding these features and fixes in 2006, and Intel has followed suit). This may not be the case when power management is enabled, some features of which can vary the processor power and speed behind the system's back e.g., thermal control, as well as lock out interrupts while their needs are satisfied, increasing interrupt latency. So you have to disable all power management features in the BIOS (including spread spectrum CPU speed alteration to reduce RF emissions for FCC rating) and in the OS (e.g. Win7/CP/Power/Advanced/System Cooling Policy/Active to increase fan speed before slowing processor) to get stable timing. better clock, where XXX are probably sysctl settings. kern.timecounter.choice: TSC-low(1000) ACPI-safe(850) i8254(0) HPET(950) dummy(-100) Looks like TSC is good on this system for all purposes. FreeBSD 8.0-RC1 running on a 2.8 GHz Celeron is using HPET. TSC (non low) runs at 2793.170237 MHz. kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-100) I haven't figured out why it things HPET is better than TSC. Looks like TSC calibration tests are a bit worse than ACPI and HPET, but none are perfect. HPET was designed to provide consistent timing interrupts for media playback, not to provide an accurate time counter; setup has to be done carefully to ensure that interrupts will be generated, access can take many cycles (Linux enforces a minimum of 128 cycles), and it appears that there is enough overhead using HPET to noticeably affect system responsivess. ACPI seems to be worse in all aspects, especially on laptops, and ignored on some other series. For a perspective see x86: hpet: Work around hardware stupidity by Thomas Gleixner at: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=54ff7e595d763d894104d421b103a89f7becf47c Because it does not change when the cpu goes into power conservation? TSC nowadays should be completely reliable if properly initialized by either the BIOS or OS, and is designed as a real time performance monitoring facility, when HPET and ACPI are affected by interrupt latencies, so are likely to suffer a lot of jitter. I learned a lot more about TSC and timers than I thought I needed to know on the weekend! Thanks for passing on to us what you learned so that some of us could also increase our knowledge of them. So you would say that there is NO micro timer which is stable under power management? That is too bad. I had thought that hpet was. The timers themselves are stable, but the setup and interrupt latencies are variable, and longer if power management is active: good enough for video work, mostly. The best bet for now appears to be synced invariant TSCs if your system has them, as the jitter is only the few cycles variance produced by out of order execution. The jitter can be reduced by preceding mfence during calibration or performance timing, but that is unnecessary when you want only a timestamp as close as possible to now. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
