I would explain it a bit differently to David. There are a lot of
interrelated components and concepts in TCP, and its sometimes hard to see
which ones are relevant in a given situation.
The key insight though is that there are two windows which are maintained
by the sender and receiver
On Tue, Apr 21, 2015 at 05:35:32PM +1000, jb wrote:
And I can't offer an option, because the server receive window (I think)
cannot be set on a case by case basis. You set it for all TCP and forget it.
You can set both send and receive buffers using a setsockopt() call
(SO_SNDBUF, SO_RCVBUF). I
On Tue, 21 Apr 2015, jb wrote:
the receiver advertizes a large receive window, so the sender doesn't
pause until there is that much data outstanding, or they get a timeout of
a packet as a signal to slow down.
and because you have a gig-E link locally, your machine generates traffic
\
On Tue, 21 Apr 2015, David Lang wrote:
I suspect you guys are going to say the server should be left with a large
max receive window.. and let people complain to find out what their issue
is.
what is your customer base? how important is it to provide faster service to
teh fiber users? Are
If you set the window only a little bit larger than the actual BDP of the
link then there will only be a little bit of data to fill buffer, so given
large buffers it will take many connections to overflow the buffer.
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On April 21,
That makes sense. Ok.
On Wed, Apr 22, 2015 at 12:14 PM, Simon Barber si...@superduper.net wrote:
If you set the window only a little bit larger than the actual BDP of
the link then there will only be a little bit of data to fill buffer, so
given large buffers it will take many connections
On Wed, 2015-04-22 at 06:04 +0200, Steinar H. Gunderson wrote:
On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket buffers
for the application layer, they do not change the TCP window size either
send or receive.
I haven't
On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket buffers
for the application layer, they do not change the TCP window size either
send or receive.
I haven't gone into the code and checked, but from practical experience I
On Tue, Apr 21, 2015 at 3:13 PM, jb jus...@dslr.net wrote:
Today I've switched it back to large receive window max.
The customer base is everything from GPRS to gigabit. But I know from
experience that if a test doesn't flatten someones gigabit connection they
will immediately assume oh
Regarding the low TCP RWIN max setting, and smoothness.
One remark up-thread still bothers me. It was pointed out (and it makes
sense to me) that if you set a low TCP max rwin it is per stream, but if
you do multiple streams you are still going to rush the soho buffer.
However my observation
As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket buffers
for the application layer, they do not change the TCP window size either
send or receive. Which is perhaps why they aren't used much. They don't do
much good in iperf that's for sure! Might be wrong, but I agree with the
11 matches
Mail list logo
