Hmm... maybe I should also take another look at
common mode noise / signal grounding. Just in case.
Frank
On 24 Dec 2017 at 1:23, linuxptp-devel@lists.sourcefo wrote:
> (
> once again my attachments were over the size limit, see them here:
> http://support.fccps.cz/download/adv/frr/tap/tap-schematic.pdf
> http://support.fccps.cz/download/adv/frr/tap/tap-board.pdf
> )
>
> --
> Dear gentlemen,
>
> apologies for this off-topic question.
> I should probably ask this in lkml or some specific Linux list at the
>
> vger, or electronics.stackexchange... yet, I've noticed some relevant
>
> souls in this list, maybe someone will know...
>
> In the context of my previously mentioned idea, to sync multiple i210
>
> chips via external PPS for precise packet capturing/timestamping,
> I've built a prototype pseudo-passive Ethernet tap for 100Base-TX.
> Schematic and board layout are attached.
> The unrouted traces for power supply rails are implemented by wire
> bridges (and a section of symmetric 100-Ohms cable for the missing
> signal interconnect).
> The "straight through" direction is as free of stubs / impedance
> impurities as possible, and the "tap outputs" are buffered by analog
> amps (electric repeaters, not data buffers) to reconstruct the
> correct voltage. I've paid meticulous attention to impedance matching
>
> and series termination. The op-amps used do have the needed
> bandwidth. I can see beautiful waveforms on the output (when
> loaded=terminated by 100 Ohms at the input of my oscilloscope).
>
> An urban legend would have it, that Ethernet NIC's readily accept
> this sort of tap output, even from a simple wired splitter that's
> impedance-mismatched = suffers from lower voltage and reflections.
> I had my doubt, but wanted to try, and... it doesn't seem to work
> against an i210.
>
> The two peers in the straight-through direction connect just fine,
> I can see nice output on the tap-out jacks with a 'scope,
> but if I attach an i210 by a straight patch-cord, its link remains
> down.
>
> I've tried forcing 100 Mbit full duplex in the eavesdropping i210 and
>
> generally super-simple behavior:
>
> ethtool -s eth2 speed 100 duplex full autoneg off
> ethtool --set-eee eth0 eee off
> ethtool -A eth0 rx off rx off autoneg off
> ethtool -s eth2 mdix off (igb driver refuses this for full/100)
> ...and obviously ifconfig up.
>
> I've noticed that my distro's ethtool was a little stale (3.16)
> so I compiled 4.13 from source (the kernel is 4.13.12).
> Now I possibly get fewer errors from ethtool that "this combination
> of arguments is illegal", but still no go.
>
> I've tried mii-tool, but the net-tools package was last updated in
> 2010 or so, and the SIOCSMIIREG is apparently unsupported
> in e1000e and igb, only SIOCGMIIREG - so the ancient mii-tool
> is not much use, maybe as a check what ethtool has actually done
> (and not a very detailed check at that).
>
> The tap outputs are attached to pins 3 and 6 in the RJ45 (the green
> pair).
>
> I haven't tried yet to load the orange pair from the eavesdropping
> NIC. Makes me wonder if the NIC could wait for a 100 Ohms load
> on the TX pair. Not very likely to me...
>
> I actually have 2 pcs of the i210 currently in the bench system: one
> as a PTP slave, one for eavesdropping.
> I'm wondering if perhaps the i210 actually depends on the autoneg
> handshake for "link up", in spite of it being disabled via ethtool
> for speed and duplex negotiation.
> The autoneg handshake is two-way, in principle. Needs both directions
>
> to work between the handshaking PHY peers :-( I suspect that this is
> also an explanation why the i210 won't link against the Meinberg GM
> if I configure both ends for 100/full without autoneg. Maybe the i210
>
> still awaits autoneg and won't link. If I configure both ends for
> autoneg, and just tell the i210 to advertise 100/full, the handshake
> happens and the link works perfectly. The autoneg handshake appears
> to be responsible for several "smart" features, such as the eee -
> i.e., it is no longer just a matter of speed+duplex :-/
>
> Any ideas welcome... is there something I could tweak in the driver
> maybe, to make "autoneg off" actually remove any dependency on a
> bilateral handshake to bring the link up?
>
> Frank Rysanek
>
>
> Attachments:
> C:\Users\frr\AppData\Local\Temp\WPM$BQ1R.PM$
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel