Thanks, Yes of course "ARM" refers only to "ARM" Would you know which other systems include the PRUs? Is it only in the TI products? It seems like an ideal solution to the problem of non-deterministic latency. This may not even be required. There is no point to extreme levels of accuracy because the weak link with any NTP server is the Internet. NTP's purpose is to transfer time over unreliable data links and these links will always be the limiting factor. On Sat, Mar 22, 2014 at 1:23 PM, Mike George <mgeorge@tuffmail.us> wrote: > The PRUs (Programmable Realtime Unit) aren't a feature of ARM in general > (they are not present > on the Raspberry Pi for instance). The BeagleBone has 2 PRUs as you > describe. It uses the TI Siatra > ARM variant. > ARM just describes the core architecture. Manufacturers tack on all sorts > of proprietary peripherals > depending on what they envision as it's primary target market. > > Mike George > > > On 3/22/2014 15:54, Chris Albertson wrote: >> >> On Sat, Mar 22, 2014 at 12:24 PM, Chuck Forsberg WA7KGX <caf@omen.com> >> wrote: >>> >>> I can see a use for an inexpensive GPSDO with a built-in >>> gigabit ethernet or USB3 port powering an NTP server. >>> >> >> Neither of those is a good way to transfer time to an NTP server. >> Both Ethernet and USB are packetized. The best way is with a simple >> wire with a square wave pulse on it that pulses ones per second. >> Nothing can be more simple or accurate. >> >> The trick is to build an NTP server that can react deterministically >> to the pulse. I think an ARM based system could far outperform an >> Intel based one. ARM has two independent PRUs. These are little >> 32-bit processes each with 4K of memory that are build right on the >> same chip as the main ARM CPU. The PRUs purpose built for real time >> task and can handle nanosecond level timing. In most existing system >> the PRUs are ignored and everything is done using the ARM. >> >> The other way to improve things even better is to not even bother to >> have a link from the GPSDO to the NTP server. Why not simply run the >> NTP server software on the same processor as the GPSDO? Just one of >> the little PRUs is more than powerful enough to run a GPSDO. They are >> a 32-bit uP that runs at 200MHz, one instruction per clock. The PRUs >> don't run any operating system code but have access to all of the >> ARM's memory and interrupts. A PRU is way-overkill for a GPSDO. >> Doing this eliminates the link cable from the GPSDO to the NTP server. >> If the ARM CPU can't handle 6 billion requests per day then buy many >> copies the ARM based systems. They are cheap. >> >> > > _______________________________________________ > 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. -- Chris Albertson Redondo Beach, California

On Sat, Mar 22, 2014 at 3:53 PM, Chris Albertson <albertson.chris@gmail.com>wrote: > Thanks, Yes of course "ARM" refers only to "ARM" > > Would you know which other systems include the PRUs? Is it only in > the TI products? It seems like an ideal solution to the problem of > non-deterministic latency. > > This may not even be required. There is no point to extreme levels of > accuracy because the weak link with any NTP server is the Internet. > NTP's purpose is to transfer time over unreliable data links and these > links will always be the limiting factor. > NTP running in broadcast mode over a local Gig-E network shouldn't be too bad. I suspect timing jitter is pretty low. -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 brian@lloyd.com +1.916.877.5067

The main problem for NIST or USNO's servers is not the actual time transfer into the machine -- that is a solved problem, but rather getting enough packets spit out precisely enough, with the required signature to make it traceable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

On Sat, Mar 22, 2014 at 2:25 PM, Brian Lloyd <brian@lloyd.com> wrote: > NTP running in broadcast mode over a local Gig-E network shouldn't be too > bad. I suspect timing jitter is pretty low. Gigabit Ethernet can be actually worse than 100BaseT because of the way the hardware works. The packets arrive so fast that interrupts occurs per several packets, not per packet. So on Gigabit systems the NTP packet might not get timestamped correctly because the interrupt applies to a group of packets that all came in close in time to each other. You are best off using 100BaseT But as I wrote before if you are on a local network and are willing to buy special PTP compatible hardware you can use PTP and avoid NTP. PTP relies on external time stamps put on but the network hardware and is about one order of magnitude better then NTP if you have the right network hardware. And if you REALLY care about timing you will distribute a PPS or a 10MHz reference NTP is best used over the Internet. It was designed for unreliable data links. -- Chris Albertson Redondo Beach, California

