From owner-freebsd-hackers@freebsd.org Mon May 9 19:33:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 299AEB34712 for ; Mon, 9 May 2016 19:33:43 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04C6B1E1C for ; Mon, 9 May 2016 19:33:42 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: by mail-pf0-x22a.google.com with SMTP id 206so79811337pfu.0 for ; Mon, 09 May 2016 12:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackerdojo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RxZDc2Pt4l/NfqKLZLdGR00odZrakmHBhKr00007Wp0=; b=lMXGoTTBBF/Wije2XR+tY++lrhnYZZGWAAVRtBwzRH3DelOY3ym7VS2hf+b/xgdGsl b1oX9QK1DlzOySbWQm1bcPALXzk8XOZNT4P/1d21C2bcpKZhN6ymCpT8DmQoSJS+1vKl dJB29heJTWVli3JOx1CyLo8q3rbQCjrydwtZ9o9+2vod38N7/Yz4IPF8AjaC4GgH16ID WVVOzMVpwMgd2PjaGG5d7u83D/YWBn9iYIFfDt3M6v3JKVgLYWvXXaRoscM2FLt1vEBT ZvGAdbBhrv9AOdNsF04/q/lK2sb6xwv7m/s8B1kjbW8/dZCB/LyQE8plsxBbpJvBAN57 mQ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RxZDc2Pt4l/NfqKLZLdGR00odZrakmHBhKr00007Wp0=; b=Pl6UJJgGHu6ewwFLc3xasO5QaegatLREphinefcaH2GT3z9mnZkUy0qExNH7zwTCjD NJ3zsJyHgQfKunCLrLCM6oTwBV6IzL47fIQzGqt/7TGt0k9rPipikMEAgTJIYRBLsQU0 dGAjgeZ7MdY7wkzyqsCOMFiZrhoV+KLvrqcN+lljDIC4ThTX5K7VXgeTCJy3z3Xi289Z 4pJNTbPTyiU+kttZeUn4VQjaw7hv/dB4HALr09KskG71dCGSIVjzLBzywsIFVB1Hq7KB vp36QBDEdasdLubTbU6CZAbRvld3cRcELsRNvnp3uVzr5ahvfnTfc+r6EfiIu5fHbzKb M2qQ== X-Gm-Message-State: AOPr4FWNh8m75M07HTyzVWADqTaQcVPddaxmM9E6c+TUJKWQrRKsvH5GYX+q8O9IXeh7cKSy X-Received: by 10.98.95.71 with SMTP id t68mr48763220pfb.158.1462822421873; Mon, 09 May 2016 12:33:41 -0700 (PDT) Received: from ?IPv6:2601:647:4204:2b00:528:4042:cb2a:9e77? ([2601:647:4204:2b00:528:4042:cb2a:9e77]) by smtp.gmail.com with ESMTPSA id h16sm40766351pfj.0.2016.05.09.12.33.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2016 12:33:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: TCP problems From: Larry Maloney X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Mon, 9 May 2016 12:33:38 -0700 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3754545C-B66D-4D40-BC92-FF1BA3D8B25D@hackerdojo.com> References: To: Dieter BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:33:43 -0000 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 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: 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"=