Hello!
transactions to data segments is fubar. That issue is also why I wonder
about the setting of tcp_abc.
Yes, switching ABC on/off has visible impact on amount of segments.
When ABC is off, amount of segments is almost the same as number of
transactions. When it is on, ~1.5% are merged.
Alexey Kuznetsov wrote:
Hello!
transactions to data segments is fubar. That issue is also why I wonder
about the setting of tcp_abc.
Yes, switching ABC on/off has visible impact on amount of segments.
When ABC is off, amount of segments is almost the same as number of
transactions. When
On Mon, 18 Sep 2006 06:56:55 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Mon, 18 Sep 2006 14:37:05 +0400
It looks perfectly fine to me, would you like me to apply it
Alexey?
Yes, I think it is safe.
Ok, I'll put this into
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 20 Sep 2006 15:44:06 -0700
On Mon, 18 Sep 2006 06:56:55 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
Ok, I'll put this into net-2.6.19 for now. Thanks.
Did you try this on a desktop system? Something is wrong with net-2.6.19
On Wed, 20 Sep 2006 15:47:56 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 20 Sep 2006 15:44:06 -0700
On Mon, 18 Sep 2006 06:56:55 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
Ok, I'll put this into net-2.6.19 for now.
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Mon, 4 Sep 2006 20:00:45 +0400
Try enclosed patch. I have no idea why 9.997 sec is so magic, but I
get exactly this number on my notebook. :-)
=
This patch enables sending ACKs each 2d received segment.
It does not affect
From: Rick Jones [EMAIL PROTECTED]
Date: Tue, 05 Sep 2006 10:55:16 -0700
Is this really necessary? I thought that the problems with ABC were in
trying to apply byte-based heuristics from the RFC(s) to a
packet-oritented cwnd in the stack?
This is receiver side, and helps a sender who does
Hello!
It looks perfectly fine to me, would you like me to apply it
Alexey?
Yes, I think it is safe.
Theoretically, there is one place where it can be not so good.
Good nagling tcp connection, which makes lots of small write()s,
will send MSS sized frames due to delayed ACKs. But if we ACK
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Tue, 05 Sep 2006 10:55:16 -0700
Is this really necessary? I thought that the problems with ABC were in
trying to apply byte-based heuristics from the RFC(s) to a
packet-oritented cwnd in the stack?
This is receiver side, and
Hello!
Of course, number of ACK increases. It is the goal. :-)
unpleasant increase in service demands on something like a burst
enabled (./configure --enable-burst) netperf TCP_RR test:
netperf -t TCP_RR -H foo -- -b N # N 1
foo=localhost
b patched orig
2
Alexey Kuznetsov wrote:
Hello!
Of course, number of ACK increases. It is the goal. :-)
unpleasant increase in service demands on something like a burst
enabled (./configure --enable-burst) netperf TCP_RR test:
netperf -t TCP_RR -H foo -- -b N # N 1
foo=localhost
There isn't any sort
Hello!
There isn't any sort of clever short-circuiting in loopback is there?
No, from all that I know.
I
do like the convenience of testing things over loopback, but always fret
about not including drivers and actual
Regardless, kudos for running the test. The only thing missing is the
-c and -C options to enable the CPU utilization measurements which will
then give the service demand on a CPU time per transaction basis. Or
was this a UP system that was taken to CPU saturation?
It is my notebook. :-)
Alexey Kuznetsov wrote:
Hello!
Some people reported that this program runs in 9.997 sec when run on
FreeBSD.
Try enclosed patch. I have no idea why 9.997 sec is so magic, but I
get exactly this number on my notebook. :-)
Alexey
=
This patch enables sending ACKs each 2d
Hello!
Is this really necessary?
No, of course. We lived for ages without this, would live for another age.
I thought that the problems with ABC were in
trying to apply byte-based heuristics from the RFC(s) to a
packet-oritented cwnd in the stack?
It was just the
Hello!
At least for slow start it is safe, but experiments with atcp for
netchannels showed that it is better not to send excessive number of
acks when slow start is over,
If this thing is done from tcp_cleanup_rbuf(), it should not affect
performance too much.
Note, that with ABC and
Hello!
Some people reported that this program runs in 9.997 sec when run on
FreeBSD.
Try enclosed patch. I have no idea why 9.997 sec is so magic, but I
get exactly this number on my notebook. :-)
Alexey
=
This patch enables sending ACKs each 2d received segment.
It does not
From: Pekka Savola [EMAIL PROTECTED]
Date: Fri, 1 Sep 2006 12:44:48 +0300 (EEST)
On Thu, 31 Aug 2006, David Miller wrote:
...
Probably, aspect 1 of ABC just should be disabled. And the first my
suggestion looks working too.
I'm ready to rip out ABC entirely, to be honest. Or at least
On Fri, Sep 01, 2006 at 01:47:15PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
Hello!
problem. The problem is really at the receiver because we only
ACK every other full sized frame. I had the idea to ACK every 2
frames, regardless of size,
This would solve lots of problems.
Alexander Vodomerov wrote:
On Wed, Aug 30, 2006 at 02:39:55PM -0700, David Miller wrote:
Expecting any performance with one byte write's is silly.
This is absolutely true. TCP_NODELAY can only save you when you are
sending a small amount of data in aggregate, such as in an SSH or
The word performance in this list seems to always mean 'throughput'.
It seems though that there could be some knob to tweak for those of us
who don't care so much about throughput but care a great deal about
latency.
SCTP has been mentioned. There is also DCCP -
Hello!
2) a way to take delayed ACKs into account for cwnd growth
This part is OK now, right?
1) protection against ACK division
But Linux never had this problem... Congestion window was increased
only when a whole skb is ACKed, flag FLAG_DATA_ACKED. (TSO could
break this, but should not).
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Fri, 1 Sep 2006 03:29:23 +0400
2) a way to take delayed ACKs into account for cwnd growth
This part is OK now, right?
This part of ABC is not on by default, and was broken until last week
:-)
Test in tcp_slow_start() used to be:
On Thu, 31 Aug 2006 16:57:01 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Fri, 1 Sep 2006 03:29:23 +0400
2) a way to take delayed ACKs into account for cwnd growth
This part is OK now, right?
This part of ABC is not on by default,
I'm ready to rip out ABC entirely, to be honest. Or at least
turn it off by default.
Turn it off for 2.6.18, by default then evaluate more for 2.6.19
If it goes out in 2.6.18 there could probably be a good argument for
going into the stable tree as well... to stop the likes of the JVM
type
On Wed, 30 Aug 2006 14:07:34 +0400
Alexander Vodomerov [EMAIL PROTECTED] wrote:
Hello!
I'm writing an application that is working over TCP. Total traffic is
very low (~ 10 kb/sec), but performance is very bad. I've tried to
investigate problem with tcpdump and strace, and it shows that
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 10:27:27 -0700
Linux TCP implements Appropriate Byte Count (ABC) and this penalizes
applications that do small sends. The problem is that the other side
may be delaying acknowledgments. If receiver doesn't acknowledge the
On Wed, 30 Aug 2006 14:39:55 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 10:27:27 -0700
Linux TCP implements Appropriate Byte Count (ABC) and this penalizes
applications that do small sends. The problem is that the
David Miller wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 10:27:27 -0700
Linux TCP implements Appropriate Byte Count (ABC) and this penalizes
applications that do small sends. The problem is that the other side
may be delaying acknowledgments. If receiver doesn't
29 matches
Mail list logo