PRU appears to be unique to TI. I have only used Raspberry Pi, Beaglebone, and Cubieboard. The Cubieboard (Allwinner CPU) has a lot of IO pins like the Beaglebone but nothing like a PRU. Mike George On 3/22/2014 16:53, Chris Albertson wrote: > Thanks, Yes of course "ARM" refers only to "ARM" > > Would you know which other systems include the PRUs? Is it only in > the TI products? It seems like an ideal solution to the problem of > non-deterministic latency. > > This may not even be required. There is no point to extreme levels of > accuracy because the weak link with any NTP server is the Internet. > NTP's purpose is to transfer time over unreliable data links and these > links will always be the limiting factor. > > > > On Sat, Mar 22, 2014 at 1:23 PM, Mike George <mgeorge@tuffmail.us> wrote: >> The PRUs (Programmable Realtime Unit) aren't a feature of ARM in general >> (they are not present >> on the Raspberry Pi for instance). The BeagleBone has 2 PRUs as you >> describe. It uses the TI Siatra >> ARM variant. >> ARM just describes the core architecture. Manufacturers tack on all sorts >> of proprietary peripherals >> depending on what they envision as it's primary target market. >> >> Mike George >> >> >> On 3/22/2014 15:54, Chris Albertson wrote: >>> On Sat, Mar 22, 2014 at 12:24 PM, Chuck Forsberg WA7KGX <caf@omen.com> >>> wrote: >>>> I can see a use for an inexpensive GPSDO with a built-in >>>> gigabit ethernet or USB3 port powering an NTP server. >>>> >>> Neither of those is a good way to transfer time to an NTP server. >>> Both Ethernet and USB are packetized. The best way is with a simple >>> wire with a square wave pulse on it that pulses ones per second. >>> Nothing can be more simple or accurate. >>> >>> The trick is to build an NTP server that can react deterministically >>> to the pulse. I think an ARM based system could far outperform an >>> Intel based one. ARM has two independent PRUs. These are little >>> 32-bit processes each with 4K of memory that are build right on the >>> same chip as the main ARM CPU. The PRUs purpose built for real time >>> task and can handle nanosecond level timing. In most existing system >>> the PRUs are ignored and everything is done using the ARM. >>> >>> The other way to improve things even better is to not even bother to >>> have a link from the GPSDO to the NTP server. Why not simply run the >>> NTP server software on the same processor as the GPSDO? Just one of >>> the little PRUs is more than powerful enough to run a GPSDO. They are >>> a 32-bit uP that runs at 200MHz, one instruction per clock. The PRUs >>> don't run any operating system code but have access to all of the >>> ARM's memory and interrupts. A PRU is way-overkill for a GPSDO. >>> Doing this eliminates the link cable from the GPSDO to the NTP server. >>> If the ARM CPU can't handle 6 billion requests per day then buy many >>> copies the ARM based systems. They are cheap. >>> >>> >> _______________________________________________ >> 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. > >

On Sat, Mar 22, 2014 at 6:55 PM, Chris Albertson <albertson.chris@gmail.com>wrote: > But as I wrote before if you are on a local network and are willing to > buy special PTP compatible hardware you can use PTP and avoid NTP. > PTP relies on external time stamps put on but the network hardware and > is about one order of magnitude better then NTP if you have the right > network hardware. > I believe this may be conventional wisdom but time-nuts shouldn't believe conventional wisdom they should be measuring. E.g. FSM says their NTP+PTP "servers" perform equally well using either protocol. The trick is to use optimized NTP software and timestamping hardware. > And if you REALLY care about timing you will distribute a PPS or a > 10MHz reference > Or, to rephrase "equally poorly using either protocol".

On Sat, Mar 22, 2014 at 6:34 PM, Paul <tic-toc@bodosom.net> wrote: > E.g. FSM says their NTP+PTP "servers" perform equally well using either > protocol. The trick is to use optimized NTP software and timestamping > hardware. Yes. If you modify NTP so that is does the same thing as PTP then it will as good as PTP. That should be obvious. NTP is modular and it is easy to write a new reference clock driver. So if I had time stamping network hardware, I'd want an NTP driver for it and would use it. But most network hardware lacks the feature. -- Chris Albertson Redondo Beach, California

On Sun, Mar 23, 2014 at 1:37 PM, Chris Albertson <albertson.chris@gmail.com>wrote: > Yes. If you modify NTP so that is does the same thing as PTP then it > will as good as PTP. That should be obvious. > I believe you misunderstand my point.