[I figured out how it appeared to go faster than USB2.] On 2020-Jul-27, at 20:07, Mark Millard <marklmi_at_yahoo.com> wrote: > On 2020-Jul-27, at 19:07, Mark Millard <marklmi at yahoo.com> wrote: > >> On 2020-Jul-27, at 18:44, John-Mark Gurney <jmg at funkthat.com> wrote: >> >>> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: >>>> On 2020-Jul-27, at 16:43, Mark Millard <marklmi at yahoo.com> wrote: >>>> >>>>> On 2020-Jul-26, at 18:20, John-Mark Gurney <jmg at funkthat.com> wrote: >>>>> >>>>>> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >>>>>>> For reference for what applying the patch >>>>>>> reported (see Hunk #14): >>>>>> >>>>>> Ok, updated it to be relative to r363583... >>>>>> >>>>>> I had made a white spcae commit to if_ure.c, but hadn't made the >>>>>> patch relative to it after that commit.. should work now.. >>>>> >>>>> I updated an old PowerMac G5 (2 sockets/2 cores each) to >>>>> head -r363590 with the update patch and tjen plugged in the >>>>> USB EtherNet device. The result (extracted from dmesg -a) >>>>> was: >>>>> >>>>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT >>>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) >>>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT >>>>> ugen2.2: <Unknown > at usbus2 (disconnected) >>>>> uhub_reattach_port: could not allocate new device >>>>> >>>>> Unfortunately, I'd not tried a PowerMac with the type of >>>>> device before the update. I do not know if the above is >>>>> new behavior or not. >>>>> >>>>> The PowerMac is big-endian, which is what got me to think >>>>> about trying it there. The PowerMac is also 64-bit running >>>>> a 64-bit FreeBSD. Its USB is 2.0. >>>>> >>>>> (It also has 2 GigaBit EtherNet ports of its own so I'm not >>>>> likely to use a USB device outside special testing.) >>>>> >>>> >>>> I tried what normally shows as an axge0, but >>>> trying on the PowerMac G5. It got the same sort >>>> of messages as above. The problem does not seem >>>> to be tied to your patch. >>>> >>>> It does prevent my testing the patch on the G5. >>> >>> Yeah, I was going to say that the above messages are before any of >>> may changes get run, so it's unlikely a problem w/ my patch... >>> If the USB device can't get an address on the bus, then it can't >>> even ask what type of device it is to load the driver. >>> >>> Thanks for trying though, maybe someone on the -powerpc list knows >>> of a fix for that. >>> >> >> Turns out that having: >> >> hw.usb.xhci.use_polling=1 >> >> in /boot/loader.conf allowed the old PowerMac context to >> get: >> >> ugen2.2: <Realtek USB 10/100/1000 LAN> at usbus2 >> ure0 numa-domain 0 on uhub2 >> ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 2.10/30.00, addr 2> on usbus2 >> miibus2: <MII bus> numa-domain 0 on ure0 >> rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus2 >> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto >> ue0: <USB Ethernet> on ure0 >> ue0: Ethernet address: ### >> ue0: link state changed to DOWN >> >> and: >> >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 >> options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> >> ether ### >> inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (1000baseT <full-duplex>) >> status: active >> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >> >> So, with that context, . . . >> (the two directions are widely mismatched) >> >> . . . > > The above is very odd for USB2 since USB2 is limited to > 480Mbits/sec, if I understand right. May be it is a mode > of use that is not getting data to send from USB > regularly at all, say internally generated data or > constant/repeated data only loaded from USB once? > > If yes, then comparing to receiving is not useful and > it need not be useful for comparing to data that does > come from USB transfers. > > I suppose another possibility is that it is an error > that it appears to be going as fast as it appears > above. I isolated the problem: it was not really using 192.168.1.149, but instead 192.168.1.145 (the builtin bge0). This is despite the -N and what the output reported. FYI: bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> ### inet 192.168.1.145 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> ### inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> After using: # ifconfig bge0 down things behaved with speeds that USB2 can handle: # iperf3 -c 192.168.1.120 -B 192.168.1.149 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.149 port 62507 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 15.9 MBytes 133 Mbits/sec 2 115 KBytes [ 5] 1.00-2.00 sec 15.6 MBytes 131 Mbits/sec 4 111 KBytes [ 5] 2.00-3.00 sec 15.7 MBytes 131 Mbits/sec 4 101 KBytes [ 5] 3.00-4.00 sec 15.6 MBytes 131 Mbits/sec 5 84.1 KBytes [ 5] 4.00-5.00 sec 15.6 MBytes 131 Mbits/sec 3 62.7 KBytes [ 5] 5.00-6.00 sec 15.7 MBytes 131 Mbits/sec 5 39.9 KBytes [ 5] 6.00-7.00 sec 15.7 MBytes 131 Mbits/sec 5 34.2 KBytes [ 5] 7.00-8.00 sec 15.7 MBytes 131 Mbits/sec 3 9.98 KBytes [ 5] 8.00-9.00 sec 15.6 MBytes 131 Mbits/sec 4 15.7 KBytes [ 5] 9.00-10.00 sec 15.6 MBytes 131 Mbits/sec 4 123 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 157 MBytes 131 Mbits/sec 39 sender [ 5] 0.00-10.98 sec 157 MBytes 120 Mbits/sec receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.149, port 42844 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.149 port 62507 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 424 KBytes 3.48 Mbits/sec [ 5] 1.00-2.00 sec 15.7 MBytes 131 Mbits/sec [ 5] 2.00-3.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 3.00-4.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 4.00-5.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 5.00-6.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 6.00-7.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 7.00-8.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 8.00-9.00 sec 15.7 MBytes 131 Mbits/sec [ 5] 9.00-10.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 10.00-10.98 sec 15.3 MBytes 131 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate And: # iperf3 -R -c 192.168.1.120 -B 192.168.1.149 --get-server-output Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.149 port 61744 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 13.7 MBytes 115 Mbits/sec [ 5] 1.00-2.00 sec 13.5 MBytes 114 Mbits/sec [ 5] 2.00-3.00 sec 13.5 MBytes 114 Mbits/sec [ 5] 3.00-4.00 sec 13.5 MBytes 113 Mbits/sec [ 5] 4.00-5.00 sec 13.6 MBytes 114 Mbits/sec [ 5] 5.00-6.00 sec 13.5 MBytes 113 Mbits/sec [ 5] 6.00-7.00 sec 13.5 MBytes 113 Mbits/sec [ 5] 7.00-8.00 sec 13.5 MBytes 113 Mbits/sec [ 5] 8.00-9.00 sec 13.5 MBytes 113 Mbits/sec [ 5] 9.00-10.00 sec 13.4 MBytes 113 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.84 sec 135 MBytes 105 Mbits/sec 12652 sender [ 5] 0.00-10.00 sec 135 MBytes 113 Mbits/sec receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.149, port 12490 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.149 port 61744 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.25 MBytes 18.9 Mbits/sec 186 30.1 KBytes [ 5] 1.00-2.00 sec 13.7 MBytes 115 Mbits/sec 1242 34.4 KBytes [ 5] 2.00-3.00 sec 13.5 MBytes 113 Mbits/sec 1291 27.3 KBytes [ 5] 3.00-4.00 sec 13.5 MBytes 114 Mbits/sec 1242 34.5 KBytes [ 5] 4.00-5.00 sec 13.5 MBytes 113 Mbits/sec 1302 25.8 KBytes [ 5] 5.00-6.00 sec 13.6 MBytes 114 Mbits/sec 1249 27.3 KBytes [ 5] 6.00-7.00 sec 13.4 MBytes 113 Mbits/sec 1285 21.6 KBytes [ 5] 7.00-8.00 sec 13.5 MBytes 113 Mbits/sec 1238 33.0 KBytes [ 5] 8.00-9.00 sec 13.6 MBytes 114 Mbits/sec 1260 31.6 KBytes [ 5] 9.00-10.00 sec 13.5 MBytes 113 Mbits/sec 1256 25.9 KBytes [ 5] 10.00-10.84 sec 11.3 MBytes 112 Mbits/sec 1101 18.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.84 sec 135 MBytes 105 Mbits/sec 12652 sender iperf Done. So do not necessarily believe the -B IP-ADDR or local IP-ADDR reporting if there is an alternative active, at least for sending data. >> . . . >> >> Very asymmetric: send relatively fast, receive relatively slow. Not after the above problem avoidance: now both relatively slow for hw.usb.xhci.use_polling=1 use. >> I've not tried hw.usb.xhci.use_polling=1 in any other context. So, >> for all I know, the results of using such could be expected. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Tue Jul 28 2020 - 02:01:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC