From: Greg KH <greg@kroah.com>
To: Olivier Galibert <galibert@pobox.com>,
Ren? Rebe <rene@exactcode.de>,
linux-kernel@vger.kernel.org
Subject: Re: MAX_USBFS_BUFFER_SIZE
Date: Wed, 1 Mar 2006 15:37:29 -0800 [thread overview]
Message-ID: <20060301233729.GA25356@kroah.com> (raw)
In-Reply-To: <20060301232535.GA13225@dspnet.fr.eu.org>
On Thu, Mar 02, 2006 at 12:25:35AM +0100, Olivier Galibert wrote:
> On Wed, Mar 01, 2006 at 02:41:23PM -0800, Greg KH wrote:
> > On Wed, Mar 01, 2006 at 11:34:30PM +0100, Olivier Galibert wrote:
> > > As a data point, I have traces of a scanner session including a
> > > download of a 26Mb binary image using 524288 bytes logical blocks
> > > physically transferred with 61440 bytes bulk_in frames. Seems stable
> > > enough. IIRC the scanner-side controller chip has some advanced
> > > buffering just to handle that kind of bandwidth.
> >
> > That's impressive. What are the endpoint sizes on the device that did
> > this?
>
> Hmmm, the chip is a Genesys gl841, on a canonscan lide 35. And it
> advertises a 64 bytes wMaxPacketSize on both in and out bulk
> interfaces. Go figure.
>
> Want the log and/or the lsusb -v?
Nah, I was just curious.
Now notice that the max the device can take for a single USB frame is 64
bytes. So if you send one urb at 16K, you should have plenty of cpu
time to queue up another one of the same size before that one flushes
out to the device, even if it is a high speed device.
That's the reason upping the size of this buffer will not really help
anyone out, except lazy userspace programmers :)
thanks,
greg k-h
next prev parent reply other threads:[~2006-03-01 23:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-01 20:16 MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-01 20:53 ` MAX_USBFS_BUFFER_SIZE Oliver Neukum
2006-03-01 21:32 ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 21:42 ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-01 21:54 ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 22:34 ` MAX_USBFS_BUFFER_SIZE Olivier Galibert
2006-03-01 22:41 ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 23:25 ` MAX_USBFS_BUFFER_SIZE Olivier Galibert
2006-03-01 23:37 ` Greg KH [this message]
2006-03-02 9:04 ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-02 16:47 ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-02 16:03 ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-02 16:47 ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-01 21:59 ` MAX_USBFS_BUFFER_SIZE Duncan Sands
2006-03-03 10:34 ` MAX_USBFS_BUFFER_SIZE Oliver Neukum
[not found] ` <mailman.1141249502.22706.linux-kernel2news@redhat.com>
2006-03-02 21:05 ` MAX_USBFS_BUFFER_SIZE Pete Zaitcev
2006-03-03 7:27 ` MAX_USBFS_BUFFER_SIZE René Rebe
2006-03-03 20:32 ` MAX_USBFS_BUFFER_SIZE Greg KH
2006-03-03 8:12 ` MAX_USBFS_BUFFER_SIZE Duncan Sands
2006-03-03 10:29 ` MAX_USBFS_BUFFER_SIZE Oliver Neukum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060301233729.GA25356@kroah.com \
--to=greg@kroah.com \
--cc=galibert@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rene@exactcode.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox