Date: Thu, 3 May 2018 14:11:24 -0700 From: Dieter BSD <dieterbsd@gmail.com> To: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: AX88179 USB-to-Ethernet is slow and silently corrupts data Message-ID: <CAA3ZYrAtvVxx1Ub22_mKBhV0T0YJJNLcBjNq0L7JfXNFOb3d5g@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
> 10.3-RELEASE
> amd64 with ECC memory
> VIA VL805 USB 3.0 controller
> ue0 is Siig USB-to-Ethernet Chipset: AX88179
>
> ugen0.7: <AX88179 ASIX Elec. Corp.> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (124mA)
>
> ue0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> metric 0
> mtu 1500
> options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
> inet 10.0.210.66 netmask 0xffffff00 broadcast 10.0.210.255
> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> media: Ethernet autoselect (1000baseT <full-duplex>)
> status: active
>
> If media is set to "1000baseT <full-duplex>" it "works", but slowly, and
> received data is silently corrupted. :-( Transmitted data is not
> corrupted (tested with > 30 GB).
>
> ifconfig ue0 -txcsum
> "works", but still gives silent data corruption
>
> ifconfig ue0 -rxcsum (acts the same with or without txcsum)
> ping out
> netstat sees packets both directions, but ping doesn't see the response:
> 8 packets transmitted, 0 packets received, 100.0% packet loss
> ping in
> netstat sees packets in, but no responses going out
>
> I can see that some Ethernet controllers would not support checksum offloading,
> but it seems to me that turning the checksum offloading off should always
> work? (at the expense of more cpu load)
pyunyh> Which phy driver is used for axge(4)?
pyunyh> You can see the phy driver name below axge(4) attachment in dmesg
pyunyh> output.
axge0: <NetworkInterface> on usbus2
axge1: <NetworkInterface> on usbus0
miibus4: <MII bus>
on axge0
miibus5: <MII bus> on axge1
- Do you use manual media configuration instead of auto-negotiation?
They auto configure at 1000. I usually set them to 100 which seems to
eliminate the silent data corruption.
pyunyh> Does the issue happen at which media speed(10Mbps, 100Mbps or
1000Mbs)?
The silent data corruption happens at 1000. 100 seems to eliminate
the data corruption but 100 isn't always fast enough. I haven't tried
setting the AX88179 to 10 Mbps mode, although I tested it by sending
data to it from another machine whioh was running at 10 Mbps, with
a Netgear switch converting the 10 Mbps to 1000 Mbps. Using usb2 instead
of usb3 also seems to eliminate the date corruption. The AX88179
doesn't seem to care about what Ethernet speed it is running at, or
what usb speed it is running at. The silent data corruption happens
if it receives too many packets per second from the Ethernet. Reducing
Ethernet speed or usb speed are simple ways to reduce how many packets
per second it handles.
pyunyh> Which direction of packet flow is broken(TX or RX or both)?
The silent data corruption happens if it receives too many packets
per second from the Ethernet.
I have not observed any data corruption when the AX88179 transmits
data to the Ethernet. Tested with rcp(1).
It seems interesting that it is the receive direction that gets data
corruption and the receive direction that fails completely when the
rxcsum is turned off. Perhaps related?
ue0 is now connected to chipset (AMD 990FX SB950) usb controller usb2
ifconfig ue0 -rxcsum
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8000a<TXCSUM,VLAN_MTU,LINKSTATE>
media: Ethernet 100baseTX <full-duplex>
Sent ue0 a bunch of udp packets from another FreeBSD box.
dd if=/dev/zero bs=1k count=50 | nc -4u 10.0.210.66 55555
input ue0 output
packets errs idrops bytes packets errs bytes colls drops
0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
50 0 0 53000 0 0 0 0 0
0 0 0 0 0 0 0 0 0
Receiving process got none of them.
nc -4nul 55555 > /var/tmp/file_via_udp_ue0
(file is zero bytes)
netstat -s -p udp
udp:
0 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
0 with no checksum
0 dropped due to no socket
0 broadcast/multicast datagrams undelivered
0 dropped due to full socket buffers
0 not for hashed pcb
0 delivered
0 datagrams output
0 times multicast source filter matched
So netstat sees packets coming in, but does not see any datagrams.
Where is the data disappearing? In the hardware? In the device driver?
Is "ifconfig -rxcsum" really doing the correct thing to the chip?
Is there some way to have RXCSUM,TXCSUM turned on, but also have the cpu
verify the checksum? I realize the the whole point of RXCSUM,TXCSUM
is to reduce the load on the cpu, but data corruption sucks.
To see if a different usb controller made any difference, I ran the same
test using ue1 = Tek Republic TUN-300 which has the same AX88179 as the Siig,
connected to onboard VIA VL805 USB 3.0 controller, and it acts exactly the
same as the Siig. So no difference seen between the two usb controllers.
Both ue0 & ue1 are running at 100baseTX <full-duplex> which appears
to eliminate the silent data corruption seen with rcp(1) when they
are running at 1000.
I also tried the same test with tcp instead of udp. Same results,
zero length file and no checksum errors reported by netstat -s.
So the protocol doesn't matter. "ifconfig -rxcsum" appears
to stop the flow of all incoming packets, icmp. udp, and tcp.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA3ZYrAtvVxx1Ub22_mKBhV0T0YJJNLcBjNq0L7JfXNFOb3d5g>