Menu
▾
▴
Re: [Lksctp-developers] RTO update
|
From: Vlad Y. <vla...@hp...> - 2007-12-21 17:20:39
|
Johan Eklund wrote: > Hi again Vlad > > Let me start by answering your questions. > Q1: The Hz was the default value 250 > Q2: Yes, I use the jiffies_to_msecs(), > so your assumption was correct. I have mow modified my kernel and the > frequency (Hz) is set to 1000. This helped me, just as you said, to have > a value of 3 ms for the rttvar...I have also noticed that 3 ms is the > minimum value I can get with this algorithm, 0 is not possible since > the calculation only treats integers. You will never get 0. The smallest value possible for rttvar is 1 jiffie, that's the scale factor for lksctp implementation. I've seen rttvar of 1 on with extremely short rtts. -vlad > > Thanks > > /Johan > > -----Original Message----- > From: Vlad Yasevich [mailto:vla...@hp...] > Sent: den 20 december 2007 19:58 > To: Johan Eklund > Cc: Kar...@ti...; 'Per Hurtig'; 'Anna Brunstrom'; > lks...@li... > Subject: Re: [Lksctp-developers] RTO update > > > > Hi Johan > > After running a bunch of test on my own and I think I found your > problem, but before I explain let me ask you 2 questions: > > 1. What is the HZ value for the kernel you are running? > > 2. Did you do jiffies_to_msecs() on the rttvar value? > > > I am betting that the HZ value is 250 and that the answer to Q2 is > yes... > > Now, for the explanation. > > The rtt variables are stored as jiffies and all the arithmetic is done > with jiffies. If you print the jiffie value for rttvar, you'll see that > it's set to 3. > > Doing rttvar arithmetic with the value of 3 produces: > > rttvar = 3 - (3 * 1/4) + (abs(0) * 1/4) = 3 - 0 + 0 = 3 > > You can change HZ to 1000 and have a 3 ms rttvar. > > -vlad > > > Johan Eklund wrote: >> Hi again Vlad and others >> >> Thanks for the quick reply. I understand there is a problem when >> calculating the RTO in the case you describe in your answer (when SACK > >> delay is involved). Nevertheless I am not certain that my question is >> related to the SACK delay. I have conducted another experiment where >> the SACK delay is set to 0 ( = disabled, a SACK is sent for every >> packet). I have also extended my trace so the rttvar and the srtt is >> printed every time the RTO is updated. One fraction of this trace is >> found here: >> >> Dec 13 05:27:25 server kernel: JE rtt= 84 >> Dec 13 05:27:25 server kernel: JE SRTT= 84 and RTTVAR= >> 12 >> Dec 13 05:27:25 server kernel: JE --------------TSN and RTT > when >> RTO updated---------- >> Dec 13 05:27:25 server kernel: JE tsn_nr 174730406l >> Dec 13 05:27:25 server kernel: JE rtt= 84 >> Dec 13 05:27:25 server kernel: JE SRTT= 84 and RTTVAR= >> 12 >> Dec 13 05:27:25 server kernel: JE --------------TSN and RTT > when >> RTO updated---------- >> Dec 13 05:27:25 server kernel: JE tsn_nr 174730415l >> Dec 13 05:27:25 server kernel: JE rtt= 84 >> Dec 13 05:27:25 server kernel: JE SRTT= 84 and RTTVAR= >> 12 >> Dec 13 05:27:25 server kernel: JE --------------TSN and RTT > when >> RTO updated---------- >> Dec 13 05:27:25 server kernel: JE tsn_nr 174730424l >> Dec 13 05:27:25 server kernel: JE rtt= 84 >> Dec 13 05:27:25 server kernel: JE SRTT= 84 and RTTVAR= >> 12 >> Dec 13 05:27:25 server kernel: JE --------------TSN and RTT > when >> RTO updated---------- >> Dec 13 05:27:25 server kernel: JE tsn_nr 174730433l >> Dec 13 05:27:25 server kernel: JE rtt= 84 >> Dec 13 05:27:25 server kernel: JE SRTT= 84 and RTTVAR= >> 12 >> Dec 13 05:27:26 server kernel: JE RTO rto= 132 >> Dec 13 05:27:26 server kernel: JE SRTT srtt= 84 >> and_RTTVAR= 12 >> Dec 13 05:27:26 server kernel: JE RTO rto= 252 >> Dec 13 05:27:26 server kernel: JE SRTT srtt= 84 >> and_RTTVAR= 12 >> >> Here it is seen that rttvar is 12 ms all the time although the RTT is >> 84 for all consecutive samples and the RTTVAR is kept at 12 ms. >> >> According to the calculation of RTTVAR: >> "RTTVAR = RTTVAR - (RTTVAR * rto_beta) + (abs(srtt - rtt) * > rto_beta)); >> where rto_beta is 1/4" >> The value of RTTVAR should decrease as there is no variation between > the >> samples: >> RTTVAR = 12-(12 * 1/4) +(abs(84-84) * 1/4) = 12-(3) + (abs(0)*1/4) = >> 12-3 = 9 >> >> And for the nextcalculation it would decrease to: >> 9-(9 * 1/4) +(abs(0) * 1/4) = 9-2 = 7 >> And so on... >> >> This would make the RTTVAR approach 0 since there is no variation. I >> can see the RTTVAR has decreased from initial 84/2 = 42 to 12, but why > >> doesn't it continue to decrease below 12 ms? That I don't understand. >> (I am concerned in evaluating the time for the failover failover >> procedure. The high RTTVAR is crucial for the failover time since it >> is increasing the RTO severely...) >> >> I hope you, or someone else, understand my question and are able to >> give me a reasonable explanation. Thanks! >> >> Regards >> >> /Johan >> >> -----Original Message----- >> From: Vlad Yasevich [mailto:vla...@hp...] >> Sent: den 19 december 2007 16:12 >> To: Johan Eklund >> Cc: lks...@li...; 'Anna Brunstrom' >> Subject: Re: [Lksctp-developers] RTO update >> >> >> >> Johan Eklund wrote: >>> Hi >>> I am running an experiment using the 2.6.16.16 kernel version. In >>> the experiment, data is sent over a dual homed network (two >> disjunct >>> paths between two different interfaces on eack machine). >>> One way link delay is set to 40 ms and the traffic pattern is static, > >>> one small packet is sent every 10 ms, the link is not overloaded. I >> use >>> a limited RTO space where the minimum value is set to 80 ms, while >>> the maximum value is 250 ms. In my experiment the primary path is >>> broken after a few seconds and the RTO-timer times out. Since the rtt > >>> is >> about >>> 80 ms ( 40 ms oneway) I expect the RTO-timer to be slightly above 80 >> ms, >>> since I expect the rttvar to be small >>> (from RFC 2988: RTO <- SRTT + max (G, K*RTTVAR), where K = 4)). >>> >>> To verify the RTO-timer and the failover behaviour i have added a few >>> trace lines in the kernel log. I have extracted a few lines from the >>> trace here: >>> >>> >>> Nov 28 06:00:47 server kernel: JE rtt 92 >>> Nov 28 06:00:47 server kernel: JE --------------TSN and RTT >> when >>> RTT updated---------- >>> Nov 28 06:00:47 server kernel: JE tsn_nr 654813719 >>> Nov 28 06:00:47 server kernel: JE rtt 92 >>> Nov 28 06:00:47 server kernel: JE --------------TSN and RTT >> when >>> RTT updated---------- >>> Nov 28 06:00:47 server kernel: JE tsn_nr 654813729 >>> Nov 28 06:00:47 server kernel: JE rtt 92 >>> Nov 28 06:00:47 server kernel: JE --------------TSN and RTT >> when >>> RTT updated---------- >>> Nov 28 06:00:47 server kernel: JE tsn_nr 654813739 >>> Nov 28 06:00:47 server kernel: JE rtt 92 >>> Nov 28 06:00:47 server kernel: JE --------------TSN and RTT >> when >>> RTT updated---------- >>> Nov 28 06:00:47 server kernel: JE tsn_nr 654813749 >>> Nov 28 06:00:47 server kernel: JE rtt 92 >>> Nov 28 06:00:48 server kernel: -----------timeout!!------------- >>> Nov 28 06:00:48 server kernel: JE seq_nr= 654813759 >>> Nov 28 06:00:48 server kernel: JE RTO rto= 140 >>> Nov 28 06:00:48 server kernel: JE SRTT srtt= 92 >>> and_RTTVAR= 12 >>> Nov 28 06:00:48 server kernel: -----------timeout!!------------- >>> Nov 28 06:00:48 server kernel: JE seq_nr= 654813777 >>> Nov 28 06:00:48 server kernel: JE RTO rto= 252 >>> Nov 28 06:00:48 server kernel: JE SRTT srtt= 92 >>> and_RTTVAR= 12 >>> >>> Here it is seen that the rtt-values are stable (92 ms), but as the >>> timer times out (after "timeout") I find the rto to be 140 ms!. This >>> is OK, according to the RTO-calculation RTO = SRTT + 4* RTTVAR = >>> 92+4*12=140 ms. My question is: Why is the RTTVAR 12 ms when traffic >>> is stable? My assumption was to find a small value of RTTVAR, which >>> would have given a RTO-value slightly above 92 ms? >>> >> RTTVAR start out at 0 and at the first RTO measurement is set to be >> 0.5*RTT. (in your case 46). >> >> For ever RTO measurement after that, RTTVAR is set to >> >> RTTVAR = RTTVAR - (RTTVAR * rto_beta) + (abs(srtt - rtt) * rto_beta)); >> >> where rto_beta is 1/4. >> >> There is an interesting issue though in the way the SCTP spec is >> written and the calculations are done. >> >> There is a bug however in lksctp for when the RTO calculations are >> done. Right now, we compute the RTO for every new SCTP DATA chunk we >> send. However, since SCTP mandates delayed SACKs (i.e SACK ever other > >> packet), we can a fluctuation since the RTT for the first chunk would >> be double of the actual RTT. >> >> TCP gets around it by sending back the timestamp of the first DATA >> segment so that the proper RTT can be computed. >> >> So may be the RTT needs to be computed for the largest TSN SACKed... >> I am trying to figure it out. >> >> -vlad >> >>> Does anyone have an explanation? >>> >>> Regards >>> >>> /Johan >>> >>> >>> >>> ~~~~~~~~~~~~~~~ >>> Johan Eklund >>> Karlstad University >>> phone: +46 (0)54 700 1954 >>> Office: 5A 437 >>> url: www.cs.kau.se/~johane >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> - >>> --- >>> SF.Net email is sponsored by: >>> Check out the new SourceForge.net Marketplace. >>> It's the best place to buy or sell services >>> for just about anything Open Source. >>> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marke >> tp >> lace >>> _______________________________________________ >>> Lksctp-developers mailing list >>> Lks...@li... >>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers >>> >> >> >> ---------------------------------------------------------------------- >> --- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services >> for just about anything Open Source. >> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp > lace >> _______________________________________________ >> Lksctp-developers mailing list >> Lks...@li... >> https://lists.sourceforge.net/lists/listinfo/lksctp-developers >> > > |