Hi

I think the key parameter is the 8 ns resolution on the time stamp.
That may or may not be adequate for this or that application.

Without doing a deep dive on the part, it’s not real clear how they
deal with the accuracy of the onboard timebase. It’s rated at 0.01 ppm
with no real details. Obviously if it is free running and there is no
practical calibration approach …. that will add to the error as well.
One would hope they thought about this ….you never know...

Bob

John Miller via time-nuts writes:

I used the i82599 ethernet chip ten years ago, to measure time in
the first Adaptive Optics Real-Time Computer prototype we built for
ESO's ELT telescope.

I have revision 2.73 of the datasheet (930 pages), but that is
probably publically available theses days in a newer revision.

The timestamping counter gets its clock from the ethernet line
signals, and the counting frequency therefore depends on the ethernet
speed:

100 Mb/s	1.5625 MHz
1 Gb/s		15.625 MHz
10 Gb/s		156.25 MHz

(The 8ns timestamping mentioned must be something outside the 82599)

The basic idea is that you can measure the line frequency with the
PPS and timestamp PTP ethernet packets TX and RX relative to the
PPS.

The card is quite picky about which packets it will timestamp, in
particular some of the message bytes must look "enough" like a PTP
packet to be timestamped.  I figured it out eventually, and Intel
promised to update the data-sheet.

I have not tried to use the 1PPS signal input, it was not available
on the cards we used back then and we only needed relative packet
timestamps.

I am not sure what it would take to produce a 10G ethernet signal
from a "house standard", it may not be trivial.

So if you want to build a really good PTP server, yes, go for it,
but it is not much use for more advanced time-nuttery.

--
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.

Poul-Henning Kamp via time-nuts writes:

I should probably expand on this to prevent misunderstandings:

The 82599 chip will timestamp with 6.4ns resolution, and since both
the frequency and the timestamp edge is derived from the ethernet
signal when you time packets, there is no noise process involved,
and you do get your full 6.4ns worth.

I understand the "8ns" number in the datasheet for the card to refer
to the PPS input and assume the extra 1.5ns to be noise in the
analog domain outside the i82599 chip.

--
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.

Hi

Could be. They also mention a 25 MHz clock on the card. That could
get you to a 125 MHz time base with a 8 ns resolution. Again, without
a deep dive into what they did … who knows.

Bob

Bob kb8tq writes:

That is the clock-supply to the 82599 chip, but there is a boatload
of PLL'ery going on such an ethernet chip.

I can't remember the details, but I /think/ a 10GB ethernet runs
as two independent simplex lines.

If so, that 25MHz will only go to the TX side, the RX side will
run at whatever frequency the other end supplies.

Unless the other end is a PTP-aware switch which does clock slaving
from the upstream port and ...

To be honest the entire PTP and White Rabbit thing has gone ...

ehh ...

time-nuttery :-)

--
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.