Re: W/RTT verification, linux tcp buffers behaviour

From: Al Boldi
Date: Tue May 16 2006 - 08:11:58 EST

David S. Miller wrote:
> From: Al Boldi <a1426z@xxxxxxxxx>
> > David S. Miller wrote:
> > > We try to make approximations in the TCP stack, see the
> > > net.ipv4.tcp_adv_win_scale sysctl and how the kernel uses that for
> > > example.
> >
> > So can this be used to convince the kernel to utilize the full bandwidth
> > w/o striping the connection?
> >
> > It seems kind of strange, that striping would be faster when it involves
> > an inherent overhead.
> I don't understand your question, what is "striping"?

Splitting the connection into subconnections to achieve bandwidth
aggregation. This is usually done over multiple links, but can increase the
thruput in the current kernel implementation even on a single link.

> The tcp_adv_win_scale determines how much of the "socket buffer
> space" we advertise in the actual TCP window. It's mean to
> approximate the amount of structure and header overhead is
> assosciated with each packet.
> But again, it's an approximation and there are cases where it
> is suboptimal.

Ok, so is this suboptimal approximation the reason why the kernel does not
reach full bandwidth?

If so, it would probably do a lot of good to look into this calculation, as
there is definitely a linear link between CPU cycles and bandwith

Not that the problem has anything to do with running out of CPU cycles, which
can clearly be demonstrated by running multiple connections over the same
link to achieve higher total thruput.



To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at