On Thu, October 26, 2017 5:58 pm, Bob kb8tq wrote: > Why go to the green? Cheaper. > Just go with one of these Pocket Beagles I have > sitting here wondering what to do with them. Pocket Beagles do not have Ethernet. How are you going to make a network time server from a board with no network? > get two Pi Zeros for the pice of the Pocket Beagle. Lash an interface > onto any of them (just like the Green) and get going. I suppose you could connect a network interface of some kind using the USB, but I have never seen a USB network adapter with hardware timestamping. Possibly they exist, but I do not believe that a driver currently exists which could read the hardware timer on a USB interface, you would need to create the driver (probably after you created the hardware). -- Chris Caudle

On Thu, October 26, 2017 7:38 pm, Denny Page wrote: > If you are going to do PTP with ptp4l, or NTP with Chrony, you are going > to want hardware timestamping support on the ethernet phy. Or the MAC. The processor used on BeagleBone Black has timestamping in the MAC. Not quite as accurate as stamping in the phy, but should be a relatively consistent fixed offset. -- Chris Caudle

> On Oct 26, 2017, at 19:29, Chris Caudle <chris@chriscaudle.org> wrote: > > On Thu, October 26, 2017 7:38 pm, Denny Page wrote: >> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going >> to want hardware timestamping support on the ethernet phy. > > Or the MAC. The processor used on BeagleBone Black has timestamping in > the MAC. Not quite as accurate as stamping in the phy, but should be a > relatively consistent fixed offset. Yes, but it might not be as consistent as you would like. The Intel i210 is a pretty good reference. It does mac timestamping and has a built-in phy. At 100Mb, Intel advertises a timestamp latency range of 984-1024ns for outbound packets, and 2148-2228ns for inbound packets. The ranges are a result of mac clock issues, unassociated with phy communication. External measurement shows that the mean values are actually outside the ranges given, 1044ns for outbound, and 2133ns for inbound. [I suspect, but don’t know for sure, that the offset is a result of a fixed 20ns delay between the phy and mac.] Anyway, on a loopback between two i210 instances, you will see an average total timestamp latency of 3177ns, with a standard deviation of around 100ns. Pretty good, but not that great. What chip does the BeagleBone Black use? Do they publish specs on the ethernet timestamp latency? Thanks, Denny

Hi Nick, I've got a project along those lines that I've been hacking on for the past three years or so, and always meaning to do a thorough writeup on. I'm more of a software than hardware guy, so the heart of it is a Taijiuino Due (a weird Chinese clone of the Arduino Due, so an 84MHz ATSAM3X8E, with the difference from the official board being that it brings out the SAM's Ethernet pins to a header that you can perch a PHY module on). It then talks to a GPS (Resolution-SMT) and Rb (SA.22c, digitally controlled), multiplied up 25/8 times by a TAPR Clock-Block to get 32ns granularity (more or less). Apart from some of the low-level MAC code which is from Atmel it's all my code for GPS decoding, timekeeping, NTP, etc, and has some basic support for health monitoring and holdover. As a NTP server it's pretty good when it's behaving -- I've got a particularly-stable Linux machine on the same Ethernet segment polling it at 16s interval and chrony reports a 500ns - 1us stdev for it, so you can take that as a jitter figure. It outperforms the old Spectracom NetClock 9183 (w/OCXO option) I've got, in any case. I'd be interested in comparing notes, and also interested in any possibility of designing a PCB to replace the rat's nest of wires I've got going on -- as I mentioned, I'm not "really" a hardware guy and EDA isn't a skill I've picked up at this point. I've always wanted to derive the micro's clock from the Rb (and PLL it up on the chip) rather than having to live with the restrictions of an externally-clocked timer... but making that happen is beyond my abilities :) On Wed, Oct 25, 2017 at 8:53 PM, Nick Sayer via time-nuts < time-nuts@febo.com> wrote: > I’ve just completed a project (off topic) with the ATSAMS70 chip and > learned a lot in a relatively short time, and I really like the result. > > I am considering a new project based on its cousin, the ATSAME70. The E70 > has an Ethernet 10/100 MAC built in as well as the rest of the stuff the > S70 has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), > and Atmel Start (the software development framework I’ve been using) > purports to have a ready-to-use IP stack (alas, no IPv6, but it’s a > starting point at least). > > Where I am going with this is I am considering designing a precision > embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got > piles of up to a GPIO and USART and the Ethernet port would provide > NTP/PTP. The idea behind making it an embedded system would be to try and > make it as accurate as it reasonably can be with the hope that (at least on > the local segment) it would wind up being more accurate than a Pi Zero > doing the same thing. At the very least, you’d expect such a thing to be a > whole lot less hassle to set up, given decent firmware. > > This may be a fool’s errand, certainly, but looking at it from here, I > would think that such a design might offer accuracy in the microsecond > range, but that’s just a tremendously uninformed guess at this point (and > what does that accuracy mean to a peer that might itself be incapable of > better than 2 orders of magnitude coarser?). > > Anybody have any ideas or suggestions along these lines? > _______________________________________________ > 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. >