I have a quite anonymous usb2.0 pci card and it slows down the system very much by just loading EHCI with usbaspi.sys
No problemos with UHCI/OHCI modes.

We are talking about Golden Axe going from skyrocket speed to laggy 286ish mess in VGA, on a p200mmx pure dos system.

Maybe these drivers are optimized for SSE instructions.

I just ran another small speed test, using 3DMark99 MAX on a Diamond Monster 3D along with the Nec D720100AGM USB2.0 chip. CPU is a P233mmx. 3Dmark score is rounded to 10, as this is roughly the spread anyway. (Win98se).

No USB 2.0 card: 920

USB 2.0 card with USB 2.0 disabled: 910

USB 2.0 card: 900

USB 2.0 card + mouse: 900

USB 2.0 card + stick: 670

USB 2.0 card + empty card reader: 680

USB 2.0 card with USB 2.0 disabled + stick: 870

USB 2.0 card with USB 2.0 disabled + mouse: 900

My conclusion from the data: Use USB 2.0 card in 2.0 mode but do not use an internal card reader. Use external usb storage devices and remove them after transfer.

Another idea would be to build a DOS start menu and only load the USB drivers for data transfers.
Than afterwards reboot without USB drivers to have full speed again.
This is the way I'm dealing with that.

crusher wrote on 2024-06-22, 11:05:

Another idea would be to build a DOS start menu and only load the USB drivers for data transfers.
Than afterwards reboot without USB drivers to have full speed again.
This is the way I'm dealing with that.

Interesting. You actually load USB drivers in Dos? Did they come with the card?
This?: All you need for USB mass storage support in pure DOS, fast!!!

Aaah if the discussion is about Windows usage then forget what I said.
I was speaking only for my DOS machine.
As I have an Ali Aladdin V chipset I'm using a NEC based card which works better in that combination.
Exactly this are the drivers I'm using. Only load it when I want to transfer data. Works very well.

OK, but using a USB 2.0 driver in DOS is a bit obscure. Also, as far as I know, there is only one such driver and it's maintained by one person and closer source. Who knows what kind of bug in that EHCI driver might be causing such a slowdown?

(I know that crazii, the creator of SBEMU, is currently working on an open source EHCI driver for DOS, but I don't think it's fully working yet.)

What is the experience in Windows and Linux? Is there a slowdown there as well, just for having an EHCI driver loaded?

digger wrote on 2024-06-22, 13:35:

What is the experience in Windows and Linux? Is there a slowdown there as well, just for having an EHCI driver loaded?

Something wrong with my test?

ux-3 wrote on 2024-06-22, 13:42:

digger wrote on 2024-06-22, 13:35:

What is the experience in Windows and Linux? Is there a slowdown there as well, just for having an EHCI driver loaded?

Something wrong with my test?

Oh, I missed your response. Sorry. That's what you get when you're checking Vogons on the phone while waiting for a train. 😅 I'll take a look. Thanks!

Thanks for the benchmarks, ux-3. So if I may summarize the conclusions from your numbers:

It looks like there is a small but acceptable slowdown when you install a USB 2.0 PCI card in an older machine, but there will be considerable slowdown once you plug in any high-speed devices, even if you don't actually use to them. So only plug in high-speed devices as needed. And also, there is an additional (albeit small) further slowdown if you plug any low speed (or so-called "full speed") devices such as keyboards and mice into the USB ports on to USB 2.0 card, so it's best to keep those plugged into the integrated USB 1.x ports of the system, if possible.

Considering how the bandwidth of the 33MHz Legacy PCI bus is 133 megaBYTES per second, which is 1064 megaBITS per second, then the maximum bandwidth of USB 2.0 (EHCI), being 480 megabits per second, would potentially take up almost half of the PCI bus bandwidth. So considerable slowdown is not surprising when high speed USB 2.0 devices are used. I guess the USB controller needs to "reserve" some of that PCI bandwidth even when a connected high speed USB 2.0 device is idle.

