CCID 3 bounded by OS scheduling granularity

CCID 3 bounded by OS scheduling granularity

[Gerrit Renker]

I have performed experiments which confirm that

 1) when t_ipi < t_gran, the transmit rate is effectively out of control
 2) when t_ipi > t_gran, the actual transmit rate is about a factor of 3
    higher than s/t_ipi would permit.
    
http://www.erg.abdn.ac.uk/users/gerrit/dccp/docs/packet_scheduling/

Re: CCID 3 bounded by OS scheduling granularity

[Ian McDonald]

On 1/23/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> I have performed experiments which confirm that
>
>  1) when t_ipi < t_gran, the transmit rate is effectively out of control
>  2) when t_ipi > t_gran, the actual transmit rate is about a factor of 3
>     higher than s/t_ipi would permit.
>
> http://www.erg.abdn.ac.uk/users/gerrit/dccp/docs/packet_scheduling/

I've been going over this and wonder if you ever got to the bottom of
it by instrumenting it or similar as it doesn't make sense to me....
We add t_ipi to t_nom after each packet so even coarse grained
scheduling shouldn't do this.

Ian

-- 
Web: http://wand.net.nz/~iam4
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Re: CCID 3 bounded by OS scheduling granularity

[Gerrit Renker]

|  > I have performed experiments which confirm that
|  >
|  >  1) when t_ipi < t_gran, the transmit rate is effectively out of control
|  >  2) when t_ipi > t_gran, the actual transmit rate is about a factor of 3
|  >     higher than s/t_ipi would permit.
|  >
|  > http://www.erg.abdn.ac.uk/users/gerrit/dccp/docs/packet_scheduling/
|  
|  I've been going over this and wonder if you ever got to the bottom of
|  it by instrumenting it or similar as it doesn't make sense to me....
|  We add t_ipi to t_nom after each packet so even coarse grained
|  scheduling shouldn't do this.
The graphs on that web page are actually the result of instrumenting the kernel.
There are further instrumentation tests, the results of which are on 
http://www.erg.abdn.ac.uk/users/gerrit/dccp/docs/impact_of_tx_queue_lenghts/

The problem is not in adding t_ipi, but rather in schedule_timeout which works
at HZ granularity.