Greg Lee wrote:
Currently I've made a preliminary firmware for implementing the
CDC-ACM interface, however as Pavel kindly pointed out for me,
currently only 64Kbyte/sec is achieveable with this driver. I've read
the archives and from the discussions, I suspect that this is
connected to the NO_FSBR flag..
Questions which popped out of my mind:
1. Is there some standard way to allow for >64Kbytes/sec using the
2.6.x CDC-ACM driver? (I mean without modification of the sources, but
setting some #defines or such) I'd not mind a reasonably slower PCI
bus..
I don't know. I've never heard about a 64 KB/s limitation
for CDC-ACM.
This conversation is worrisome, I work with a number of devices that are
accessed through usbserial and ACM (e.g. wireless/cellular modems) that have
data rates in the 1-2 Mbits/s range. There are devices coming out in the
next few months that will be in the 3-6 Mbits/s range with 13 Mbits/s a year
out.
This discussion of possible underlying data rate limitations in the CDC-ACM
implementation is worrisome. Does anyone have a precise answer for what the
data rate limitations are of these two implementations (usbserial and ACM)?
I've made a switch from embedded OS to Linux recently in order to take
advantage of Linux's native USB support and am wondering whether this was
the wrong move.
Could be...
I'd be interested in whatever people have to say about this.
It seems that the acm driver sets the maximum transfer size to
the wMaxPacketSize field of the relevant endpoint descriptor,
this is maximum 64 bytes for a bulk high speed endpoint.
From my experiments this does not just restrict bulk packets to
the correct size but also restricts the maximum number of packets
in a frame to one packet. With 1 frame/ms this gives a limitation of
64k/s.
Changing the line
acm->writesize = le16_to_cpu(epwrite->wMaxPacketSize);
to
acm->writesize = 64*17; /* 17 - number of bulk packets in a USB high
speed frame */
increases performance for writes considerably.
This hack is almost certainly not optimal for usb 2.0 (full speed) devices.
I have never looked to see what other drivers did or if a similar change
helped
reads as a series of changes in the kernel made the ACM driver unusable for
me (and many others) until recently (when I complained enough to get it
fixed).
I wrote my own user space driver which has achieved write speeds of 900k/s.
These speeds should also be achievable for the ACM driver with appropriate
read/write sizes.
/Brian
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
