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. But this is invisible
in numbers of throughput/cpu usage.

That' numbers:

1Gig link. The first column is "b". - separates runs of netperf
in backward direction.

Run #1. One host is slower.

        old,abc=0
	 new,abc=0
	  new,abc=1
	   old,abc=1

2	23652.00  6.31   21.11  10.665  8.924
	 23622.16  6.47   21.01  10.951  8.893
	  23625.05  6.21   21.01  10.512  8.891
	   23725.12  6.46   20.31  10.898  8.559
	-
	23594.87  21.90  6.44   9.283   10.912
	 23631.52  20.30  6.36   8.592   10.766
	  23609.55  21.00  6.26   8.896   10.599
	   23633.75  21.10  5.44   8.929   9.206

4	36349.11  8.71   31.21  9.584   8.585
	 36461.37  8.65   30.81  9.492   8.449
	  36723.72  8.22   31.31  8.949   8.526
	   35801.24  8.58   30.51  9.589   8.521
	-
	35127.34  33.80  8.43   9.621   9.605
	 36165.50  30.90  8.48   8.545   9.381
	  36201.45  31.10  8.31   8.592   9.185
	   35269.76  30.00  8.58   8.507   9.732

8	41148.23  10.39  42.30  10.101  10.281
	 41270.06  11.04  31.31  10.698  7.585
	  41181.56  5.66   48.61  5.496   11.803
	   40372.37  9.68   56.50  9.591   13.996
	-
	40392.14  47.00  11.89  11.637  11.775
	 40613.80  36.90  9.16   9.086   9.019
	  40504.66  53.60  7.73   13.234  7.639
	   40388.99  48.70  11.93  12.058  11.814

16	67952.27  16.27  43.70  9.576   6.432
	 68031.40  10.56  53.70  6.206   7.894
	  67777.95  12.81  46.90  7.559   6.920
	   67814.41  16.13  46.50  9.517   6.857
	-
	68031.46  51.30  11.53  7.541   6.781
	 68044.57  40.70  8.48   5.982   4.986
	  67808.13  39.60  15.86  5.840   9.355
	   67818.32  52.90  11.51  7.801   6.791

32	90445.09  15.41  99.90  6.817   11.045
	 90210.34  16.11  100.00 7.143   11.085
	  90221.84  17.31  98.90  7.676   10.962
	   90712.78  18.41  99.40  8.120   10.958
	-
	89155.51  99.90  12.89  11.205  5.782
	 90058.54  99.90  16.16  11.093  7.179
	  90092.31  98.60  15.41  10.944  6.840
	   88688.96  99.00  17.59  11.163  7.933

64	89983.76  13.66  100.00 6.071   11.113
	 90504.24  17.54  100.00 7.750   11.049
	  92043.36  17.44  99.70  7.580   10.832
	   90979.29  16.01  99.90  7.038   10.981
	-
	88615.27  99.90  14.91  11.273  6.729
	 89316.13  99.90  17.28  11.185  7.740
	  90622.85  99.90  16.81  11.024  7.420
	   89084.85  99.90  17.51  11.214  7.861

Run #2. Slower host is replaced with better one. ABC=0.
No runs in backward directions.

	new
	 old

2	24009.73  8.80   6.49   3.667   10.806
	 24008.43  8.00   6.32   3.334   10.524
4	40012.53  18.30  8.79   4.574   8.783
	 39999.84  19.40  8.86   4.851   8.857
8	60500.29  26.30  12.78  4.348   8.452
	 60397.79  26.30  11.73  4.355   7.769
16	69619.95  39.80  14.03  5.717   8.063
	 70528.72  24.90  14.43  3.531   8.184
32	132522.01  53.20  21.28  4.015   6.424
	 132602.93  57.70  22.59  4.351   6.813
64	145738.83  60.30  25.01  4.138   6.865
	 143129.55  73.20  24.19  5.114   6.759
128	148184.21  69.70  24.96  4.704   6.739
	 148143.47  71.00  25.01  4.793   6.753
256	144798.91  69.40  25.01  4.793   6.908
	 144086.01  73.00  24.61  5.067   6.832

Frankly, I do not see any statistically valid correlations.

that "linux" didn't seem to be doing the same thing. Hence my tweaking 
when seeing this patch come along...]

netperf does not catch this. :-)

Even with this patch linux does not ack each second segment dumbly,
it waits for some conditions, mostly read() emptying receive queue.
To model this it is necessary to insert some gaps between
bursted segments or to use slow network.

I have no doubts it is easy to model a situation when we send
lots of useless ACKs. F.e. inserting 20ms gaps between requests.
To see effect on thoughput/cpu, we could start enough of connections,
doing the same thing.

Alexey