I've asked this in this thread before, but I'm really curious what would happen to system performance if a USB 3.0 (XHCI) card were to be installed on such an old system, through use of a PCIe to Legacy PCI adapter. With a theoretical maximum bandwidth of 5 gigabits per second, such a card could potentially hog the entire bandwidth of the Legacy PCI bus. Would such a system still be usable? And how would bandwidth be divided between contending devices?

It would require the installation of a newer Windows or Linux version, but it would be a really fun and interesting experiment, I think.

Also, I'm curious about what the performance impacts would be with a motherboard with an AGP graphics card, since AGP cards would get their own dedicated bandwidth that they wouldn't have to share with any cards on the PCI bus. In such setups, you'd think that only disk perfomance would be affected by the addition of a USB 2.0 card, and graphics performance would remain unaffected.

digger wrote on 2024-06-22, 14:12:

there is an additional (albeit small) further slowdown if you plug any low speed (or so-called "full speed") devices such as keyboards and mice into the USB ports on to USB 2.0 card, so it's best to keep those plugged into the integrated USB 1.x ports of the system, if possible.

I can't confirm that, because I have no working USB 1.x on that board to test against. There was no difference between the card in USB2.0 and in USB1.0 mode with a mouse in it. The only reason to use the onboard usb for mouse& keyboard would be DOS.

digger wrote on 2024-06-22, 14:12:

It would require the installation of a newer Windows or Linux version, but it would be a really fun and interesting experiment, I think.

😀 I don't take the bait.

digger wrote on 2024-06-22, 14:12:

Also, I'm curious about what the performance impacts would be with a motherboard with an AGP graphics card, since AGP cards would get their own dedicated bandwidth that they wouldn't have to share with any cards on the PCI bus. In such setups, you'd think that only disk perfomance would be affected by the addition of a USB 2.0 card, and graphics performance would remain unaffected.

I do have a ready setup for this, but my desk is full atm.

digger wrote on 2024-06-22, 14:12:

additional (albeit small) further slowdown if you plug any low speed (or so-called "full speed") devices such as keyboards and mice into the USB ports on to USB 2.0 card, so it's best to keep those plugged into the integrated USB 1.x ports of the system, if possible.

this is inconclusive, I wager a guess both onboard and pci card USB 1.1 will have same overhead.

digger wrote on 2024-06-22, 14:12:

Considering how the bandwidth of the 33MHz Legacy PCI bus is 133 megaBYTES per second, which is 1064 megaBITS per second, then the maximum bandwidth of USB 2.0 (EHCI), being 480 megabits per second, would potentially take up almost half of the PCI bus bandwidth.

you dont use full USB 2.0 BW by just plugging USB pendrive 😀
Its about the density of CPU interrupts generated by USB controller Re: IDE 66 and USB 2.0 relationship
"USB 1.0 pooling rate maxes out at 1ms. USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals.
TLDR: USB 2.0 generates 8x more traffic even when doing nothing. Afaik USB controllers (OHCI, UHCI might have this automated) are stupid enough to require manual cpu handling of each individual SOF interrupt."

digger wrote on 2024-06-22, 14:12:

So considerable slowdown is not surprising when high speed USB 2.0 devices are used.

plugged, just plugged not doing anything. I think I saw someone else test showing even USB 2.0 device with no driver installed will cause same overhead.

digger wrote on 2024-06-22, 14:12:

I've asked this in this thread before, but I'm really curious what would happen to system performance if a USB 3.0 (XHCI) card were to be installed on such an old system, through use of a PCIe to Legacy PCI adapter.

most likely driver would require/was compiled for more modern CPU and just crash 😀 but if it didnt overhead wouldnt be bigger. 3.0 adopted 2.0 pooling rate.

ux-3 wrote on 2024-06-22, 14:27:

I can't confirm that, because I have no working USB 1.x on that board to test against. There was no difference between the card in USB2.0 and in USB1.0 mode with a mouse in it. The only reason to use the onboard usb for mouse& keyboard would be DOS.

