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 it
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.
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
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-
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
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. :-) Of
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 actua
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 sor
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 10
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 h
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 net-2.6.19 for now. Thanks.
-
To unsubscribe from this list: send the line "unsubscri
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
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 d
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 af
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 t
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 re
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 no
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 anot
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 p
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.
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.
>but that might have other problems.
BSD used to do this, everyon
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
turn it off by default.
Just as a curious observer: do you think these issues are due t
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Fri, 1 Sep 2006 15:39:37 +1200
> > > 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 probab
> 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 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
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:
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: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 31 Aug 2006 15:14:56 -0700
> On Fri, 1 Sep 2006 01:46:35 +0400
> Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
>
> > > Expecting any performance with one byte write's is silly.
> >
> > I am not sure why you are so confident about status of ABC
On Fri, 1 Sep 2006 01:46:35 +0400
Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
> Hello!
>
> > Expecting any performance with one byte write's is silly.
>
> I am not sure why you are so confident about status of ABC.
> I missed the discussions, when it was implemented. Apparently,
> it was noticed
Hello!
> Expecting any performance with one byte write's is silly.
I am not sure why you are so confident about status of ABC.
I missed the discussions, when it was implemented. Apparently,
it was noticed that ABC in its pure form does not make sense
with snd_cwnd counted in packets and there wer
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 - http://www.read.cs.ucla.edu/dccp/
Kelly Burkhart wrote:
On 8/30/06, David Miller <[EMAIL PROTECTED]> wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
> 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",
On 8/30/06, David Miller <[EMAIL PROTECTED]> wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
> 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
tel
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
t
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
> telnet session, whereas in th
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'
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
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: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 tha
39 matches
Mail list logo
