From owner-freebsd-hackers@freebsd.org Mon May 9 19:35:19 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 C8528B34839 for ; Mon, 9 May 2016 19:35:19 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 99F5D1F73 for ; Mon, 9 May 2016 19:35:19 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: by mail-pa0-x22c.google.com with SMTP id bt5so75254493pac.3 for ; Mon, 09 May 2016 12:35:19 -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=wK/D/qa+M4HHRlZuWDbg9XbmIHNRbqZs5jd/IWFqy2g=; b=wIFEW2E37RwKQGoVyLHsj1PalBOaJT+jrePS9/S1GPHTBIwY5tzM9xAIw+xjkMwQnA sZrTYF6GbQZ7G6YleT/SsA7CeQpaHykNYgi8eXcSiZ0KSNH95viJ7r36rGeL2329LiOJ iFkFPV2GpKp3po/5SMuU+55h2kaBItJe2kVnfKIPxDXT1ABJV4r8BP+FNLcc450Tmk7T x5LMlC7ipHma6jJu2spMaxsC2yhWhR43RiHuFpMvgzFS4hDRvo+upqXueehGJNpilKB6 PB9esQWTDY+QGU9JEJ019sQzRHqD5WMCTECiYrJO1BCn/Ee4Awl1gmLJLNCT2esB0eQe sN2A== 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=wK/D/qa+M4HHRlZuWDbg9XbmIHNRbqZs5jd/IWFqy2g=; b=jh8Jn6ItAKI3UiqRB6znSvNxaqMOUwvRmCeDVwAA5FwN55L9G60jCBi6sSZn0sN6Gm jp8cSkhLBver4wo2TiTiplvStsmnKu+UHO54GWqrB7ezVxFtJpeG4NjlFpRlQSic2E2x 6hu/IlzEjQjd6PryDvKnA3RK7B85X2e9Mdhx4We0GJRZpeo9fg8siaaXADHo/eyQ64P2 2F9w9O6tFt+8PYnOCZJOCcxiO4qs2hMtyTWDDSwn3v+qKw1OPP8UJP3CWfe+EuT/8Lxw h6NyKzAhjDJC3oFJ7PFBKmKaRE7zTyxFeCZQ9htaiowNM45AtZnj0JmMn0GT/zzB3EL4 iXAA== X-Gm-Message-State: AOPr4FWO69wqcJZtkSx93fGaCtHD1+5znMRlmJPimlA4WAEUejnWtaMQlFXn/ZnOp41ZDgRy X-Received: by 10.66.65.133 with SMTP id x5mr53120425pas.108.1462822519244; Mon, 09 May 2016 12:35:19 -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 h16sm40770948pfj.0.2016.05.09.12.35.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2016 12:35:17 -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:35:16 -0700 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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:35:19 -0000 Keep in mind, if you are going through a switch, you may need to bump the sw= itch's MTU too if you want to try jumbo frames. Are these machines direct connected? /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"=