Quoting Mark Handley: | On 12/1/06, Colin Perkins <csp@xxxxxxxxxxxxx> wrote: | > I'd actually suggest something on the order of 16-20ms. The rationale | > would be to match the typical inter-frame interval for multimedia | > applications, so that the kernel will likely be processing a sent | > packet when the timer expires, and can amortise the costs of checking | > the nofeedback timer into the send routine. | | You make a good point. The cost of checking the timer should be | fairly low if you're already in the DCCP send code for the relevant | connection. You have to reset the timer anyway every time you get | feedback, and checking the timer shouldn't be more expensive than | resetting it. As you get feedback every RTT under normal conditions, | you ought to be able to check it at least once per RTT so long as | you're in the DCCP code anyway. | | Now, do you every need to check the timer when you're not in the DCCP | send code? I think not. It's not like TCP, where you need to send a | packet on RTO expiry. I think it should be possible to only ever | check the nofeedback timer when you're in the send code for that | particular DCCP connection. And if so, then surely you can afford to | check it as often as you reset it - ie around once per RTT? | | You just have to be a bit smart - if you go to send and discover that | the timer should have expired multiple times, then you have to process | multiple backoff events, and perhaps reschedule your send for later | after you've done that. Once again thanks to both answers - both value range will be made configurable and a default value of 100ms will be provided. With a default of 10ms, one is close to the timer granularity of 100HZ on some systems. I will also add the helpful information provided to the configuration menu. Gerrit
