I have some minor thoughts relating to this.
- In what units are t_nom kept? I would hope microseconds at least, not
milliseconds. You say dccps_xmit_timer is reset to expire in t_now + rc
milliseconds; I assume you mean that the value t_now + rc is cast to
milliseconds. Clearly high rates
On 2/8/07, Eddie Kohler [EMAIL PROTECTED] wrote:
I have some minor thoughts relating to this.
- In what units are t_nom kept? I would hope microseconds at least, not
milliseconds. You say dccps_xmit_timer is reset to expire in t_now + rc
milliseconds; I assume you mean that the value t_now +
- ccid3_hc_tx_send_packet should return a value that is measured in
MICROSECONDS not milliseconds. It also sounds like there is a
rounding error
in step 3a); it should probably return (delay + 500)/1000 at least.
This is used to set a timer to know when to wake up again which is
valid to be
On 2/8/07, Eddie Kohler [EMAIL PROTECTED] wrote:
- ccid3_hc_tx_send_packet should return a value that is measured in
MICROSECONDS not milliseconds. It also sounds like there is a
rounding error
in step 3a); it should probably return (delay + 500)/1000 at least.
This is used to set a timer
Quoting Eddie Kohler:
| The first figure certainly demonstrates a problem. However, that
| problem is not inherent in CCID3, it is not inherent in rate-based
| solutions, and high-rate timers probably wouldn't solve it. CCID3 has
| been tested -- in simulation mind you -- at high rates.
Quoting Eddie Kohler:
| The problem I see is that
|* scheduling granularity is at best 1ms
|* hence t_gran/2 is at best 500usec
|* and so when t_ipi 1ms, packets will always be sent in bursts
|
| So we have a `critical point' after which the average sending rate is
dominated
| For what it's worth, it's as close to in the RFC as it can get without a
| revision. The authors of the RFC agree that we meant the initial
| Request-Response RTT to be usable as an initial RTT estimate; the
| working group agreed; errata has been sent.
So we are RFC-compliant for the
The first figure certainly demonstrates a problem. However, that
problem is not inherent in CCID3, it is not inherent in rate-based
solutions, and high-rate timers probably wouldn't solve it. CCID3 has
been tested -- in simulation mind you -- at high rates. The problem is
a bug in the Linux
| | For what it's worth, it's as close to in the RFC as it can get without
a
| | revision. The authors of the RFC agree that we meant the initial
| | Request-Response RTT to be usable as an initial RTT estimate; the
| | working group agreed; errata has been sent.
| So we are
On 13/01/07, Gerrit Renker [EMAIL PROTECTED] wrote:
I have a snapshot which illustrates this state:
http://www.erg.abdn.ac.uk/users/gerrit/dccp/dccp_probe/examples/no_tx_locking/transmit_rate.png
The oscillating behaviour is well visible. In contrast, I am sure that you
would agree that the
10 matches
Mail list logo