[..]

I do have a ready setup for this, but my desk is full atm.

If and once you get around to testing such a setup, you'd be able ton test both hypotheses, since earlier motherboards with AGP slots also have integrated USB 1.1 (UHCI) controllers.

rasz_pl wrote on 2024-06-22, 15:30:

you dont use full USB 2.0 BW by just plugging USB pendrive :) Its about the density of CPU interrupts generated by USB controlle […]
Show full quote

you dont use full USB 2.0 BW by just plugging USB pendrive 😀
Its about the density of CPU interrupts generated by USB controller Re: IDE 66 and USB 2.0 relationship
"USB 1.0 pooling rate maxes out at 1ms. USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals.
TLDR: USB 2.0 generates 8x more traffic even when doing nothing. Afaik USB controllers (OHCI, UHCI might have this automated) are stupid enough to require manual cpu handling of each individual SOF interrupt."

Interesting. Thanks for sharing. I guess this was the reason why IEEE 1394 (FireWire) was more performant back in the day, despite the lower theoretical peak bandwidth. With DMA support, you wouldn't have to poll so much, and therefore wouldn't need to fire so many interrupts, right? Of course that came at the price of being less secure and more expensive to implement.

About trying USB 3.0 (XHCI) cards in USB 1.x systems:

most likely driver would require/was compiled for more modern CPU and just crash 😀 but if it didnt overhead wouldnt be bigger. 3.0 adopted 2.0 pooling rate.

There should be some Linux distros that are catered to older computers. Even the latest mainline Linux kernel (including all its included drivers) can still be compiled for first-gen Pentium CPUs. Even 486 support is only just now in the process of being removed.

But even if there is something in the Linux XHCI driver sources that would make it incompatible with older PCs, the testing of such a hardware setup should still be possible using NetBSD. NetBSD is designed in such a way that all included kernel drivers should compile successfully for and run correctly on any architecture, old and new. For instance, the PCI end USB subsystems in NetBSD have been designed with architecture-neutrality in mind.

digger wrote on 2024-06-22, 16:09:

Interesting. Thanks for sharing. I guess this was the reason why IEEE 1394 (FireWire) was more performant back in the day, despite the lower theoretical peak bandwidth. With DMA support, you wouldn't have to poll so much, and therefore wouldn't need to fire so many interrupts, right? Of course that came at the price of being less secure and more expensive to implement.

Yes, afaik pooling doesnt exist in FW at all. Devices initiate transfers and interrupts at their leisure, FW works more or less like a very slow one lane PCIE.
Its possible USB 3.0 controllers are smart enough to have fully automated pooling and only interrupt when something actually does happen, I thought that would happen with USB 2.0, but as the tests show here we are with heavy CPU usage at idle.

I just discovered a new problem:

IF (NEC USB 2.0 card is present) AND (secondary IDE master is connected), THEN the system hangs at boot after HDD detection, during PnP initialization.

Connecting the secondary slave will boot fine. The usb card takes IRQ 9,10 and 11, IDE takes 14. There is no interrupt conflict visible. Could this be a DMA channel clash?

No DMA channel conflicts on PCI

no need of benchmarks here 🤣. I disabled EHCI for good.

rasz_pl wrote on 2024-06-22, 15:30:

Its about the density of CPU interrupts generated by USB controller Re: IDE 66 and USB 2.0 relationship
"USB 1.0 pooling rate maxes out at 1ms. USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals.
TLDR: USB 2.0 generates 8x more traffic even when doing nothing. Afaik USB controllers (OHCI, UHCI might have this automated) are stupid enough to require manual cpu handling of each individual SOF interrupt."

EHCI doesn't have a SOF interrupt.
It's far more streamlined that UHCI/OHCI; all you have to do is set up transfers in memory and the controller does the rest. Interrupts only need to occur when transfers complete or there is a port status change. High CPU usage is simply a case of poor drivers.

jmarsh wrote on 2024-06-23, 02:47:

case of poor drivers.

all of them, from all vendors?