search

OpenPrinting / ippusbxd

Cross-platform IPP over USB driver
Other
29 stars 4 forks source link

Increase HTTP and USB packet size. #38

Closed fletcherw closed 4 years ago

fletcherw commented 4 years ago

Previously, we used a 4KiB packet size for USB transfers and HTTP packets. This should work fine, but it's slow, especially for large IPP print and eSCL scan jobs. Therefore, change it to 32KiB to speed things up a bit.

As a data point, a scan on a virtual test printer was taking 1.8 seconds with ipp-usb (which uses a 32KiB buffer size), and 8.5 seconds with ippusbxd's 4 KiB buffer.

This could potentially be increased further; 32 KiB is not necessarily the point of diminishing returns.

Also open to discussion about whether this is the right value to use, or if we want to add a flag to set this value as well.

tillkamppeter commented 4 years ago

I have merged it, thank you very much. If you find out, perhaps by testing on actual devices, whether an even larger buffer gives better results and does not cause any problems, please post another pull request. Could you test whether this change also improves the reliability of the web admin interface?

alexpevzner commented 4 years ago

Hi,

recently I've decreased ipp-usb's read buffer size to 16K. Seems that on some combinations of Linux kernels and libusb, buffer size large that 16K works unstable.

For details, see this issue: https://github.com/OpenPrinting/ipp-usb/issues/3 and large comments inside the libusb's submit_bulk_transfer function in the libusb/libusb/os/linux_usbfs.c

Unfortunately, I'm not able to better investigate the issue, because I don't have a direct assess to the problematic hardware

fletcherw commented 4 years ago

Thanks for the info Alex. Maybe the best approach here would be to default to 16K and to allow increasing transfer size via flag then?

alexpevzner commented 4 years ago

I don't think so, because only few people will ever use this flag.

I think the best approach would be to use large buffer then and only then, when libusb doesn't use buffer splitting (see submit_bulk_transfer for details).

What I don't understand, the problem was discovered on the Raspberry Pi with Ubuntu 20.04, which implies a quire recent kernel, while comment in libusb mentions "older versions of usbfs"

P.S. large transmit buffers is not a problem, only receive buffers are affected.