Experimental Physics and Industrial Control System
> Are any of the 10G links fiber?
I have tested with 2 different Linux machines. On one of them the link from the Linux machine to the first switch is fiber, on the other it is copper. Both fail the same way. I have also tested 2 different devices that are connected to different 1 Gbit switches with (obviously) different cables. So I don't think it is a defective cable or switch. I would also point out that the problem is not at all random, it is completely deterministic. Each time I send a specific packet I get a frame error on the NIC, which does not sound like collisions to me?
> I suspect that if you were able to eliminate the switches, and connect a 10G NIC directly to the device, things would work.
> Or fail explicitly with no link if auto-negotiation isn't working.
My understanding what you propose is impossible. I have not seen any 10 Gbit copper NICs that support 10 Mbit. They all say they only support 10000/1000/100 Mbit. The same is true for the 10 Gbit switches I have seen. In order to physically connect the device to a 10 Gbit NIC I believe I need at a minimum a 1 Gbit switch.
Have you seen 10 Gbit NICs that can directly connect to a 10 Mbit device?
Thanks,
Mark
________________________________
From: Michael Davidsaver <[email protected]>
Sent: Sunday, January 5, 2020 6:36 PM
To: Mark Rivers
Cc: 'Heinz Junkes'; '[email protected]'
Subject: Re: Ethernet question
On 1/5/20 8:45 AM, Mark Rivers wrote:
>> Your original message mentions a switch. Is this still present? If so, have you checked what link speed is negotiated between this switch an the device?
>
> The switch is always present. The network path from the Linux machine to the device is as follows:
>
> Linux machine (has both 10 Gbit and 1 Gbit NICs)
> |
> 10 Gbit switch #1
> |
> 10 Gbit switch #2
> | (possibly additional 10 Gbit switches in here, I'm not sure)
> |
> 1 Gbit switch
> |
> Device (10 Mbit AUI)
Well, that's far from a simple situation. Are any of the 10G links fiber?
I suspect that if you were able to eliminate the switches, and connect a 10G
NIC directly to the device, things would work. Or fail explicitly with no
link if auto-negotiation isn't working.
> If I use the 1 Gbit NIC on the Linux machine it works fine. That says to me that the speed negotiation between the 1 Gbit switch and the Device must be working. It only fails if I use a 10 Gbit NIC on the Linux machine.
I don't think you can conclude this. And even if it were, this doesn't
eliminate a problem with this last link. All that may be changing with 1G vs. 10G
for the first link is the timing of when frames are sent.
My suspicion falls on the last two links, where the link speed drops from
10G -> 1G and then 1G -> 10M. There is (or should be) buffering happening
here. Also, potentially full -> half-duplex. Which is the only way that
modern switched ethernet can still have collisions. If the final 1G switch
were unmanaged (eg. some cheap netgear) I might suspect it of not handling
collisions correctly, which would account for the checksum violations.
>> Is the AUI from the early 1990 as well? As I recall, an AUI is an active device.
>> So you might have some luck replacing it with something newer (late 90's).
>
> The AUI is working fine if the Linux machine uses a 1 Gbit NIC. The packets between the 1 Gbit switch and the device should be independent of what NIC is used on the Linux machine.
>
>> Beyond this, I'm out of ideas. You might be stuck using an older host to talk to this device. (30 years is a long time to maintain compatibility)
>
> I don't need an older host, I just need to use the 1 Gbit NIC on my modern Linux host. I can dedicate that NIC to this device. It can connect to the same public network with some dummy private IP address, since I will only be using it for this non-IP traffic.
>
> So I don't have a show-stopper problem, but it does require an additional NIC. I would like to understand why a 10 Gbit NIC gives framing errors given the above network topology that is working fine with a 1 Gbit NIC.
Unless you can move remove some/all of the switches, I don't think you'll
be able to isolate the problem further.
FYI, as the checksum field is at the end of a frame, some routers/switches
will forward frames with checksum errors to reduce latency. So I don't think
you can assume that these errors originate on the final link. Though checking
the cabling is always a good idea.
- Replies:
- Re: Ethernet question Michael Davidsaver via Tech-talk
- Re: Ethernet question J. Lewis Muir via Tech-talk
- References:
- RE: Ethernet question Mark Rivers via Tech-talk
- RE: Ethernet question Mark Rivers via Tech-talk
- Re: Ethernet question Michael Davidsaver via Tech-talk
- RE: Ethernet question Mark Rivers via Tech-talk
- Re: Ethernet question Michael Davidsaver via Tech-talk
- Navigate by Date:
- Prev:
Re: Ethernet question Michael Davidsaver via Tech-talk
- Next:
Re:RE: help for streamDevice question 张亚威 via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Ethernet question Michael Davidsaver via Tech-talk
- Next:
Re: Ethernet question Michael Davidsaver via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024