On Aug 1, 2011, at 4:55 PM, Felipe Balbi wrote: > Hi, > > (please break your lines at 80 characters ;-) Please fix your email reader to justify text written on email clients that give you no way to do that effectively. No, I probably don't buy that either, used to annoy the heck out of me too. 8/ > On Mon, Aug 01, 2011 at 02:57:42PM -0700, Perry Wagle wrote: >> If I have a 2.6.31.6 kernel running on an ARM, what kind of >> performance can I get how? I'm getting about 14 MB/sec read and write > > it pretty much depends on the controller you're using and how optimized > the driver for that controller is. This is really a case-by-case > analysis. While the stack itself poses some overhead, I would say > (didn't measure ok ;-) Linux's USB stacks (host and device side) are > quite low overhead... I guess I was looking for ballpark estimates for vanilla hardware. Like whether I was getting average performance or ridiculously slow for basic commodity hardware and software. > >> and the customer of my customer (I'm an independent contractor) is >> expecting 20-30. Is that possible in linux? (I get the same > > well, if the HW _can_ do better and the SW isn't optimized, then yes, > why not ?!? I'm not sure how well the hardware can do, is there any way to experimentally get estimates? What's "easy" to do in the way of software? I'm a slightly clued usb noob. >> performance on a x86_64 running ubuntu 10.10). What's the deal we can >> tell them? > > we can't really tell you how to talk to your customers, what we can tell > is that without further information on the setup (which controller, > which device, who's playing the role as Host and who's playing role as > Device, which chipset on Host side, which disk are you using, etc) it's > quite difficult to give any tips. Ok, to not unduly annoy everyone with a bout of 20 questions, what should I look at to get more detailed info that I can give here? > -- > balbi -- 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
