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
