> You can use time(1) while reading usb disk to see if cpu is really the > bottleneck, or if in fact your machine is spending most of its time > waiting for a usb interrupt. If the machine is mostly idle, profiling > clock ticks should usually find it sitting at the HLT instruction which > happens to be couple of bytes before _strayintr.
time suggests that it is waiting for interrupts: 0.03u 0.75s 25.42r if i force polling, it's a little faster: 0.01u 0.45s 17.70r (dd -if /dev/sdU0.0/data -of /dev/null -bs 65536 -count 1024) holding a second, time wouldn't show interrupt-handling time, correct? load remains fairly low during both, but system calls and context switches are high. time to read up on ehci... thank you, tristan -- All original matter is hereby placed immediately under the public domain.
