Re: MFC status for retransmit timer min/slop

> Wow. I'm flattered. Everyone so far thinks 200ms will be ok! I'd still prefer the default left at 1 sec until there is enough real testing so that people not taking part in the test don't get surprised. That is, "dampen" any potential future oscillations in this value. To Unsubscribe: s

Re: MFC status for retransmit timer min/slop

In message <[EMAIL PROTECTED]>, Matthew Dillon w rites: >Wow. I'm flattered. Everyone so far thinks 200ms will be ok! > >Its up to Jonathan Lemon now. Jonathan, if you sign off on 200ms >for the MFC I'll go with it. Even if everybody agrees to 200msec I think it is far too early f

Re: MFC status for retransmit timer min/slop

Wow. I'm flattered. Everyone so far thinks 200ms will be ok! Its up to Jonathan Lemon now. Jonathan, if you sign off on 200ms for the MFC I'll go with it. -Matt Matthew Dillon

Re: MFC status for retransmit timer min/slop

On Sun, 21 Jul 2002, Matthew Dillon wrote: > I believe the basic concept and code is reasonable and the only real > issue is whether to make the default slop 1000ms or 200ms. I would very > much like to change the default to 200ms in -stable but I will be happy > to MFC the code

Re: MFC status for retransmit timer min/slop

200ms is fine with me. cheers luigi On Sun, Jul 21, 2002 at 12:45:00PM -0700, Matthew Dillon wrote: > I am going to be MFCing the transmit timer min/slop stuff soon (because > the vast majority of complaints by users related to this issue is > on -stable). > > I

MFC status for retransmit timer min/slop

I am going to be MFCing the transmit timer min/slop stuff soon (because the vast majority of complaints by users related to this issue is on -stable). I believe the basic concept and code is reasonable and the only real issue is whether to make the default slop 1000ms or 200ms