From owner-freebsd-stable@FreeBSD.ORG  Fri May  2 12:29:09 2008
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 685AF1065672;
	Fri,  2 May 2008 12:29:09 +0000 (UTC)
	(envelope-from kamikaze@bsdforen.de)
Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79])
	by mx1.freebsd.org (Postfix) with ESMTP id 2A5448FC0C;
	Fri,  2 May 2008 12:29:08 +0000 (UTC)
	(envelope-from kamikaze@bsdforen.de)
Received: from mobileKamikaze.norad (unknown [92.116.48.145])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.bsdforen.de (Postfix) with ESMTP id AA68D8A0825;
	Fri,  2 May 2008 14:29:02 +0200 (CEST)
Message-ID: <481B0904.40403@bsdforen.de>
Date: Fri, 02 May 2008 14:28:52 +0200
From: Dominic Fandrey <kamikaze@bsdforen.de>
User-Agent: Thunderbird 2.0.0.12 (X11/20080422)
MIME-Version: 1.0
To: Adam McDougall <mcdouga9@egr.msu.edu>
References: <481AD8D1.7090004@bsdforen.de> <481AF29C.9080706@egr.msu.edu>
In-Reply-To: <481AF29C.9080706@egr.msu.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kan@FreeBSD.org, freebsd-stable@freebsd.org
Subject: Re: ubsa speed limit
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2008 12:29:09 -0000

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.