David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 10 Mar 2006 17:15:14 -0800
/* RFC3465: Slow Start
* TCP sender SHOULD increase cwnd by the number of
* previously unacknowledged bytes ACKed by each incoming
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 10 Mar 2006 17:15:14 -0800
> > /* RFC3465: Slow Start
> > * TCP sender SHOULD increase cwnd by the number of
> > * previously unacknowledged bytes ACKed by each incoming
> > * acknowledgment, provide
Stephen Hemminger wrote:
On Fri, 10 Mar 2006 16:16:07 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:
I would have thought that byte based growth of the CWND would have meant
that the ACK's above would have allowed more bytes to flow, yet more
bytes are not flowing. That makes it seem like cwnd
On Fri, 10 Mar 2006 16:16:07 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:
> >>I would have thought that byte based growth of the CWND would have meant
> >>that the ACK's above would have allowed more bytes to flow, yet more
> >>bytes are not flowing. That makes it seem like cwnd isn't strictly
I would have thought that byte based growth of the CWND would have meant
that the ACK's above would have allowed more bytes to flow, yet more
bytes are not flowing. That makes it seem like cwnd isn't strictly
bytes, but is also tracked in terms of number of outstanding segments.
Linux cwnd i
On Fri, 10 Mar 2006 13:41:28 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:
> > ABC is strictly enforcing byte based CWND growth now.
> >
> > All the details are in RFC3465.
>
>
> > That certainly is an odd looking trace. There doesn't happen to be a
> > system call trace to go along with it doe
ABC is strictly enforcing byte based CWND growth now.
All the details are in RFC3465.
That certainly is an odd looking trace. There doesn't happen to be a
system call trace to go along with it does there? It looks like it goes
along like this:
13:23:33.458806 IP l.5877 > l.12823: P 29110
Eric Molitor wrote:
Was there a trace posted somewhere? I would indeed like to look at it.
I'd be quite happy to slam java it it happened to be putting logically
associated data onto the connection in separate send calls :)
It was sent to Bugzilla but too large so Andrew Morton kindly upload
> Was there a trace posted somewhere? I would indeed like to look at it.
> I'd be quite happy to slam java it it happened to be putting logically
> associated data onto the connection in separate send calls :)
It was sent to Bugzilla but too large so Andrew Morton kindly uploaded it to
htt
On Fri, 10 Mar 2006 10:27:35 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:
>
> > Part of the issue is that NODELAY has dual meaning. It means don't delay
> > acks (on receiver), and don't coalesce writes (on sender). If java
> > didn't turn on NODELAY, it would get coalescing but it would then get
Part of the issue is that NODELAY has dual meaning. It means don't delay
acks (on receiver), and don't coalesce writes (on sender). If java
didn't turn on NODELAY, it would get coalescing but it would then get
delayed acks.
Ah, this is the first time I've heard that TCP_NODELAY on a receiver
On Fri, 10 Mar 2006 09:31:19 -0800
Rick Jones <[EMAIL PROTECTED]> wrote:
> Eric Molitor wrote:
> > Thanks for bearing with my questions. The RFC makes it very clear why
> > this is bad and I agree that workarounds in the kernel for naughty
> > apps are silly and a bad idea. I do suspect that Java
Eric Molitor wrote:
Thanks for bearing with my questions. The RFC makes it very clear why
this is bad and I agree that workarounds in the kernel for naughty
apps are silly and a bad idea. I do suspect that Java wont be the only
app that has issues with this. In the meantime there is a workaround.
Thanks for bearing with my questions. The RFC makes it very clear why
this is bad and I agree that workarounds in the kernel for naughty
apps are silly and a bad idea. I do suspect that Java wont be the only
app that has issues with this. In the meantime there is a workaround.
Thanks all,
Eric
From: "Eric Molitor" <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 22:39:16 -0600
> Its pretty bad on both. But most Java developers debug via localhost.
> The slowdowns don't occur on Windows, Solaris, or the unoficial JDK
> port to BSD. But I dont know what kernels support ABC. For now I will
> see
Its pretty bad on both. But most Java developers debug via localhost.
The slowdowns don't occur on Windows, Solaris, or the unoficial JDK
port to BSD. But I dont know what kernels support ABC. For now I will
see what sun does with the bug report and then chase after IBM. IBM
tends to be more willin
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 09 Mar 2006 15:51:14 -0800
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff going?
X wants the packets to go out immediately, in fact as Ji
On Thu, 09 Mar 2006 15:54:50 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Thu, 09 Mar 2006 15:51:14 -0800
>
> > Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
> > of small packets? What happens to it with this A
Also X on Linux doesn't use TCP over loopback. It seems to use AF_UNIX.
is this problem only over loopback? or is it just harder to see it over
a "real" link?
rick
onlist no need for cc
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PR
Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
of small packets? What happens to it with this ABC stuff going?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 09 Mar 2006 15:51:14 -0800
> Doesn't X semi-legitimately set TCP_NODELAY and then start sending lots
> of small packets? What happens to it with this ABC stuff going?
X wants the packets to go out immediately, in fact as Jim
Getty's mentioned duri
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 15:45:05 -0800
> Maybe Solaris (and Windows?) have special-case handling for local TCP. It
> seems a bit odd to me that loopback would use normal handling for things
> like slow-start and congestion, but I'm sure there's a good reason
"David S. Miller" <[EMAIL PROTECTED]> wrote:
>
> > Like Sun is going to give me the source?...
>
> And if Sun doesn't support their userland products well that is
> somehow the Linux kernel's problem?
Presumably they tested this on Solaris and it ran OK.
Maybe Solaris (and Windows?) have special
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 15:11:47 -0800
> Then the dst would get changed, no breakage.
Not with a TC action rewrite on input, that would happen after
loopback does the netif_rx().
Interface specific hard-coded metrics are wrong from every single
possible
On Thu, 09 Mar 2006 15:06:22 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Thu, 9 Mar 2006 14:56:43 -0800
>
> > This patch is changes the initial TCP congestion window for connections that
> > are over the loopback device. This give
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 9 Mar 2006 14:56:43 -0800
> This patch is changes the initial TCP congestion window for connections that
> are over the loopback device. This gives better for performance for
> applications
> that do lots of small writes. It might also help f
This patch is changes the initial TCP congestion window for connections that
are over the loopback device. This gives better for performance for applications
that do lots of small writes. It might also help for idiotic benchmarks.
See: http://bugzilla.kernel.org/show_bug.cgi?id=6177
Signed-off-b
27 matches
Mail list logo
