delayed acks after fast recover

Andrea Arcangeli (andrea@e-mind.com)
Wed, 25 Nov 1998 22:09:57 +0100 (CET)


David, in 2.1.129 you have fixed the sender case (doing congestion
avoidance only if we are in fast-retrans) but if I understand the code
well that has nothing to do with the delayed ack problem I reported to you
(since I am always the receiver).

I have to say that disabling delayed acks was a lazy approch ;-).

With 2.1.129 I get this trace for example:

08:48:12.126249 141.76.20.99.ftp-data > 195.223.140.60.1044: . 1025:1281(256) ack 1 win 32512 [tos 0x8]
08:48:12.126320 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 1281 win 31744 (DF)
08:48:12.756297 141.76.20.99.ftp-data > 195.223.140.60.1044: . 1537:1793(256) ack 1 win 32512 [tos 0x8]
08:48:12.756392 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 1281 win 31744 (DF)
08:48:12.836279 141.76.20.99.ftp-data > 195.223.140.60.1044: P 1793:2049(256) ack 1 win 32512 [tos 0x8]
08:48:12.836371 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 1281 win 31744 (DF)
08:48:12.916282 141.76.20.99.ftp-data > 195.223.140.60.1044: . 2049:2305(256) ack 1 win 32512 [tos 0x8]
08:48:12.916377 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 1281 win 31744 (DF)
08:48:12.996282 141.76.20.99.ftp-data > 195.223.140.60.1044: . 2561:2817(256) ack 1 win 32512 [tos 0x8]
08:48:12.996362 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 1281 win 31744 (DF)
08:48:14.136320 141.76.20.99.ftp-data > 195.223.140.60.1044: . 1281:1537(256) ack 1 win 32512 [tos 0x8]
08:48:14.136406 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 2305 win 30720 (DF)
08:48:14.766347 141.76.20.99.ftp-data > 195.223.140.60.1044: . 2305:2561(256) ack 1 win 32512 [tos 0x8]
08:48:14.766454 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 2817 win 30976 (DF)
08:48:14.836352 141.76.20.99.ftp-data > 195.223.140.60.1044: . 2561:2817(256) ack 1 win 32512 [tos 0x8]
08:48:14.836422 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 2817 win 31744 (DF)
08:48:15.576381 141.76.20.99.ftp-data > 195.223.140.60.1044: P 2817:3073(256) ack 1 win 32512 [tos 0x8]
08:48:15.656384 141.76.20.99.ftp-data > 195.223.140.60.1044: . 3073:3329(256) ack 1 win 32512 [tos 0x8]
08:48:15.656465 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 3329 win 31744 (DF)
08:48:15.736384 141.76.20.99.ftp-data > 195.223.140.60.1044: . 3329:3585(256) ack 1 win 32512 [tos 0x8]
^^^^^^
08:48:16.206425 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 3585 win 32512 (DF)
^^^^^^

So I implemented a my own new heuristic to try to improve the delayed acks
calculation. At first I think that using tp->ato for disabling delayed
acks is a bad choice because doing that we lose the good history
information we achieved in the past.

So here my delayed acks implementation against 2.1.129 (that is just
included also in arca-31 to allow unstable people to give a try). The only
thing I am sure is that the patch can' t harm it could only increase o
decrease the performance (I think the first is true).

Basically I try to account only the delays between two consecutive packets
in the delack estimation. When the delack timer expires I return to probe
the tp->ato but at the first two consecutive packets from the other end I
stop the probing and start the regime accounting.

The patch is against 2.1.129 and incidentally includes also some little
*_before() stuff and a no-PROC_FS-config-allow fix.

