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
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
