Date: Mon, 9 May 2016 12:33:38 -0700 From: Larry Maloney <larry.maloney@hackerdojo.com> To: Dieter BSD <dieterbsd@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: TCP problems Message-ID: <3754545C-B66D-4D40-BC92-FF1BA3D8B25D@hackerdojo.com> In-Reply-To: <CAA3ZYrCAiqzFWX24qXWJbSPaWEbuv5mG3xH%2B4bk7ZDEXtaod2Q@mail.gmail.com> References: <CAA3ZYrCAiqzFWX24qXWJbSPaWEbuv5mG3xH%2B4bk7ZDEXtaod2Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Can you do a sysctl dump for each NIC to see their settings? /Larry Sent from my iPhone > On May 9, 2016, at 11:49 AM, Dieter BSD <dieterbsd@gmail.com> wrote: >=20 > Larry suggests: >> Have you tried bumping the MTU on the interfaces to JUMBO frames? >> 9000 or whatever max is? >=20 > Easy enough to try, but 2 of the 4 max out at 1500. I suppose I > could rewire the networks to get the 2 that allow 9000 on the > same wire. But packet size seems unlikely to have anything to do > with bind failing. And MTU=3D1500 is really supposed to work. >=20 > I set ue0 to *smaller* mtu (500, 250, 100) and still got data corruption, > along with > rcp: lost connection > Data connection: Operation timed out. (ftp) >=20 > More on ue0's MTU below. >=20 > Mark suggests: >> Sounds like you may have fired the nic on the G box >=20 > Which is why I tried both networks. Seems unlikely that both > re0 *and* ue0 would fail with the same symptoms. Seems unlikely > that bad nics would have anything to do with bind failing? >=20 > Thank you both for your suggestions. > ------------------- > re0: >=20 > New problem. One network got some strange ping times for awhile: >=20 > 64 bytes from machine_G_re0: icmp_seq=3D2 ttl=3D64 time=3D0.355 ms > 64 bytes from machine_G_re0: icmp_seq=3D3 ttl=3D64 time=3D2001.209 ms > 64 bytes from machine_G_re0: icmp_seq=3D4 ttl=3D64 time=3D2001.219 ms > 64 bytes from machine_G_re0: icmp_seq=3D5 ttl=3D64 time=3D1000.728 ms > 64 bytes from machine_G_re0: icmp_seq=3D6 ttl=3D64 time=3D0.229 ms > 64 bytes from machine_G_re0: icmp_seq=3D7 ttl=3D64 time=3D2001.091 ms > 64 bytes from machine_G_re0: icmp_seq=3D8 ttl=3D64 time=3D2001.129 ms > 64 bytes from machine_G_re0: icmp_seq=3D9 ttl=3D64 time=3D1000.643 ms > 64 bytes from machine_G_re0: icmp_seq=3D10 ttl=3D64 time=3D0.149 ms > 64 bytes from machine_G_re0: icmp_seq=3D11 ttl=3D64 time=3D2001.207 ms > 64 bytes from machine_G_re0: icmp_seq=3D12 ttl=3D64 time=3D2001.211 ms > 64 bytes from machine_G_re0: icmp_seq=3D13 ttl=3D64 time=3D1000.726 ms >=20 > 64 bytes from machine_T_bge0: icmp_seq=3D0 ttl=3D64 time=3D423.415 ms > 64 bytes from machine_T_bge0: icmp_seq=3D1 ttl=3D64 time=3D14491.793 ms > 64 bytes from machine_T_bge0: icmp_seq=3D2 ttl=3D64 time=3D13490.387 ms > 64 bytes from machine_T_bge0: icmp_seq=3D3 ttl=3D64 time=3D12489.373 ms > 64 bytes from machine_T_bge0: icmp_seq=3D4 ttl=3D64 time=3D11488.635 ms > 64 bytes from machine_T_bge0: icmp_seq=3D5 ttl=3D64 time=3D10487.481 ms > 64 bytes from machine_T_bge0: icmp_seq=3D6 ttl=3D64 time=3D9486.493 ms > 64 bytes from machine_T_bge0: icmp_seq=3D7 ttl=3D64 time=3D8485.567 ms >=20 > Powered machine G down overnight and re0 mostly recovered. > Still have the bind problem. Does bind have anything to do > with the Ethernet hardware or device drivers? I'm guessing no. >=20 > No clue as to why re0 was causing data corruption, or why the > data corruption went away (that problem went away before the power down > so it isn't that). Also no clue about what caused the long ping times, > which went away after the power down. >=20 > ------------------- > ue0: >=20 > Noticed that netstat was reporting input errors for ue0. > And ue0 input was where the data corruption was happening. > Sent data from machine A with 10Mbps Ethernet. Netstat > did not report any input errors on ue0 and there was no data > corruption. >=20 > So ue0 can handle gigabit data rate, but gets input errors if > packets arrive too frequently. >=20 > # ifconfig ue0 media 100baseTX-FDX > fixed the input error problem and the data corruption problem, > at the expense of making it even slower. >=20 > Max data rate seen (before lowering to 100Mbps) was about 35 MB/s > which is said to be the effective rate of USB2. >=20 > usbconfig says: > ugen0.3: <AX88179 ASIX Elec. Corp.> at usbus0, cfg=3D0 md=3DHOST spd=3DSUP= ER > (5.0Gbps) pwr=3DON (124mA) >=20 > so I guess it really is running at USB3 speed. >=20 > The chip performs a lot better for tweaktown: > http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-netw= ork-adapter-review/index.html > (Vantec CB-U300GNA with the same Asix AX88179 chip) > "full duplex gigabit with 952 Mbps consistently across the chart" >=20 > Asix AX88179 chip: > http://www.asix.com.tw/products.php?op=3DpItemdetail&PItemID=3D131;71;112 > "Supports Jumbo frame up to 4KB" >=20 > But ifconfig rejects any value > 1500: >=20 > # ifconfig ue0 mtu 4000 > ifconfig: ioctl (set mtu): Invalid argument > # ifconfig ue0 mtu 1501 > ifconfig: ioctl (set mtu): Invalid argument >=20 > A quick look at the driver code didn't find a MTU limit. (But did in othe= r > Ethernet drivers.) Looks to me like axge(4) doesn't support a large MTU. >=20 > IIRC, one should set ifconfig -rxcsum -txcsum to get maximum data > integrity (at the expense of using more cpu). If the cpu were doing > the checksums it should catch and correct the data corruption I'm > getting since the corruption appears to be happening inside the > Asix AX88179 chip. But: >=20 > # ifconfig ue0 -rxcsum > results in no Ethernet traffic > # ifconfig ue0 -txcsum > seems to work ok. (including no data corruption) >=20 > Why am I not getting any Ethernet traffic with -rxcsum? I can see that > some controllers might not have the hardware to support rxcsum, but it > seems to me that -rxcsum and -txcsum should always work? >=20 > # ifconfig re0 -rxcsum -txcsum > seems to work ok. (including no data corruption) >=20 > Is Asix AX88179 still the only USB to gigabit Ethernet chip? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3754545C-B66D-4D40-BC92-FF1BA3D8B25D>