Date: Fri, 02 May 2008 14:28:52 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: kan@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: ubsa speed limit Message-ID: <481B0904.40403@bsdforen.de> In-Reply-To: <481AF29C.9080706@egr.msu.edu> References: <481AD8D1.7090004@bsdforen.de> <481AF29C.9080706@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Adam McDougall wrote:
> Dominic Fandrey wrote:
>> When I download a single file it seems that the download speed is
>> limited to 32k (raw data as shown by netstat). Under Windows I can
>> reach values around 60k. I can achieve more throughput (though not as
>> much as under Windows), when downloading several files at once.
>>
> Try this hack, its using concepts I gathered from people patching the
> Linux driver, basically increasing the block size of transfers.
>
> Edit ubsa.c and recompile/reload the ubsa driver. Its located around
> line 362. Basically replace UGETW(ed->wMaxPacketSize); or
> UGETW(ed->wMaxPacketSize); with 2048. I think the default is 512 and
> you can play with different values to evaluate its effect on speed. I
> realized a large performance boost from 2048, I think at least 80k/sec
> transfer rate.
>
> } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN &&
> UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) {
> ucom->sc_bulkin_no = ed->bEndpointAddress;
> - ucom->sc_ibufsize = UGETW(ed->wMaxPacketSize);
> + ucom->sc_ibufsize = 2048;
> + // ucom->sc_ibufsize = UGETW(ed->wMaxPacketSize);
> } else if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_OUT &&
> UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) {
> ucom->sc_bulkout_no = ed->bEndpointAddress;
> - ucom->sc_obufsize = UGETW(ed->wMaxPacketSize);
> + ucom->sc_obufsize = 2048;
> + // ucom->sc_obufsize = UGETW(ed->wMaxPacketSize);
> }
> }
Thanks a lot. This improves the situation a lot. However I found the
improvement somewhat unsteady. I think that a 2k or 4k buffer is still not
sufficient if the answering time is high. A 16k buffer leads to a much more
steady data stream for me.
I think the best solution would be dynamic buffer allocation similar to what
is done on layer 4.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?481B0904.40403>