Testing ntpd and/or timing from gpsd

[Chris Johns]

On 13/05/2016 07:37, Gary E. Miller wrote:
>
> It would be insane for a switch to have EEE enabled without a way to
> turn it off, so you likely have never seen it turned on.

The switch should only enable EEE if the PHY says it is ok. If you 
disable it in the PHY and switch should honour it. A PHY that knows 
nothing about EEE can not be expected to interoperate with a port 
operating in that mode.

> I can enable autonegotiation for EEE it on some of my switches, nothing
> but trouble.

I would make sure this is not a compliance issue with your switches 
and/or PHYs connecting to it. I seem to remember some issue with early 
devices that ended up not matching the standard but I cannot find the 
references. Power up latency would be an issue as a send results in a 
reset timer starting in the PHY and depend on the MAC the data may be 
buffered in the PHY until the link has come up.

EEE and PTP together does not make sense to me.

If you are looking at this level there are a number of PHY configuration 
parameters that can effect things such as pause frames and flow control, 
then there is switch memory configuration and congestion in the switch. 
I have only seen a need to dig into layer 1 for special back planes and 
custom hardware. Most defaults work well.

> If your backbone is GigE then it is likely way better than you think.
> Turn on PTP and your hosts will time link closer than you have ever
> seen, if it works at all.  Hardware timestamping of the ethernet packets
> works well, when it works at all.
>
> PTP shows that the main problem with high accuracty NTP is the network
> stack and the OS, not the network itself.

Yeap, this is important once you get down to this level. Xilinx 
recommend using an RTOS when doing PTP on their Zynq processor and 
Marvell talk about measuring the delay in clocks in their PHYs. 
Interrupt latency seems to be the key factor.

Chris