On Mon, Sep 30, 2013 at 5:12 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > On Mon, Sep 30, 2013 at 4:59 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Mon, 30 Sep 2013, Markus Rechberger wrote: >> >>> to explain why Isochronous makes such a difference, the kernel driver >>> doesn't do the memset anymore for each urb packet. >>> However that patch addresses multiple issues >>> * Isochronous improvement by removing memset for each packet >>> * Pre-Allocation to prevent allocation failures during runtime. >>> * Allow to restore the original behavior for >15k buffers (I'd >> >> Why do you use 15 KB as the boundary line? Wouldn't it make more sense >> to use 16 KB (that is, four pages)? >> > > it is 16k yes. > >>> recommend to make further decisions about forcing SG transfers over >>> Bulk transfers once manufacturers deliver low-end devices which >>> include both possibilities) here we have seen the latency issue with >>> certain chipsets when buffers are too small I don't know the >>> behavior/latency of SG transfers unfortunately and there's no way to >>> test it on the particular target system - other systems do not trigger >>> that problem. >> >> In general, an SG transfer has slightly higher time and memory >> requirements than a non-SG transfer. It's not a big difference. >> >> But with non-SG, the memory is allocated as a single, big buffer, >> whereas with SG the memory is allocated as a bunch of smaller buffers. >> Therefore, when memory is fragmented (which will happen on a system >> with a small amount of memory), SG transfers are more likely to succeed >> than non-SG. >> >> For example, you are more likely to be able to allocate eight 16-KB >> memory regions (SG) than a single 128-KB region (non-SG). >> > > I'm just worried about that single case where timing of the USB frames > seem to matter, it worked > with 50k buffers. > The 16k transfer size buffer seems to stop the transfer randomly after > some time needing to toggle > a register to re-enable the data again (the transfer length is > reported to be 0 the packets themself still arrive on the host). > I'm not against the SG transfers here but I'd rather like to keep both > possibilities (the old one which was available with Linux 3.5 where > there was no 16k limitation) and the SG one, I'd certainly like to > test both of them. > To make SG transfers foolproof I recommend anyway to use pre-allocated > buffers, you saw the bugreports that permanently re-allocating 16k > buffers over some time is not reliable. > >>> As far as I can see there's still some space for improvements. (eg. >>> pre-allocate large buffers (15k) for USB 3.x otherwise it will end up >>> with allocation failures during runtime on low-end systems - as seen >>> by our customers with USB 2.0 and 15k buffers on low-end systems). >>> With SG and USB 3.0 this problem should happen even quicker than with USB 2.0. >> >> Why would low-end systems be using USB-3? >> > > Routers for sharing Harddisks/NAS Systems. There are already some > available on the market. > is this going to be fixed? http://support.sundtek.com/index.php/topic,350.0.html http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 http://support.sundtek.com/index.php/topic,411.msg2153.html#msg2153 http://support.sundtek.com/index.php/topic,531.msg2956.html#msg2956 http://support.sundtek.com/index.php/topic,364.msg1829.html#msg1829 or do you have another solution for that issue on systems with a lower performance? https://developer.apple.com/library/mac/documentation/IOKit/Reference/IOUSBInterfaceInterface192_reference/translated_content/IOUSBInterfaceInterface192.html#//apple_ref/doc/uid/TP40011544-CLSCHIOUSBInterfaceInterface192-DontLinkElementID_2 Apple obviously did it the same way, though that doesn't mean that Linux has to do it that way of course. Markus > Markus > >> Alan Stern >> -- 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