begin 664 delack.gz
M'XL("+YN7#8``V1E;"UA8VLM,RYD:69F`+U:Z6[;2!+^33U%Q<%D1$N41?F(
M+1\;'SF,.+;7SNS,+@8@:+(I]8HB%;)IQ3/Q/OM653=U'V,LL`H@6F15=W75
M5R=SF83B>QMBF13?MV02Q$4HMA*AME0P:'0KH8PB<(IES]MN@_^M>]YH-=R*
MXSCKZ*P/F83K]!%:36@VVTVWW7H+[L'!?J56JRUCMGX5H6;:A9;;WMY'/LWT
M[ATX^VZS[K:@1M<]>/>N`I:E!LY))E3F)WE?JAR.CZ%I'U;@N0(59VL3OG9E
M#DK$,7YW!<AD4"@89&D@\EPF'1CXJHM/?`5^`J?GGR'OID4<0B>%M%`5!S8A
MDYVN@B0=-NCG5L5Y'8I()@)09$\D2F3>MT(&/3_H>?TT%%7/4P/;JNJK<^*K
M%(ZA^NE?6VZS:=O3_#+Y"\Q3W!78VJP`RG4E<Y0ZCB%7OA(YI!'X\/7\%O(T
MZ`FE3Q7@L1X$/$HQ1-7Z.9)L!&F2B$")<(/78?8&:%7A,<&8):?%O/M_7GMW
M[\__4<>M%.JFTX5+\/M(J.`)=XF*.'ZJ7"[#'LFR$GR:8`7ZI@E6P&^:\*7X
MT]RK`=@ZV$7@U>CB-C4`<Y45@8)T(!(O$]\*D2MK<S-_2KRA+Y47^[E"-"*A
M3!30[0>T=)QV#BT$YYG^FRR7B4#(1]P<]9T3RFI6D>2RD^`M8@U%7$+DL%(S
M"++(0!?OKQ"WWNW=S=GE]4>KZAX=->V%)'?O/UY^><\4[F**B\O[T[,K3=*R
MT8M8=K"F[4OJDH/''?SR^G[^K1',V'>>8,:^RPEF[+N<<-Z^N]NS]IWGGN%R
M=]O;!Q/V=7=WV,!T=7>TA3&Z%%F"!E(FK-30_VJP:?V:^8.!R"!]Q"]4I/)R
M$:-?>7X89E6;:-",Q78+S/93SPUP0O$H`P&;>*T#T8:YJK/%\P!!A:O\B5`P
M,LQMPES,H:D1&L^56@5>RPB-"^<WUQ\N/Q(TSKT/]Q7V=!F`V9JBH!?*C&)8
M]F1M\F_:P8B+0>OZEZLK@H!6SGZ3E(+:V=\OX^_EK??E]/[OB)^S7SY6W3IL
M%$DF.AB91$;A]?>-+5K66(*7W?HI_WT#>,_?DXTZ!7$+?SDGB=^G$X#%@HS7
MJ<X*5@>FC],AAL\469QG#(L8[2D^KS6+CN'_JUF</RO."\S"P`$/Y94J*I*@
M:DSQF,H06`@^)#VNTCT,]"M=SO,+E4;#M9XWHEOC@'-T:_QPCGZ!.^ZL<\?1
M(JN]<GMON_X6:OJBLSY^$I5VXZH?(0XPQF)*4WZ@[+IY2O<#%:-253I[+\U4
M'8U''^97LB^RAO@^D)G(C_Z-^I28^_X&36C#W'/'/+?K&`AX#7KL/8@HS<3\
M<O62?-UZDT)&L=_);9TVK$&:'S^@)R2U6"2'2U&!"HAD9Q4>2HKE2)BE6(Z!
M6<H7!N.2?;7=#]ZVR.[Z0G9_+1(\'2L%@XOJ53<:&QPP+%(BAJO2=C4@'6/]
M=DAV'G9E+*!:/CQB,GCS!E[)P.ND"O/V('ZRR9R&=-*DI7V8RU[`-A-L,2+>
M7M]Z9S<W7V_9IC*"*G(\I*D:>&1:6YMZ=`]3_V/57F9:721BU;K<MA,DRXR[
M@`2MN[W(N@M(%YBWN=2\$_RSU=3;]N[^V+Z[7$SA]SY;%T,W?89IUH.AI%)3
M5SU/5+<&O;P!FN8400"?8R&2MF7=ZDH>RW@J>7-FA-O[3Y!C:2H3JOE'*T<8
M)[C>;W#ZIH4RX<-IAC5R1\2R;=T)K'IUS16D_4$L5/S$;<.D')J9)*6]^D^0
MB"%T19%ALI)!@[;;(M=];:I+.-(*,J#OGFAP[]5;!&[,I"US_*U1@N:L0'HT
M51\6E;*/G<`H/=&S=*!@$WN$"E`JDE&56B'3+C1MOLG=49P%CP3HL7]@E6#E
M*'W0A9*)T$^%!I>I?2)`2/M%K-ITDPH>R\)6X30(TB)18YU@;Z&&:`K4M9-F
M(6;<42%;FB1-L#_0[.@*0P%^)JCV>*#ZH(KRXJ$S!=P%H;HG56T;OC0CUO&F
MV*?TA9\7&=*5`JAABD9+<A$4"O<WG*4049;V>8$4OS*L'\*&H>"NAQL?S.T#
M$<B(=G]XPG[P">X^G-/FJ&Y'(AX@S/Q(P>F'R\^&VT^P/%<_0SX!&)]`(4/A
MU^$!,7R)^\JD5S:6?;]7"D?RC(`#?8PVJ+U8^@^Q**5#C!)[7N(L$CZ6'(+:
MNI]!P0,"N%=*FAM125+#/I87]13X13X-93:%#_>?;GZYNH!#&ZJY$).LCA0J
M<LR:#JJW0U\J2V.GZ3;4=T5;XM:NVVH98\W[%53]G@^.C[]M:.UP0-#!@^BW
M&'611N)$EP-OH#K?WOR8:V=LWI>Q:_4G<H`#D^`_Y.=+W8&?8D-V>WIW>GUS
M>0%!5P0](QSY5A^.R*MTRJ=MW)*+'Y[P9IGV([.1;OO-?;V_B',Q2S!RVY,3
M<&U,7>Q]UO.4WUVRXZ!64:YP+B(!5<IX(B0)4\9%(H@L+9T`G4T02AAB!-DA
M(\AX'N[M&[\F7Z4J5V04<I).B07:+&],"4/0(9^12;F]3+!:]PGA&,%Y^(!D
M7?]10$>HTE_@T8\QN.6BTQ<<2&@\@]R-$CWT8:RLA<<\%$9&GB(\AO_,`XF5
M/++'+,^/X_G5J1YCF\"=T(J;L@$6]2EF)B73Q(_CIX8&O#G`&IE,V\TRL4O3
M7X&/WMILE^R+<`LLSB<1#U"A"47?6)"^<VR-IL,JEY<<<E#?.8?E@KHCE->/
M@>"'=BG0"J"53KECR70+4PZ55<]`VM-IAI/&"M]S5N4B9\K!G+%_.?/.Y2SV
M+<>8TEGK62P)ZNS7*0!O\`G)CAM`9VP8%4PDU:.I&=ST/N6#S99]6)I+/Z(H
M@>4AEOZX)VU&CLE)2P=CG3JT/W.Z78*7*3B.$3PJB)]U@TF%A=LZH*K9W=LK
MNZ5R,82J1U"MU0ZILZ#AJ$R>G$[F]V<*)\I14.0\#S4`8I4`:Z3KG`SR+E7"
MU;SW@$;%['NDM=W/<R^@(*5UKE4U5@?J:;=YN.B`TPXW\@=X!BJE4-1S="J.
M:9QH"T5Y*^^GE,Y#R)0"4R.A[;Z2.GWE8[)D!L*\5LWVVSW6S8X[:B4IM+S"
M3"<RSC;WG\^\\S,ZE^V<H':QK?]6UT`+'KWDN[*ILM)^=PKCP7,=6AA6^RE6
MF"A?/TV`W+<!\"'-`HJY@*@/I4]R!SVC3.O^A@[+HY.\5X>-\7JC,JJ-!OD&
M/_U&HQ*8DQ"?L3.N=M87Z-NR>E$FA(?+\Q9\2X\Y#AEG6H\'+:U'QAKI4>/I
MIM<8U5-X9*S@O33R=%UH(GX=HE(C8T4L0"@>:LV9_NJ1M&@7,J>Z"NLMGZ09
M8.G(L7I"`KK'#5J.4$68\E%W]UK8G]3<W8,#TZ<P9*K5"4R8>$>_AL7`AI/C
MT6]T"(RZ7TY_8[G^Z:%H-OSX@:L`?G0@&LHXAF(0$C@H%`QE$F+\WJ!.1$82
M$S56E1M8:34:1EKB)>UDOLR%I^G17+RR,[$R:P^=P,0WW%S'M_%:SFBMN1<1
MJ&9:KU:N=V&R':Z2`_:_$&J5AN/B6IL#/2"DT):+.!KOI-=9G<:-T>8TQ$4$
M]8,I+4CV8_\>Z8*@Z@V$Z%7?T/J3N,-#B4+8\$H/,R?<%\,$8Q`EY;<>N-J*
M#AS_6-.`,\7*_GN*8MEP99[R1<.5,?N"YGMBN.)N[[>H_>9K.5;##H/T5V0=
MCQ7,;@`ZNN1/R3<]GV0J'1D,P\1[#<U3&SU:G\5`UW>C5(+>L[N]IX<D9A&:
M\&$D[GBY_(.6*6DICZTP&N)@[=RDI%EEN%D:--W.,M/-TK[8>.4",^;;V6GO
M-"=FHDT>B38G9B<7_B,6UO<-^(+Q1&16VSKO^EE'8*N,=?\3YG-JN,E-]0M-
M5.)H-!(6/*U'.VZ11XS?CS86K@UMZX;%Q`C3H3>9IOD5V#UD8IA)I43";TO_
MSY.6T8MD/639V:?8O5,F*6M^>H)@>H/0<T[4P!O()$H;?N3A<S-]G4U,&MUZ
MVK(D9LZ4/+/%X9I.8-1JL,\%6,YGWG>L!SP>&G.5\!4)O`M*)(?CJN]@=Y]G
MI7P9OQDW.TU-G*EP+J>C2.:'H5G\S2P';5!^ILK]2(](*2(?P;)][%'G-C%-
M-6SUY5S:\5$WRZ2JE^+;AV7ENSP$Z+571@!#LBH`S)"L"MTSI"]V?\._)GB_
M=;G^PHOKED5)]17A^`]Z^15B<:Y3XP)H-Z8`/4G(_Q&`,B4!\OSJYO[]:"R(
M^?(^[0N:9'4P^:/+#[.4(D9JI@ODNW@0GM[Z'1^;JLG^=YD8BVNWR=3`J8<*
C<:2E$H=\R'0[XS$IBV#P,GIK'I-\E,;LRG\!PT/[H!HC````
`
end

Andrea Arcangeli

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/