Slow umass(4) on xhci(4)
I observe ~90x difference in bandwidth between Linux and OpenBSD on the same hardware. The test case is reading big files from a USB-attached flash drive[0]. The drive is plugged into a sole USB-c port on the back of the motherboard. On Linux I get about 900MB/s. OpenBSD shows ~10MB/s: # dd if=/dev/sd1i of=/dev/null bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 95.617 secs (10966340 bytes/sec) While a transfer is going, I can see consistently slow performance: % iostat 1 ttycd0 sd0 sd1 cpu tin tout KB/t t/sMB/s KB/t t/sMB/s KB/t t/sMB/s us ni sy sp in id 3 397 0.0000.00 19.43 781.47 4.00 3191.24 0 0 0 0 0 99 2 264 0.0000.00 0.0000.00 4.00 2679 10.47 0 0 0 0 1 99 0 88 0.0000.00 0.0000.00 4.00 2683 10.48 0 0 1 0 0 99 0 88 0.0000.00 16.0040.06 4.00 2683 10.48 0 0 1 0 1 98 0 89 0.0000.00 0.0000.00 4.00 2710 10.59 0 0 0 0 0100 0 87 0.0000.00 0.0000.00 4.00 2657 10.38 0 0 1 0 1 98 0 88 0.0000.00 64.0010.06 4.00 2683 10.48 0 0 0 0 1 99 Is 4K/t typical/normal for USB drives? systat shows consistent interrupt rate: 1006 xhci0 The devices details from usbdevs: Controller /dev/usb0: addr 01: 1022: AMD, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub0 addr 02: 2109:2812 VIA Labs, Inc., USB2.0 Hub high speed, self powered, config 1, rev b.e0 driver: uhub4 addr 03: 045e:0040 Microsoft, Microsoft 3-Button Mouse with IntelliEye(TM) low speed, power 100 mA, config 1, rev 3.00 driver: uhidev0 addr 04: 29ea:0102 Kinesis, Advantage2 Keyboard full speed, power 100 mA, config 1, rev 1.00, iSerial driver: uhidev1 driver: uhidev2 driver: uhidev3 addr 05: 0bda:8153 Realtek, USB 10/100/1000 LAN high speed, power 180 mA, config 1, rev 30.00, iSerial 0100 driver: ure0 addr 06: 1050:0200 Yubico, Yubico Gnubby (gnubby1) full speed, power 30 mA, config 1, rev 0.97 driver: uhidev4 addr 07: 1058:264f Western Digital, My Passport 264F super speed, power 224 mA, config 1, rev 20.07, iSerial driver: umass0 Controller /dev/usb1: addr 01: 1022: AMD, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub1 Controller /dev/usb2: addr 01: 1022: AMD, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub2 Controller /dev/usb3: addr 01: 1022: AMD, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub3 lsusb on Linux lists more stuff (followed by dmesgs at the end): Bus 003 Device 003: ID 1058:264f Western Digital Technologies, Inc. My Passport 264F Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x1058 Western Digital Technologies, Inc. idProduct 0x264f bcdDevice 20.07 iManufacturer 2 Western Digital iProduct3 My Passport 264F iSerial 1 xxx bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0079 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 896mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface
Re: Firefox and stuttering USB audio
TFW your software is so complicated it might as well be proprietary. I'll be sticking with Firefox ESR for now and hope by the time the time the ESR version bumps this will be resolved. Otherwise I'll have to play the worlds smallest violin. ESR doesn't have the issue. On 6/1/22 16:02, Raul Miller wrote: On Wed, Jun 1, 2022 at 6:13 PM Mihai Popescu wrote: I am not able to understand why a simple application like mpv for example is able to play videos and streams at high resolutions with good performance, but a "browser" needs 10 times the CPU cores and memory and it still does it wrong enough to annoy users. If you look at the build details for chromium: It's layers and layers of indirection where no one really understands how the browser works.
Re: pkg_add in -current
Stuart Henderson wrote: > On 2022/06/04 15:23, Theo de Raadt wrote: > > Stuart Henderson wrote: > > > > > If you are running -current and have not updated base recently, you > > > may run inTO "pkg_add: Unknown option: always-update ". > > > To fix it, just update to a newer base snapshot. > > > > > > > > What happened is that a developer made a change to the pkg tools which > > creates completely incompatible package files. > > > > Noone knew this was happening beforehands. An email was circulated > > after-the-fact to ports@ list (which is mostly read by developers, and > > not read by users). It has now been weeks, and it still hasn't been > > clearly communicated. > > People can decide for themselves about that, > > First commit enabling parsing in pkg_add > https://github.com/openbsd/src/commit/5cb7aebf4211294fd2891b0bc45c383ab7fd66af That commit message does not say: There will be no backwards compatiblity. > "REMINDER: snapshots go with -current" > https://marc.info/?l=openbsd-ports=165355109123377=2 That message says: There is zero effort being made for backwards compatiblity. It also says it is going to be FUN. Are we having fun? We are not having fun. This is the case of one developer (who did not even explain what was happening to any non-ports developer) making a decision in their own bubble, without communicating the impact in a way that everyone can understand. > Second commit, after base is updated with this subsequent package builds > use the new annotation > https://github.com/openbsd/src/commit/c2e596a17ac45689d758df0d67597fef94480ebe That commit message does not say: No effort has been made for backwards compatibility. > (Then it takes time for new packages to be built on the various archs > and it's not until *then* that errors would show up for people who > haven't updated base yet) So here we are: There is no backwards compatibility, and users are starting to encounter the problem, and the answer for them is that they must reboot. No it's not just that, they are being told the PROCESS WAS GREAT, and what is wrong here is *THEIR* process of using snapshots. It has also been pointed out that current.html has no information about this change. I have been saying for a while we should delete current.html because it seems to always contain useless information, and here we see it lacks crucial information.
Re: pkg_add in -current
On 2022/06/04 15:23, Theo de Raadt wrote: > Stuart Henderson wrote: > > > If you are running -current and have not updated base recently, you > > may run inTO "pkg_add: Unknown option: always-update ". > > To fix it, just update to a newer base snapshot. > > > > What happened is that a developer made a change to the pkg tools which > creates completely incompatible package files. > > Noone knew this was happening beforehands. An email was circulated > after-the-fact to ports@ list (which is mostly read by developers, and > not read by users). It has now been weeks, and it still hasn't been > clearly communicated. People can decide for themselves about that, First commit enabling parsing in pkg_add https://github.com/openbsd/src/commit/5cb7aebf4211294fd2891b0bc45c383ab7fd66af "REMINDER: snapshots go with -current" https://marc.info/?l=openbsd-ports=165355109123377=2 Second commit, after base is updated with this subsequent package builds use the new annotation https://github.com/openbsd/src/commit/c2e596a17ac45689d758df0d67597fef94480ebe (Then it takes time for new packages to be built on the various archs and it's not until *then* that errors would show up for people who haven't updated base yet)
Re: reminder: ports snapshots go with base snapshots
That Subject is incorrect. Unless pkg_add is going to start doing a stat() of /bin/cat and demanding you run sysupgrade INCLUDING THE REBOOT if the file is more than a day old? or is it two days? Or is it a week? What has happened for years now is that if you attempt to upgrade an old base snapshot with new packages, you get nice messages which tell you what libraries are incompatible, and then you it is clear to everyone what is going on and they take the correct action. But I guess your real message here is the library checking code in pkg_add can be deleted, because telling everyone "you must have upgraded to a new snapshot INCLUDING THE REBOOT" is the new way, so why check libraries?!! they will always have the new libraries, because you are saying that is the ONLY RIGHT WAY. You are wrong. We will not demand that people aggressively jump to new snapshots. Look, you failed to communicate with the developers ahead of time and then you failed to communicate with the users _after the fact_, and it required complaints on public and developer forums before you acted by telling people their process is broken. No, sorry, you are incorrect blaming users for not updating to new snapshots. What is wrong here is your development process. Marc Espie wrote: > If you don't update base first (as you should always do), > recent package snapshots will break. > > Code to parse the hash after > @option always-update > was added on May 26. > > Package snapshots built after May 28 use that new syntax. > > You will notice fairly early, as quirks uses > @option always-update > > the new package will refuse to install with an error > from the packing-list parsing code: > > "Unknown option: always-update " >
reminder: ports snapshots go with base snapshots
If you don't update base first (as you should always do), recent package snapshots will break. Code to parse the hash after @option always-update was added on May 26. Package snapshots built after May 28 use that new syntax. You will notice fairly early, as quirks uses @option always-update the new package will refuse to install with an error from the packing-list parsing code: "Unknown option: always-update "
Re: pkg_add in -current
Stuart Henderson wrote: > If you are running -current and have not updated base recently, you > may run inTO "pkg_add: Unknown option: always-update ". > To fix it, just update to a newer base snapshot. What happened is that a developer made a change to the pkg tools which creates completely incompatible package files. Noone knew this was happening beforehands. An email was circulated after-the-fact to ports@ list (which is mostly read by developers, and not read by users). It has now been weeks, and it still hasn't been clearly communicated. We break compatibility often, but generally ensure the right people -- both developers and users -- know when they need to know. This is important because people who follow snapshots (in various ways) should have a good experience because if they don't enjoy the snapshot experience, we may end up with a smaller test community between releases. Sometimes there are surprises in snapshots of a testing nature, but this particular change was not deployed or communicated as a test (we cannot go back). The normal model was not followed in this instance.
pkg_add in -current
If you are running -current and have not updated base recently, you may run inTO "pkg_add: Unknown option: always-update ". To fix it, just update to a newer base snapshot.
