Re: [time-nuts] TICC resolution...
Tom, Thanks for your comments - the plot was really a quick example only. Yes, I am aware of the TDC7200 method of operation, all I meant to say was that the 55 ps clusters can be clearly seen, and I was expecting the jitter to blur the lines somewhat more. It was a combination of a histogram with a low number of bins, few samples, and judging by the phase plot I am also suspecting quantisation of the 1PPS output. The source is quite stable, although it is being actively GPS+GLN disciplined. While the 10 MHz and the 1PPS come from the same unit, they do not come directly from the PRS10, they hit some CMOS->LVDS->distribution->CMOS and some 74xxx, across different paths, so all that takes a toll. I have some less complex systems available where this should be cleaner. Anyhow, the TICC is proving an invaluable tool for field testing, calibration, and even cable delay measurement.. ...One reaches a whole new level of anal retentiveness once in the sub-100 ps range. Thanks, Wojciech On 4 April 2017 at 23:03, Tom Van Baak wrote: > Hi Wojciech, > > Thanks for sharing your TICC plot. Yes, the periodic peaks show the ~55 ps > quantization, which is the limiting factor of the TICC's single-shot > resolution. The TICC is based on the TDC7200 Time-to-Digital Converter > (TDC) chip, which uses a digital ring oscillator, which a mobius strip-like > closed loop of an odd number of gates. So this quantization is expected and > readily measurable with any pair of stable sources. > > But I'm not sure why your plot is so ragged. Either you have too few > samples, or one of your sources is unstable, or maybe the 1PPS is itself > quantized, or perhaps some low order digits from the TICC are truncated > before you made your plot. > > If you use cleaner sources and longer runs you can get textbook-pretty > results. > > The attached plot is the result of a 30 hour run on a TICC (beta, Nov > 2016): > http://leapsecond.com/pages/ticc/ticc-log5342-hist-1.gif > > Also attached is what happens if you zoom in a bit: > http://leapsecond.com/pages/ticc/ticc-log5342-hist-3.gif > > In that second plot both the 1 ps granularity of the TICC ascii output and > the ~55 ps quantization of the TDC7200 chip are visible. > > A TICC tends to have slightly better resolution than a hp 53132A but the > "character" of their resolution is quite different: the TICC has strong > quantization peaks and the 53132 is more Gaussian; the TICC outputs with 1 > ps resolution (overly optimistic) and the hp rounds to 0.1 ns (probably > conservative). If you try to push the envelope with better-than-spec > performance out of a TICC or try to automate channel-channel-reference > calibration, these details start to matter. > > /tvb > > > - Original Message - > From: "Wojciech Owczarek" > To: "Discussion of precise time and frequency measurement" < > time-nuts@febo.com> > Sent: Tuesday, April 04, 2017 9:20 AM > Subject: [time-nuts] TICC resolution... > > > > ___ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > > and follow the instructions there. > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > and follow the instructions there. > -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] TICC resolution...
___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Optical Cesium or maybe Cesium "light"!
I tried lifting it but it wouldn't fit in my bag :( ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] A (slightly) different apu2 question
On 18 November 2016 at 09:21, Martin Burnicki wrote: > > Just a few thoughts regarding NTP vs. PTP: > Oh dear... OK, before this snowballs into a bigger discussion this was not meant to be: My original post was _not_ about PTP vs. NTP, it was about the APU2 boards and hardware timestamping. My only point was to highlight the following: 1 This board has got exposed test pads for lots of 1PPS / frequency in / out pins tied to timestamping hardware making it very easy to tap into them. This is a great opportunity which begs to be exploited. 2. With a stable 1PPS from GPS or another source, this board can serve nanosecond time, and that includes NTP in hardware, because the Intel NICs can timestamp every packet, not just PTP. And yes, this mostly matters for LAN. I am fully aware of what you listed. NTP is just a different beast and silicon vendors jumped onto PTP, and PTP inherently lacks the sophisticated quorum and trust mechanisms NTP has, and yes, those are key items on the P1588 WG agenda. Thanks, Wojciech -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] A (slightly) different apu2 question
> > > NTP does not require softstamps. NTP can be (and I believe it has been in > a product) modified to use "PTP" hardware (hardstamps) and reasonably > current releases can run with "drivestamps" (sampled in the NIC driver) > between cooperating endpoints. Of course it does not *require* software timestamps, I never said that, it is just the fact that most people use it with software timestamps, even if the NIC permits hardware timestamps. You need a secondary servo to sync the NIC to O/S clock if you want to serve that (or consume that) - or sync the NIC to external 1PPS. What you call a "drivestamp", I call a software timestamp. If it's not a function of the silicon, it's software. All I meant was that there is some unexploited potential. -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] A (slightly) different apu2 question
...do excuse the slightly off-topic 5(insert your preferred sub-currency here). I think many people put a significant effort into getting a precise pulse into a board like the APU2, losing a lot of precision and accuracy by getting it into the O/S software clock, and then perfectly waste what's left by then retransmitting it via NTP with software timestamping. I am not saying that there is anything wrong with NTP, just that software packet transmission and receipt timestamps ruin both precision and accuracy. The APU2 is a real gem for many reasons, but one is of significance for time sync. The board uses discrete i210 PHY/MAC chips which support hardware timestamping (of all packets, not just PTP) - rather than using an in-SOC Intel MAC paired with a different PHY like Marvell or, diety forbid, Realtek. When designing the board, Pascal did the time nuts a huge favour by presenting pins 60-63 of each i210 as test pads on the board, four per chip. These pins are software-defined I/O pins which can be used for 1PPS output, arbitrary square wave output, and input event timestamping - all tied to the i210 hardware clocks. I have exchanged a few e-mails with Pascal and he hinted that he will consider breaking those i210 pads either as a pin header or possibly as u.FL connectors - maybe not all, but say two per NIC. The only thing that could make this board better (but then it would be a different board) is if it used the latest generation of Intel Atom, where they implemented counter correlation between the CPU and NICs, allowing for very tight O/S clock to NIC clock sync. But that Atom was only recently announced (Skylake CPUs do this already), and an AMD CPU was selected for the APU2 for specific reasons. Another small board with similar potential is the upcoming Minnowboard Turbot Dual-E ( http://www.adiengineering.com/products/minnowboard-turbot-duale/): Atom-based, small, with two i211 right on the board. Cheers, Wojciech On 17 November 2016 at 13:04, Attila Kinali wrote: > On Wed, 16 Nov 2016 15:24:06 -0800 > Jay Grizzard wrote: > > > On the apu2, this crystal is easily accessible (at least as easy as > > anything SMD is). Can anyone think of a reason that it wouldn't be > > feasible to replace this crystal with an external reference, à la the > > widely known clockblock + Soekris net4501 hack (but with 64x the RAM)? I > > figure the higher frequency might make it a bit trickier to get the > > signal to the board intact, but is there any other good reason this > > wouldn't work? > > You should check with Pascal Dornier (the guy behind pc-engines). > He can exactly tell you what would work and what wouldn't. > And he is generally very very helpful. > > Attila Kinali > -- > It is upon moral qualities that a society is ultimately founded. All > the prosperity and technological sophistication in the world is of no > use without that foundation. > -- Miss Matheson, The Diamond Age, Neil Stephenson > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Every year... always makes me wonder, do these vendors even test this themselves? I know at least one vendor who disn't have GPS simulators and relied on Trimble's built-in test mode - which gives you 13-bit week counters, whereas the satellites give you 10-bit counters. So the vendor assumed 13-bit and was comparing the current wc to 13-bit that never came. Luckily I found the issue months before the event, and only because we purchased GPS simulators - which I recommend to anyone running timing services in production. Oh well, at least this keeps us busy. Original Message From:noah.ro...@gmail.com Sent:21 July 2016 5:11 p.m. To:time-nuts@febo.com Reply to:time-nuts@febo.com Cc:hmur...@megapathdsl.net Subject:Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year > On Jul 21, 2016, at 5:23 AM, Hal Murray wrote: > > > noah.ro...@gmail.com said: >> Discovered that my commercial GPS appliances opted to *apply* yesterday's >> pending leap second, which has made for an interesting day. > > Could you please say more? > > How are you working around it? > > Vendor? Model? Can you take the cover off (or peer in through the vents) > and see what type of GPS receiver they are using? In earlier email. > > I assume the gear is recent or the problem would have been discovered the > last time we had a leap second. Have you contacted the vendor? Have they > confirmed the problem? Any estimate on when they will ship new firmware? We just finished replacing our previous gear with this a week ago; timing is everything. :) Vendor was contacted yesterday and have supplied a patch this morning to reduce the GPS->UTC offset back to 17 until they get a more permanent fix from Trimble. I've not installed it yet, but the vendor states the patch won't persist across reboots. --n ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] 1 PPS 50-ohm driver
Florian, Gerhard, All, Thank you for the extensive answers. Just to think that at some point I passed exams where I had to implement truth tables in "raw" NMOS/PMOS - things evaporate quickly enough if you don't refresh, and then years go by and you wish you had been paying more attention. The moment you mentioned that a CMOS NOT gate only requires two transistors, it all came back. As to Beaglebone Black and "use use whatever you have", fine for 1PPS input, I'm using an SN74AHCT125 for the moment, I may revisit that. But for the output, I do want the slope to look decent and the signal to be able to travel over some length of coax, even if not so precise. I am developing a PTP slave timing probe based on the BBB - you sync it to PTP and take a reference 1PPS input to compare the phase. Or alternatively, sync time to GPS + 1PPS, or just phase to 1PPS, and run PTP read-only and report the observed offset. The hardware right now is the bare minimum required to get the signals in. On the software side, for 1PPS input, I am able to stay within the resolution of the counter used for event capture, which runs at ~24 MHz, so about +/-40 ns, I'm getting a pretty clean sawtooth. For the 1PPS output, I'm using a PWM pulse, which is aligned to top of PTP second using a PI servo (counter overflow generates a PWM pulse and a timestamp at the same time). PI servo because it's a standalone device and the real frequency can be unknown. Well, I can experiment with pure correct-and-rearm next, PI was a quick and lazy solution. Also the PTP clock resolution is 4 ns, so quantisation error is a problem, more for the output than for the input. I can't test the quality of the output until this is hooked up to a proper counter. Well, in fact I can't compensate for the h/w interface delays either until I run this against a decent scope. Yet another embedded project, but I will be happy to share the results when ready. This is definitely not lab-grade stuff, but it is designed to be used environments where you're aiming for sub-100 us accuracy, so 100 ns is well enough, and for cheap. BBB is 100 megabit, but the upcoming BBB Enhanced (third party fork) is gigabit. Kind regards, Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] 1 PPS 50-ohm driver
A slightly naive question(s) perhaps, so do excuse me, but I reckon this is a good opportunity to ask since I am approaching the same design questions (this is a 1PPS in + 1PPS out driver for the Beaglebone Black, to/from its PTP clock). This involves 5v / 3.3v conversion but that's another topic. IC spec sheets are one thing, but since the Time Nuts have seen and done it all... Why an inverting buffer? Is there an advantage in using inverted logic for 1PPS? I have come across other timing kit that internally uses falling edge, which is eventually inverted when interfacing with the outside world. Is this common, and why? If my output is rising edge right from the PWM pin I'm using to generate my 1PPS (again, separate topic), do I gain anything by inverting it and using an inverting buffer? Is this a matter of different rise/fall propagation delays over the various ICs? Thanks, Wojciech -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS Outage
Funny how apparently Trimble were involved in the wk860 problem, I thought they famously used their leap second based rollover protection: http://www.google.co.uk/patents/US5923618 :) Maybe that algorithm isn't that smart after all. Thanks, Wojciech Original Message From:martin.burni...@burnicki.net Sent:29 February 2016 11:02 am To:time-nuts@febo.com Reply to:time-nuts@febo.com Cc:hmur...@megapathdsl.net Subject:Re: [time-nuts] GPS Outage Hal, Hal Murray wrote: > > martin.burni...@burnicki.net said: >>> Strange that at least 3 independant firmware trees/development teams should >>> chose the same magic wk860. > >> I don't find it strange. If the next firmware version is based on the >> previous version and none of the developers has stumbled across this >> potential problem earlier ... > > That sounds like poor software engineering. Or poor engineering management. > > The wk860 is supposed to represent the build time of the software ... Do you *know* this, or are you just *assuming* this? ;-) > so it will > work for 20 years from when it was built rather than 20 years from when the > 10 bit week counter last rolled over or 20 years from when the constant was > last updated. There are also approaches where the proper extension of a week number doesn't just work within a single 1024 week cycle with some hardcoded limit, like this simple example: if ( wn < 860 ) wn += 1024; There may always be pieces of code which generate a faulty result under certain conditions, and no stumbles across this even in reviews until it really happens. I'm not aware of *any* project where each single line of code is checked once again whenever a new release is rolled out. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] End of Loran-C in Europe confirmed.
I have a memo / stakeholder briefing document from the General Lighthouse Authorities UK/Ireland (can't see any confidentiality notes on it), that states: "" 4. Effect if France Terminates eLoran It is hoped that the RNTF [http://rntfnd.org] commercial initiative can maintain the continuity of eLoran transmissions from France beyond the end of 2015. However, in the event that the French and Norwegian transmissions were to cease, all maritime eLoran Navigation capability in UK waters would be lost immediately. In addition, the UTC basis of precise Timing of the Anthorn eLoran transmissions would also be lost, unless an alternative link to a source of UTC in the UK could be provided. The Loran transmissions from Anthorn could be continued to provide precise Timing (with intervention to synchronise transmissions to UTC) for the benefit of UK and Irish CNI, but the maritime mandate of the GLA does not cover this intervention. Without French transmissions and hence with no maritime benefit, the GLA have no mandate to maintain any eLoran capability in the UK and would plan to close the service down. "" Chronos in the UK have partnered with UrsaNAV to form this: http://taviga.com . The various UK government bodies support eLORAN and the people involved say they have the capacity to make Anthorn a master station. They need a UTC reference, but given that the NPL are transmitting MSF from Anthorn, I would assume that traceable UTC is already there. All that's left to do is wait to see what actually comes out of this, but things are looking bleak for now; for positioning you can't do much with Anthorn alone. Thanks, Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] trade timestamps
Long time lurker here. Hefty read follows - apologies. Can't blame anyone for TL;DR. On 11 November 2015 at 02:07, Alexander List wrote: > > On Wednesday, November 11, 2015 03:15 AM, Don Latham wrote: > Indeed. HFT firms have been working on their own "advanced" timekeeping > using PTP and GPS and what not, but it seems the MIFID-II directive and > equivalents in other markets force the entire industry to up their > systems from NTP to PTP... It's all nice and simple when you have a GPSDO in your lab and nice, steady 10 MHz, and that's that. So far MIFID-II sets a precedent. The tightest US requirement is currently 50 ms to UTC (time error, not timestamp granularity), but the US is bound to follow EU at some point. PTP has been pretty much a standard for bigger trading firms for 5+ years. I first saw it in 2007. Until now, it has only been used by traders to gain advantage in establishing data arrival times, and exchanges used it to maintain timestamp consistency between different components of a trading system. Now it becomes a legal requirement for both. They were all screaming and shouting, but the EU settled on 100 us from UTC (only for firms with low latency systems). Initially they suggested 1 us! NTP is on the way out, but it's not the protocol's fault, it's the implementations' fault. Long poll intervals, small amount of samples and no hardware timestamping. PTP resolves all of those in its very core definitions - and implementations follow. Your clock may be stable, but if you're polling every 16 seconds and packet delay variation of the network stack outweighs your path delays, and you have no accurate transmission timestamp, no Allan Intercept will help. Suboptimal measurement, and you have crap in, crap out. Hardware can do small nanoseconds, the problem is getting the time to the operating system where the application lives. People have to realise that they are not driving actual crystals, just software models describing OS clocks, that only use assumed known frequency as a starting point. It is advanced timekeeping, considering scale, network conditions, monitoring, holdover, mitigating GPS vulnerabilities, complex GPS distribution into data centre bunkers, calibration, etc. OK, it's not exactly China Mobile with 700,000 base stations using PTP, but it's pretty advanced in my humble opinion. With software-only PTP, with good filtering you get low microseconds, albeit somewhat noisy. With a PTP timestamping NIC you can get sub-150 ns between OS and NIC, and the NIC can definitely get sub-500 ns to reference, assuming little or no delay asymmetries, or use of PTP transparent clocks across the whole path. 100 us is easy if you architect it right, the Finance community just has a lot to learn. For many engineers from the "IP generation", phase and frequency concepts are completely foreign, they mix definitions and generally get confused. NTP you could just leave running, syncing to something, and it gave you a number. With PTP, suddenly every small detail affecting phase offset has to be understood and accounted for, because your target is smaller. It also works the other way round: explaining the problems of time sync in enterprise networks to frequency / telecom people (vendors) is a tough task. I have been doing this for a few years now, and today they mostly get it. Now they have to explain "their" stuff back to the users and everything will be fine (ha-ha). Before the legal requirement is cut down to 10 us, hardware timestamping will be available on every NIC (mostly is today for new systems), and sync will be much less challenging. Solving the "Last two inch problem" ( (c) John Eidson), that is building computer systems that are time-aware and time- correct by design, will be the last task on the road to ubiquitous sync. Intel have already laid the foundations allowing to relate the TSC counter to PTP time, and there is the PTM functionality in PCI Express 3.x+ spec (basically PTP over PCIE). Finally, there is Synchronous Ethernet, providing tight frequency lock between network ports - add PTP for phase and time, and you've got White Rabbit (picosecond accuracy). The funniest thing about MIFID-II, or rather ESMA, the regulatory body, is that they question the traceability of GPS time to UTC! Perhaps because the EU has Galileo. Apparently. [disclaimer: personal opinions only] Thanks, Wojciech -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] When NTP goes wrong...
I think this is a classic case of confusing application security with network security. The whole idea relies on spoofing packets. A spoofing scenario is only realistic in a lab setting. Or in case of a physical takeover of a circuit, which - well, then you have more important things to worry about, and please show me an actual existing case. The series of off-path attacks described are off-path only because they don't require intercepting previous communication, but they still require spoofing. Theoretically any application using a connectionless protocol like UDP suffers from this "vulnerability" to spoofing one way or another. My personal favourite statement "on a properly designed network..." usually negates most of those. PHK - as you say, the only cure is to have your own NTP servers, and any serious organisation out there does. The paper definitely has some research value, but in my opinion the negative publicity generated by this is overblown and undeserved. One thing I will agree with, is that there are too many random NTP servers out there which are dusty boxes sitting somewhere in the broom cupboard, running ancient software. However, all those vulnerable public NTP servers are vulnerable if you're sitting next to them. Regards, Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Symmetricom experts?
Hi Chris, This is a Linux box - an x86 box in fact. As far as I remember they even have VGA pin headers on the board inside. Boot it up with the serial console active and see if you get anything meaningful, but I doubt it. I opened one up for the same purpose last year but I don't have it to hand anymore and I don't remember what the exact platform was. Open it and you may be able to connect to it by other means than the serial port - which I found to be of little use for troubleshooting. It could be something as trivial as the box stuck in fsck prompt because of a corrupted FS. They do have dual partitions, but I'm not sure whether they can actually fail over, or is the second partition used only during f/w upgrades. Is the statement about copy protection actually confirmed? I would try finding someone with another S200 and copying the CF card first. And yes, they will want ,££s, and it got worse since the Microsemi acquisition. I have witnessed multiple S2xx deaths. Usually PSU fail, but death on power cycle is not uncommon either. Thanks, Wojciech On 24 September 2015 at 09:46, Mike Cook wrote: > Hi Chrs, > Not an expert… but usually computer systems give some indication of why > a boot is failing on the systems console. The S200 is probably a unix based > system as it has utilities such as SSH. TELNET. HTTP. So you could try > connecting an RS232 terminal , or telnet’ing to its console server if it is > managed by one. Then power it on again and see what the symptoms are. If > there is no output, then it is a probably hardware problem and you will > need to either have it serviced, or dig into it yourself . I doubt however > that it is user serviceable. > There are troubleshooting steps in the user manual, so I suggest you look > at those. If you don’t have the manual handy, see > < > http://iecitel.com/resources/ntp%20network/S250/SyncServer%20S2xx%20User%20Guide.pdf > > > > Have fun > Mike > > > Le 24 sept. 2015 à 09:21, G1FEF a écrit : > > > > Do we have any Symmetricom experts on this list? > > > > I've had a Symmetricom Syncserver S200 GPS+PPS with rubidium clock > running for several years until we had a power cut and the UPS battery > failed, on powering back up it won't boot at all. > > > > I suspect the flash is corrupt but they protect it in some way, so one > can't just copy the o/s onto a new card, and the company want 's to fix > it for me! > > > > Thanks in advance, > > Chris > > > > > > ___ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > "The main function of a modern police force is filling in forms." > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] IEEE 1588v2 on CISCO IE 3010
Hi, Excuse the lengthy reply; I hope it helps however. Excuse if I'm stating the obvious here and there. I have not worked with the IE series, but other than physical build options like DIN rail mount and IP67 (and protocol support), they are largely just normal Cisco IOS Ethernet switches. IE3000 and IE2000 (newer) support PTPv2 in boundary and transparent clock modes, here's an example: http://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie3000/software/release/12-2_50_se/configuration/guide/ie3000scg/swptp.html What your switch will support (and if it will), will depend on the software image installed, not only the hardware. You may want to upgrade to the latest IOS 15.x as well. Not sure how familiar with Cisco IOS you are, but their CLI syntax for PTP on this kit is common - material from the link above should work on your platform. The easiest thing to do is just explore the CLI - see what PTP-related commands you have available in config mode, and what PTP-related commands you can see in exec mode ("show" commands). If you can't find it, then you will likely need a different software image. Since you're not under a support contract, you may need to search the Internet for images and you might get lucky. If you have not worked with IOS, this is a very popular platform and there is an abundance of beginners' guides available. If not Boundary Clock, the switch should at least support End-to-End Transparent Clock operation. In fact, it should be enabled for E2E Transparent by default (only the base ports; uplink modules don't support PTP). It is not clear what PTP profile they support though, but this being an Industrial Ethernet switch (and Layer 2), it may only run PTP over Ethernet transport, and not IP/UDP multicast. An easy test is to run a PTP conversation between a master and a slave through the switch, do a packet capture and look for the presence of values in the CorrectionField of Sync, (Follow Up in two-step mode), Delay Request (in one-step it's on egress towards master) and Delay Response. If CorrectionField is non-zero anywhere, you have a TC in the path. Some vendors will not tell you this in the datasheets, but some Transparent Clock implementations may only support PTP One-Step mode or Two-Step mode, not both. For example, if you're running one-step and the switch is not populating CorrectionField in Sync messages, it doesn't support one-step. If you're running two-step and CorrectionField is still in Sync, not in FollowUp, the switch only supports two-step; etc. Regards, Wojciech On 15 September 2015 at 22:06, Andrew Symington < andrew.c.syming...@gmail.com> wrote: > Dear All > > I have managed to get hold of a 24-port rack mount Cisco switch > (model: IE-3010-24TC) which, according to the datasheet, is "IEEE 1588v2 > hardware ready". I am developing a Quality of Time stack for Linux as part > of a research project, and I would like to use this switch to synchronize a > test bed comprising of 20 BeagleBone Black slave nodes. > > Despite the advertised IEEE 1588v2 support, none of the Cisco software > documentation covers PTP configuration. Cisco support is not being very > helpful to me, as the switch is not covered by a Smartnet contract. > > Does anybody have experience configuring PTP on this switch, which they are > willing to share with me? > > Regards > Andrew Symington > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Trimble Resolution [T, SMT, SMT GG] - spontaneous GPS loss of signal events, multiple locations
On 14 September 2015 at 17:06, Brian Inglis wrote: > Hi, > Probably the vendor if no one else experiences or knows of Resolution > issues. > You can contact Trimble UK or Trimble Navigation Europe in Hampshire and > they > may know about any product or vendor OEM issues. > If you can get the timing down to 30s GPS frame times or 750s/12.5m > message times, > it could possibly be a GPS system issue like updates, and you can report > problems at: > http://www.gps.gov/support/user/ > which links to the form at: > http://www.navcen.uscg.gov/?pageName=gpsUserInput Thanks - I have a case open and the vendor saw the same in their labs. I'm aware of the 12.5m issue: the last Res T f/w (1.17) lists this in the change log. I don't think this is what's affecting us, but this is one of the things I'm trying to get the vendor to look into. Actually looks like I forgot about the obvious. I have one of those receivers at home and it's an old engineering sample (no warranty, no worries) so I'll hook up the module to at least check the firmware. Regards, Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Trimble Resolution [T, SMT, SMT GG] - spontaneous GPS loss of signal events, multiple locations
On 14 September 2015 at 15:37, Mike Cook wrote: > > Hi, > I have both -T and SMT and have not seen this on the 5th or afik any > other day. If you have other dates, I can check those in more detail. > OK - I think this itself excludes an issue with the boards. What firmware are you running on the T's: 1.17, 1.14 or something else? > I would suggest that if you have spare capacity, that you remove one of > the receivers from its platform and monitor with it hooked up > independently. If it is shows no issue then you can go back to the vendor > with the evidence. > Thanks Mike - I didn't mention in the original e-mail that I am not in a position to remove the receivers as these are boxes under support / warranty, even the lab ones I test with. I was trying to establish if this is a Trimble issue, because the vendor tends to have little clue. Long story. Also since I can't remove them, I can't check their firmware. I have some standalone Resolution T's at home, but I don't have them operational 24/7. I should probably fire them up. Best regards, Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Trimble Resolution [T, SMT, SMT GG] - spontaneous GPS loss of signal events, multiple locations
Hello Time Nuts, I was wondering if other people have seen this. 20+ receivers and they all use different variants of the Resolution boards - majority are the old Resolution T.We have observed sudden GPS loss of signal occurring. Seemingly nothing unusual, these things happen, that's what holdover is for, etc... however: - All devices are connected via decent distribution amps, - All installations use roof-mounted antennas with unobstructed 180 degree sky view - All devices see about 11 birds most of the time - None of these events coincided with known GPS SV outages And here's the fun part: - This is happening in multiple locations in the US, AND in the UK - The log timestamps (UTC) for the alarms, are *exactly the same* across all sites, down to the second. This happens twenty to ten seconds before midnight, and usually recovers within two or three minutes. The last event was on 5th September, at 23:59:37 UTC. We have seen this happening anywhere between once every month to once every two months. Time may differ by a few seconds, but it's the same across all devices. I'm trying to establish whether the issue is with Trimble or with the vendor who embedded Trimble. Because of what I refer to as "vendor anal-digital decoupling delay", I have to investigate in parallel. Has anyone seen this with Resolution? Unfortunately I have no visibility into firmware versions in the Resolution boards. Any pointers welcome. Many thanks, Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] LORAN-C reception in the UK
Dave, I'm afraid I can't give you a quantitative answer about LORAN-C, but I can say that eLORAN is your friend. It has recently been revived in the US and it's doing all right in Europe, UK included. The promise in general is 50 ns to UTC. UrsaNav make some receivers and Chronos (who are a big eLoran advocate) distribute them in the UK, along with their own product. I take it you don't already have the FS700? In that case I think it's definitely worth looking at eLORAN. Again, note that I'm also not using eLORAN at the moment, but I'm looking at it very closely as a GNSS alternative. Cheers, Wojciech -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Time in a cave
o solution to discipline via CDMA. > > I'm also curious if anyone has any idea about non-GPS time sync after CDMA > gets turned off (can I get time from 4G?). > > My endgame worst case is to just do PPS from a stratum 2 NTP (or even a > freerunning oscillator) and lie to my PTP server; hard sync to UTC is a > secondary concern so long as the cluster agrees with itself. Endrun is > looking pretty good, but I'd really like to have a second option to compare > against. > > -Joe > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
On 7 Jan 2015 00:23, "d0ct0r" wrote: > > > Hello, > > The same question is for UNIX epoch time. How computers knows if it is necessary to add leap seconds ? During the event, the kernel raw time (assuming UTC) will go from 23:59:58.9 straight to 00:00:00.0 when removing a leap second, and when inserting one, Linux for example will go 23:59:59.9 to 23:59:59.0 again. The time formatting library functions (aware of leap and time zones) will turn the latter into xx:59:60. As to how the computer knows - some time sync software (NTPd, PTPd etc.), which is made aware of the event from upstream, needs to tell the kernel about this - on systems with the kernel NTP API like Linux, BSDs and others, this is done by setting a respective STA_INS or STA_DEL status flag with ntp_adjtime() or adjtimex(). This can be done in kernel up to 24 hours in advance. When either of the two flags is set, the kernel will trigger the leap event in the last seconds of the current day. GPS should announce the pending leap second not long after the IERS announcement. I haven't checked my clocks yet but it may already be out there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] rs-422 rs-232 to fast ethernet converter
Ser2net is the way to go for me. A hardware solution I have been using for this purpose for quite a while are those tiny USB-powered SoC-based "3G / 4G portable routers" from vendors like TP-Link (good little case designs - TL-MR3020 for instance which I currently use). The "3G" models don't actually have cellular modems, they just have a single USB port - and a Fast Ethernet port, and 802.11. They (can) run Linux. The newer ones have 4M onboard flash and you can flash them instantly with OpenWRT. You can drop the web UI to trim down flash usage if you want, but out of the box they will fit USB-serial drivers and ser2net. Just add a USB to serial cable (or even go wild and buy a quad one with an USB hub built in) and you are still below the price of a Raspberry Pi, nevermind a dedicated serial to Ethernet box. You can also add a mini USB hub, stick a mini USB key in and use it as storage overlay. OpenWRT has all the tools you need available in the package repositories. I paired mine with a 12Ah portable USB power bank, clipped on using 3M Command(tm) hook-and-loop straps. It ran on it for 48 hours straight. This setup has proven an invaluable tool in data centre work for emergencies and upgrades. I can hang it in a rack or keep it in my pocket, connect to kit using serial or Ethernet, and work from my smartphone over wifi. File transfers, firmware upgrades, whatever you want. Not sure if ser2net supports X/Zmodem somehow (it's probably down to the telnet client here) but for the times you need it, there's minicom. Naturally, USB-RS converters are not always the way to go, but the RPi needs one as well, it can only do TTL natively. With some DYI you can put the router board, USB hub and battery in a neat little box as well and add an antenna, for improved usability. Regards Wojciech Wojciech Owczarek -Original Message- From: Paul Alfille Sender: "time-nuts" Date: Mon, 24 Nov 2014 22:38:04 To: Discussion of precise time and frequency measurement Reply-To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] rs-422 rs-232 to fast ethernet converter There is a protocol for ending serial commands over telnet (tcp): RFC2217 See http://tools.ietf.org/html/rfc2217 A number of command line tools, like ser2net and netcat use the protocol. Some of the small serial servers support it and it can make using serial remotely tunneled over tcp seamless. On Mon, Nov 24, 2014 at 6:23 PM, Graham wrote: > > I have done a bit of searching and found that what I want to do is nothing > really new and their are several off the shelf applications which will work > just fine - linux and Windows based hence the mention of the Raspberry PI > and Beaglebone Black. Some of the higher end Arduinos (i.e. Yu) are capable > of running linux and Windows as well but it would be entirely possible to > roll you own using the lower end Arduinos as well. > > I found some answers rather quickly after I started searching for the > right things, for example Serial to Network Proxy. > > On Windows you could use a virtual serial port to do the redirecting from > com port to network and on linux there are several the one I found often > mentioned is socat. > > The little serial to fast ethernet boxes which I was finding would work in > the situations where you don't have a computer near the device you are > trying to connect to, they act as the Serial to Network Proxy. In my case, > I have a computer nearby which runs linux and is my GPS disciplined NTP > server. I have purchased a RS422 to USB interface cable which will connect > the KS-24631 to my linux box. Now I just have to sort through all of the > information I have found and figure out just which app I need on the linux > box (likely socat) and which one on any of the other computers on my > network with which I may want to connect to the KS-24631. And of course, > how to configure them. > > cheers, Graham ve3gtc > > > > > On 2014-11-24 08:42, Jim Lux wrote: > >> On 11/24/14, 2:20 AM, Graham wrote: >> >>> Interesting. >>> >>> I have also been thinking that it might not be too difficult to >>> implement using Beaglebone Black, Raspberry PI, or even one or another >>> flavour of Arduino. Lots of possibilities from simple to not so simple. >>> >>> >>> >> The challenge is always trying to figure out what sort of protocol to use >> for encapsulating serial data in the Ethernet Stream. Do you send each >> character in its own UDP or TCP datagram? Do you batch them together and >> send a message every TBD milliseconds. >> >> Ideally, you'd like the protocol to match some commonly available client >> on the oth
Re: [time-nuts] FYI: NPLTime(R) - a new service providing a precise time signal directly traceable to Coordinated Universal Time (UTC) and independent of GPS.
NPL Time will be delivered to access centres where those finance people are already present, from there it's only a matter of a crossconnect from their kit to the client and other operators. Regarding the three seconds - this is about to radically change with the upcoming EU directives (MIFID II) and US ones (SEC regulations) are brought out. We may see a 100 us target. Obviously with timing distance is of less importance as long as links are of symmetric latencies and low packet delay variation. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FASTRAX GPS
My 2c - RS232 is extensively used in data centres over cat5 with network kit for out of band management via serial consoles, usually 9600 baud. I've done this many times via (multiple) patching panels/frames easily over 100ft, ribbon/rollover then cat6 but also cat5. This kit tends to be reliable and usually well grounded though. Well, and "compliant". Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Linux TSC clocksource on multi-core systems
Laszlo, What sometimes helps is additional kernel command line parameters, namely acpi=off (maybe you wouldn't have to disable the PM settings in the BIOS if you had this) and noapic, also there is the clocksource=tsc parameter which should make TSC the preferred clock source (that's if it's operational). This all depends on your kernel version as well. My experience is that the TSC sync issues were mostly an AMD thing and some CPU / chipset generations ago, and anything modern should behave correctly - but clearly the Atom doesn't. Perhaps some platforms are just not meant for timing - some googling shows a lot of Atom D510 results showing TSC clock source not starting. The problem with writing the TSC is that it's a moving target that gets incremented with every CPU tick. It is writable with the wrmsr (0x10) instruction, and there's a write_tsc macro defined in asm/msr.h that does exactly that, but you also need to send it to the right core. One thing worth mentioning though is that issues like this can sometimes be resolved with a BIOS upgrade - always worth a try. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Affordable (cheap) COTS / eBay kit for TIE / 1PPS phase comparison
Thanks for your suggestions so far everyone, The picPET would be a great solution if it could run at higher frequencies - but now there's a separate thread about that :) Magnus - my reference is a Brilliant Telecom (now Juniper Networks TCA series) PTP grandmaster (TCA8000), which does PTP and has E1/T1/BITS/frequency outputs. Internally it uses a Trimble Resolution T board for GPS/PPS. I think it could run Rubidium if I replaced the OCXO with a SpectraTime LPFRS. I'm familiar with Stable32 and I have a basic understanding of frequency stability / phase noise measurement concepts, but for the most part I will be simply looking at realtime phase offset measurement to test filtering and PI servo optimisations. Regards Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Examples of leap-seconds in local timezones
Magnus, I have little experience with radio-based public time dissemination services, but some with GPS/NTP/PTP, so here's some info - hope it's of some value to you. For US and European exchanges, the leap second time happens outside trading hours, so maybe that's why we've heard little (horror) stories. This is definitely not an easy thing to deal with during trading, unless your messaging protocol actually has specific leap second extensions - which I'm not aware of any of the ones I know having. This is how the Linux kernel running UTC does it (assuming it's been told by NTP/PTP/GPS/user and the respective leap second kernel flag was set - and for example, a broken IRIG-B box somewhere hadn't forgotten to tell some of your NTP servers about this and your quorum blocked it): - If we're removing a second, Linux system clock will change from 23:59:58.9 straight to 00:00:00.0 - If we're inserting a second, Linux system clock will run the last second second twice: 23:59:59.9 will change again to 23:59:59.0 (that's the kernel internal / UTC time, time formatting functions will output the :60 value at insertion time). This approach can potentially be problematic for some applications, especially the insertion, which is essentially a step backwards, so some institutions / vendors propose an alternative approach, which is the leap second smear - I think Google was advocating that one: this is where you gradually add/take the extra time throughout the whole leap second day (which would be an approx. 11.6 ppm offset if you started from midnight - so you'd have to model this carefully to bring it back to normal soon after the leap second midnight). Those alternative methods of time insertion may be fine if they're used only internally within an organisation that doesn't provide timestamped data to other organisations, without also providing time services to them - or basically, all is well as long as interconnected parties use the same method of dealing with this. *personal opinion* While the leap second is a somewhat inconvenient phenomenon, while it's still there, it's there and we have to deal with it. I think that most of the problems around it that people talk about are a little bit of FUD resulting purely from the lack of adequate testing. This is based on my experience with computer/network kit - this wasn't meant to be an absolute statement. I'd say let the IERS keep computing it but let's drop it from UTC and let's do a one-off leap hour in some 4,000 years :-) Regards Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Affordable (cheap) COTS / eBay kit for TIE / 1PPS phase comparison
I meant I have *no* time to spare to complete one. Thanks Wojciech ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Affordable (cheap) COTS / eBay kit for TIE / 1PPS phase comparison
Hi List, I'm a software developer turned network test engineer slowly turning time&frequency guy (not sure if this is upwards or downwards ;-) ) with some distant background in electronic engineering. For the last couple of years I have been increasingly involved in various work involving IEEE 1588 and finally I started fitting out a small home lab setup. I never really needed lab kit at home before and my work lab is primary to do with Ethernet and IP (and timing, but outside my price ranges), so I was wondering if you could point me in the right direction: I'm looking for some reasonably inexpensive solution to allow me a) to do TIE measurements of 1PPS signals against a reference and b) do phase comparisons of different 1PPS signals - so something with REF and at least two inputs. I have an OCXO GPS reference (upgradable to Rb) with 1PPS, 5MHz and 10MHz outputs which is stable enough for my needs so that part (perhaps most important) is sorted. In terms of requirements, granularity wise, well, as good as achievable - I'm used to 10 ns and 5 ns granularity with TIE that I get from work kit. 50 ns or better would be perfect. I must add that ideally I would like to avoid having to design or build the kit myself - I would love a project, but I have time to spare to complete one. Any pointers much appreciated. Best regards Wojciech -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] PTPv2 grandmaster with a Z3805A?
On 20 August 2013 21:16, Poul-Henning Kamp wrote: > You never should, for precision timekeeping, for a host of technical > hacks, all outside your control. > I brought up TSC only as a, to me, better alternative to HPET / ACPI. Of course it's not good enough for serious timekeeping, no "mostly software" clock is. > support for timing electrical signals > using the same free-running counter as used for the PTP packets. Sounds interesting. Can you elaborate? Does the card then run its own clock? > > but it's the best chip there is right now OK, different price range, but do you think it trumps the likes of SolarFlare's 10GE adapters with dedicated OCXOs, or copper-only cards with OCXOs like Oregano's, or other dedicated timing NICs? What makes it stand out so much - is it just that it supports all that's needed without being marketed as a precision timing NIC? Best regards Wojciech -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] PTPv2 grandmaster with a Z3805A?
On 20 August 2013 19:12, Mike S wrote: On modern x86 processors, both Intel and AMD, the tsc increments at a > constant rate, independent of the CPU frequency. I keep forgetting about constant_tsc. -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] PTPv2 grandmaster with a Z3805A?
On 20 August 2013 17:16, Mike S wrote: > > By default, the tsc is calibrated at each boot, which means that timing > will likely change (and ntp drift values will be off) each time you boot. > > There's a linux kernel command line option which will fix that and provide > consistency between boots, something like "clocksource=tsc > tsc_khz=2410988". The exact value depends on how fast the processor is > clocked. True, this will help, and needless to say, dynamic CPU frequency etc. is a no-no, and it's best to bind the (ntp) process to a single CPU core. However I find it that the drift differences will be sub-1ppm across reboots. In my case (data center) they are in fact sub-500ppb - calculated with ptpd. You always need some stabilisation time after reboot, especially that your wall clock will likely get re-initialised from RTC. I think overcoming that may sometimes take longer than re-calculating drift. I pointed to TSC mostly because of the PTP GM side of the original poster's query. Regards Wojciech - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] PTPv2 grandmaster with a Z3805A?
On 20 August 2013 11:03, David Gravereaux wrote: > Hi, > > I've been lurking a bit and absorbing. > So have I. > Are the 3.58 MHz ACPI timers okay or should I use the 25MHz HPET ones > for system clock? I would recommend the TSC time source: lowest read overhead. All three have different behaviours - different (cold start) frequency offset and different drift rates once stabilised and then left drifting. However reading time with TSC time source takes least amount of time and id least prone to jitter , which helps with timestamp accuracy. Regards Wojciech -- - Wojciech Owczarek ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.