( 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
WPM$BQ1R.PM$
Description: Mail message body
------------------------------------------------------------------------------ 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
