From owner-freebsd-net@freebsd.org Tue Apr 10 22:55:00 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AB20FA0C43; Tue, 10 Apr 2018 22:55:00 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 E51D8768C1; Tue, 10 Apr 2018 22:54:59 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-io0-x242.google.com with SMTP id 141so267359iou.12; Tue, 10 Apr 2018 15:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=g8umbL33JS4JMhFOtXihytGs1MPURHhV0U1dPQO1+1w=; b=PgtnKbfrJWtgc5gFg9ZM+xypbtqwBqoPnGuUmBRCMFI1YoLiYF22vdXhhBEfGYEw6E Hwncpu6scW5gYuCevrEsm/HFBKgWjjUiDIPRDWnZ4DdMgCTjwvOJa/BZcSN8nRP8cbGX qo/M55wB0HvWVzzaX1C4d85MG+S+YspToZfX1SOAtcMTGydmGgRWjpKq1keKkw5z4LwW yES4vgbLeP6DbUyIGSvuRaJEnwyUOJaTrHt1+0+7LSYWWs7B5xrlath/SamB6bfA1O0/ BQtUrNr0+2I68GET7sIXma9YmWbTkmDZrSGdpegyqXgAeWXV1lWUqS7BElOFGk/HR0kd ewNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=g8umbL33JS4JMhFOtXihytGs1MPURHhV0U1dPQO1+1w=; b=gqPCLOtk+hXxuFh8F5zkw997KSP1fyiZ5je/liGyH9WAmOL4urtXXE5VAljrh5E6Pn 4Mte70+J9y4fK01S5hPEHx2ru6mTNYZrqypE+KKOUgC08A5Bz8qdwVeDdt5QJZve/L7a 08fgzMiSC9p4ku3C/CstatLO6JUgZMiU5e2td5Jo3bB3HUdGL6wtZilGWpSlvz523roQ W5Gg43b7oK4hv/S7PRO4c3VSTuhCZJtzvpxMZfoeLzWBI9ixV7L+aiymKQ6f5QBMag6l 09USs56vKvl9Ftvkr3tAQ3AySMjyMyv9P9TjsI7/LV8/t7NV80NTMnyTP81EFn8GiIKK Ydig== X-Gm-Message-State: ALQs6tCeAUptuoNk8MUG/8s22Fk/tzBFqc23Y/g+MSnTrme8rMhQSf1v YQHmu1UxtT6T3ZQ1hm0U8U3rV6K+vyLpUHp1XVg= X-Google-Smtp-Source: AIpwx49b56snKnBLOm9G8UeLhwQsi6yZfRa0YensdI0kYroj8e1y9NcH4URvtU0hynNigyLnQV5tjS7OAL/1wfZ091s= X-Received: by 10.107.146.136 with SMTP id u130mr2324773iod.96.1523400899098; Tue, 10 Apr 2018 15:54:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.173 with HTTP; Tue, 10 Apr 2018 15:54:58 -0700 (PDT) From: Dieter BSD Date: Tue, 10 Apr 2018 15:54:58 -0700 Message-ID: Subject: AX88179 USB-to-Ethernet is slow and silently corrupts data To: freebsd-usb@freebsd.org, freebsd-net@freebsd.org Cc: freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 22:55:00 -0000 10.3-RELEASE amd64 with ECC memory VIA VL805 USB 3.0 controller ue0 is Siig USB-to-Ethernet Chipset: AX88179 ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA) ue0: flags=8c43 metric 0 mtu 1500 options=8000b inet 10.0.210.66 netmask 0xffffff00 broadcast 10.0.210.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active If media is set to "1000baseT " 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) Previously (2016 May): # ifconfig ue0 media 100baseTX-FDX fixed the input error problem and the data corruption problem, at the expense of making it even slower. Sent data from machine A with 10Mbps Ethernet. (Netgear Ethernet switch converts 10Mbps to 1000Mbps) Netstat did not report any input errors on ue0 and there was no data corruption. So ue0 can handle gigabit data rate, but gets input errors if packets arrive too frequently. I tried moving it to a USB-2 port. No data corruption, but USB-2 is slow. The chip performs a lot better for tweaktown: http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-network-adapter-review/index.html (Vantec CB-U300GNA with the same Asix AX88179 chip) "full duplex gigabit with 952 Mbps consistently across the chart" http://www.vantecusa.com/products_detail.php?p_id=143&p_name=USB+3.0+Gigabit+Ethernet+Adapter&pc_id=21&pc_name=Network&pt_id=5&pt_name=Accessories Asix AX88179 chip: http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112 "Supports Jumbo frame up to 4KB" But ifconfig rejects any value > 1500: ifconfig ue0 mtu 1501 ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument I tried mtu of 100, 500, 1000, 1400 but they all give rcp: lost connection USB disks are fast, so the USB controller seems to work ok. I also tried a Tek Republic TUN-300 which has the same AX88179, and it acts the same as the Siig. So, transmit works, but is slow. Receive works if the amount of traffic is low enough (limit rate of data sent, limit Ethernet speed, or use USB-2). But if data is received too fast it gets silently corrupted. Setting -rxcsum does not work, and cannot set mtu other than 1500. Questions: Why does -rxcsum not work? Why does attempting to set a larger mtu fail? Why does setting a smaller mtu make rcp fail? Why is the chip acting slow? How do I get it to work properly? (fast and without data corruption)