Re: Sending packets out of schedule?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Soo-Hyun Choi,

>> may I ask a simply question? Is it possible to send DCCP packets at
>> other times than those calculated by the rate control? I mean, is it
>> possible to call a send socket call with an option saying, send this
>> packet immediately no matter that the rate control is saying to you?
>> 
> In my opinion and experience, this is possible - after all, DCCP
> calculates the *suggested* sending rate.

Cool. Thus, I just have to change the ccid3_hc_tx_packet_sent function in ccid3.c.
If, for example, a packet is mark as urgent (somehow), then I can drop the scheduling of packet transmission [RFC 3448, 4.6] but send the packet immediately?
 
> For example, the calculated inter-packet interval is 0.1 ms over a
> general purpose PC (installed a modern Linux kernel). Also, assume the
> host OS clock granularity is 4 ms (i.e., 250 Hz) - well, some Linux
> kernels have configured at higher rate than this but not more than
> 1000 Hz. Then, there would be the cases that the OS clock did not
> schedule the real-time application in time such that the application
> cannot actually maintain the calculated inter-packet interval correctly.
> 
> When the application is scheduled next time, the application would
> need to send the packets which have not been able to transmitted due
> to the OS clock granularity.
> 
> Caveat:
> What we need to be careful is that the application should not send
> much faster than the DCCP rate, because it may introduce (unwanted)
> persistent packet losses. As we know, the packet losses can degrade
> the performance of the multimedia applications significantly.

Yes, of course. 
> 
>
>> The role of DCCP would be to calculate the proposed sending rate and
>> to measure the network round trip time. This data is then used by an
>> application specific rate control.
> 
> Correct.	
> 
>> 
>> The background of my questions is based on the experience, that
>> real-time packets shall be send immediately, especially if a
>> scenario of very interactivity is given, and that some codecs cannot
>> change their sending rate immediately but need some extra time (e.g.
>> one or two additional frame periods). Thus, a less strict sending
>> schedule would help.
>> 
> 
> You might want to change the codec itself to interact with DCCP in
> real time, so that the codec can change the necessary parameters
> (e.g., various encoding parameters) when needed.

Yes, that is what we are doing. However, due to calculation speed and queuing, this cannot happen immediately but only with a slight delay. Also, we need to support a frame size of 2.5 ms instead of 10ms. This should be still ok?

Anyhow, thanks for the fast and excellent answer.

Greetings
 Christian





[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux