Hello, I am chasing a performance issue with a device that presents itself as a cdc-acm device. Using pv, I have seen data rates that indicate writes are saturating full-speed USB -- can't ask for more than that. OTOH, on reads, PV shows truly sad data rates. using: pv /dev/ttyACM0 > /dev/null On a short transaction where the reply is 11 lines of text of about 30 characters each, pv reports: 100 B/s with the tty in cooked mode, (yes, that is a B, no k, no M) 1.8 kB/s in raw mode. On a longer transaction where the reply is about 360 lines of 40 characters each, pv reports: 35 kB/s cooked 38 kB/s raw (I'm collecting the data by queuing up a large number of transactions in the device, so all it has to do is format and report the data. There should not be any transaction turn-around delays.) Obviously , raw is the correct mode for my application, I only show the data for comparison. After searching this list I see that other cdc-acm devices can saturate full speed reads. I've spent enough time reading the cdc-acm driver that I think I understand its basic operation. It appears that it queues up all available empty read urbs at every opportunity, so that the read task should never be starved for buffers, is that understanding correct? What is the best way to isolate whether the delay is in the device, the cdc-acm driver, or some other piece of the tty driver stack? Is turning on debug instrumentation as simple as building cdc-acm with -DDEBUG, or do I need to enable something else further? If it does turn out to be the device, what kind of device quirks (in USB implementation*) could be at the root of something like this? Any suggestions for further experiments appreciated. TIA -dave *Obviously, the device could just be doing poor real-time scheduling internally. I'm asking here specifically about poor USB implementation. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
