Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: >> >> Moreover, the same way that we can use sysfs to increase max_sectors, we >> >> can use it to decrease everytime we find a broken device. I really >> >> wonder if they still are available in the market. So, wouldn't a better >> >> default be 2048 and we decrease this as quirk flags when people complain >> >> about regressions ? I mean, 20~25% improvement is quite considerable >> > >> > I don't know about current availability. The decision to use 120 KB as >> > the default was made a long time ago, but it wouldn't be surprising if >> >> apparently back in 2003 [1] > > I found an apparently earlier message in the old usb-storage archives. > This was back when the list contents was supposed to be available to > subscribers only, but I hope nobody will mind if I copy the message > here (it doesn't contain anything confidential): > > ------------------------------------------------------------------------------ > Date: Sun, 2 Nov 2003 11:01:29 -0800 > From: Matthew Dharm mdharm-usb@... > Subject: [usb-storage] PATCH 2.5/6: limit transfer size for more compatibility > > This patch limits the amount of data that will be transferred in a single > command/data/status exchange to 240 sectors (about 120KB on most devices). > > This is to increase compatibility with existing devices. Apparently, many > of them don't like large transfers. Those devices are broken, but there > are enough of them (and they are otherwise impossible to detect) to make > this patch valuable. > > Future versions of the kernel may allow runtime tuning of this parameter > for higher performance. > > Greg, please apply. > > Matt > ------------------------------------------------------------------------------ > > > Here's another related message taken from the archives: > > > ------------------------------------------------------------------------------ > Date: Thu, 24 Jul 2003 12:57:16 -0700 (PDT) > From: frits <Frits.Vanderlinden@...> > Subject: [usb-mass:0500] Maximum transfer size? > >>>I can impose an artificial limit on this size. However, I'm wondering how >>>large a limit I should impose. >>> >>>Does anyone know what transfer size chipsets are generally tested to? >>> > > we just reduced in Solaris the limit to 124K. around 128K some devices > start hanging and choking. requests > 124K are broken up. > > fritS > ------------------------------------------------------------------------------ > > > So Linux wasn't alone. One of the error reports that led to this patch > can be found in this thread: > > http://marc.info/?l=linux-scsi&m=105847048818775&w=2 thanks for digging these up. >> > some of the devices available back then are still in use. You wouldn't >> > want to cause a regression, would you? :-) >> >> My point is that it might be better to find out which device(s) is >> quirky because that list might be a lot smaller than the list of >> non-quirky devices. Looking at the CBW structure, I have 16 bits for >> telling the gadget how many sectors I want, when we limit to 240 >> sectors, we're only using 8 bits of those :-p >> >> If I can find one of these old devices, I'd certainly try to, at least, >> Document the reasons why we chose this, apparently arbitrary, 240 >> sectors limit. > > In view of Linus's comments, it really seems best to leave the default > setting as it is for USB-2 devices. (Even increasing it just for USB-3 > devices _might_ lead to occasional trouble, but at least it's a > defensible approach.) okay, fair enough. >> >> > In fact, there are quite a few USB storage devices which break if you >> >> > try to transfer more than 64 KB at a time. That's what Windows uses by >> >> > default (although maybe they use a larger value for USB-3 devices). >> >> >> >> I have no idea what MS uses as default so I'll just take your word for >> >> it, unless you have some evidence of this statement somewhere. >> > >> > It's easy to prove for yourself. Enable VERBOSE_DEBUG in >> > storage_common.h and plug the resulting mass-storage gadget into a >> > Windows machine. Then check the kernel log to see how large the read >> >> /me goes look for a windows machine >> >> > and write transfers get. That's how I learned about the Windows >> > limit. >> >> and that happened how long ago ? :-) > > Well, my original tests were probably more than 12 years ago. But I > have seen logs taken using Windows-based hosts more recently. Okay, fired up my sniffer. Largest transfer I saw was 128 blocks. I don't have a USB3 host around to see if windows treats USB3 devices differently. Guess I'll go buy an ExpressCard next week and try it out. cheers -- balbi
Attachment:
signature.asc
Description: PGP signature
