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. 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
