> > > > > Grepping through a few log files, the userland program read
> > > > > 44,751,896 bytes
> > > > > with a single syscall. The default recv buf size of 65536 doesn't
> > > > > get the
> > > > > job done for this application.
>
> OK, I'll take the bite. The following scenario might apply
On Sun, Feb 08, 2009 at 09:58:23PM +, Dieter wrote:
> > > > Grepping through a few log files, the userland program read 44,751,896
> > > > bytes
> > > > with a single syscall. The default recv buf size of 65536 doesn't get
> > > > the
> > > > job done for this application.
OK, I'll take t
> > > > > > > How high is too high? I have a utility that sets recv buf size
> > > > > > > to 100,000,000 and it works fine on FreeBSD and NetBSD. (Not
> > > > > > > tested yet on OpenBSD.) Necessary when the other end has buggy
> > > > > > > network code and insufficient send buf.
> > > > > >
On Wed, Feb 04, 2009 at 11:34:25AM +0100, Claudio Jeker wrote:
> On Tue, Feb 03, 2009 at 04:28:36PM +, Dieter wrote:
> > > > > > How high is too high? I have a utility that sets recv buf size
> > > > > > to 100,000,000 and it works fine on FreeBSD and NetBSD. (Not
> > > > > > tested yet on O
On Tue, Feb 03, 2009 at 04:28:36PM +, Dieter wrote:
> > > > > How high is too high? I have a utility that sets recv buf size
> > > > > to 100,000,000 and it works fine on FreeBSD and NetBSD. (Not
> > > > > tested yet on OpenBSD.) Necessary when the other end has buggy
> > > > > network code
> > > > How high is too high? I have a utility that sets recv buf size
> > > > to 100,000,000 and it works fine on FreeBSD and NetBSD. (Not
> > > > tested yet on OpenBSD.) Necessary when the other end has buggy
> > > > network code and insufficient send buf.
> > >
> > > Could you clarify what y
* Brian Keefer [2009-01-31 19:47]:
> On Jan 31, 2009, at 4:57 AM, Stuart Henderson wrote:
>
>> On 2009-01-31, Brian Keefer wrote:
>>>
>>> Great, thanks for the pointers! I'm trying to fiddle with iperf
>>> performance testing going to a Linux box. tcpbench works great on
>>> OpenBSD, but it see
On 2009-02-01, Dieter wrote:
> Black box sends data to BSD box using TCP. Data is generated in
> real time, the rate cannot be changed. Black box has a very small
> (way too small) send buffer. If the BSD box takes too long to
> ack, the black box's send buffer fills up and data is lost,
> and/
On Sun, Feb 01, 2009 at 02:26:52PM +, Dieter wrote:
> [ replying here because gmail is broken ]
>
> > > How high is too high? I have a utility that sets recv buf size
> > > to 100,000,000 and it works fine on FreeBSD and NetBSD. (Not
> > > tested yet on OpenBSD.) Necessary when the other en
[ replying here because gmail is broken ]
> > How high is too high? I have a utility that sets recv buf size
> > to 100,000,000 and it works fine on FreeBSD and NetBSD. (Not
> > tested yet on OpenBSD.) Necessary when the other end has buggy
> > network code and insufficient send buf.
>
> Could
> > > It seems the
> > > only significantly value for net.inet.tcp.rfc1323 is 0 (disabled) vs.
> > > non-0
> > > (ws=0). Am I missing something?
> >
> > You'll never see a scale size larger than zero unless the involved
> > program sets a socket receive buffer size larger than 64KB before
> > ca
On Jan 31, 2009, at 4:57 AM, Stuart Henderson wrote:
On 2009-01-31, Brian Keefer wrote:
Great, thanks for the pointers! I'm trying to fiddle with iperf
performance testing going to a Linux box. tcpbench works great on
OpenBSD, but it seems iperf is the only thing readily available for
Linux
On 2009-01-31, Brian Keefer wrote:
>
> Great, thanks for the pointers! I'm trying to fiddle with iperf
> performance testing going to a Linux box. tcpbench works great on
> OpenBSD, but it seems iperf is the only thing readily available for
> Linux that is also on OpenBSD. I'm just trying
On Jan 30, 2009, at 6:29 PM, jared r r spiegel wrote:
On Fri, Jan 30, 2009 at 05:55:48PM -0800, Philip Guenther wrote:
It seems the
only significantly value for net.inet.tcp.rfc1323 is 0 (disabled)
vs. non-0
(ws=0). Am I missing something?
You'll never see a scale size larger than zero u
On Fri, Jan 30, 2009 at 05:55:48PM -0800, Philip Guenther wrote:
> > It seems the
> > only significantly value for net.inet.tcp.rfc1323 is 0 (disabled) vs. non-0
> > (ws=0). Am I missing something?
>
> You'll never see a scale size larger than zero unless the involved
> program sets a socket rec
On Fri, Jan 30, 2009 at 3:53 PM, Brian Keefer wrote:
> I'm probably ignorant, but I can't seem to find a way to increase the window
> scaling multiplier on an OpenBSD client. It's always zero.
"What problem are you trying to solve?"
The scale factor is *ONLY* a means to increase the maximum pos
On 2009-01-30, Brian Keefer wrote:
> I'm probably ignorant, but I can't seem to find a way to increase the
> window scaling multiplier on an OpenBSD client. It's always zero. It
> seems the only significantly value for net.inet.tcp.rfc1323 is 0
> (disabled) vs. non-0 (ws=0). Am I missing
I'm probably ignorant, but I can't seem to find a way to increase the
window scaling multiplier on an OpenBSD client. It's always zero. It
seems the only significantly value for net.inet.tcp.rfc1323 is 0
(disabled) vs. non-0 (ws=0). Am I missing something?
--
bk
18 matches
Mail list logo
