[time-nuts] IEEE 1588 PTP support on raspberry pi 4 compute module

[Poul-Henning Kamp]

--------
Wojciech Owczarek writes:

>This topic was bound to hit time-nuts - great to see Rpi finally going for
>a MAC/PHY with hardware timestamp support and hopefully future full-sized
>models will follow suit. Unfortunately for most chips other than Intel and
>enterprise comms vendors like Solarflare, Mellanox etc, a IEEE-1588
>compliant MAC/PHY means that the silicon physically only timestamps PTP
>packets, whereas with Intel and others, it can timestamp all packets,
>making for example hardware-backed NTP possible.

So a couple of footnotes from somebody who have actually used this kind
of hardware.

What the "timestamping" hardware gives you, is a snapshot of a
counter running a the PHY frequency.

That PHY frequency and its quality depends on what is on the other
end of the cable.

Rule of thumb: If your switch does not have a metal cabinet and
does not speak ssh(1), you will be disappointed.

You need to tie that PHY counter to your kernels timekeeping.

If you do it by appointing it "timecounter", any event affecting
PHY frequnecy, downnegotiation, unplugged cable, power-cycled switch,
EMC, Lightning, shitty hardware will screw up your computer's
time-keeping.

If you do not appoint it "timecounter", you need to poll it from
the kernel often enough to precisely model it detect all of the
above disturbances.

On "real" PTP hardware, this probing uses a separate signal which
is timestamped by the PHY counter *and* the CPU timecounter
you depend on.  This may be easier, and will certainly be cheaper
in magic smoke, on an RPi, but only possible given chip-docs.

(When I did this on Intels '599 chip ten years ago, my questions
regarding these details caused the "datasheet" to grow by nearly
250 pages.)

Absent access to such a signal, you have to do the probing entirely
in software, which is tricky, expensive, and due to the memory-hierarchy
and clock boundaries, very noisy process.

So, yeah... Perfect time-nuts project :-)


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.