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 by the
hardware and no longer under the rate-based control of t_ipi.
I think there might be a confusion about what "average sending rate"
actually means. You appear to assume that precise timing control is
needed to obtain a smooth average. I.e., if there are bursts, then
there is no smooth average. But this isn't what the RFC means by
average. The average rate is suppsoed to be smooth *from one RTT to the
next*. Sub-RTT burstiness is *explicitly allowed*, although
implementations should try to avoid it when it's easy to do so.
I have done a back-of-the-envelope calculation below for different sizes of s; 9kbyte
I think is the maximum size of an Ethernet jumbo frame.
-----------+---------+---------+---------+---------+-------+---------+-------+
s | 32 | 100 | 250 | 500 | 1000 | 1500 | 9000 |
-----------+---------+---------+---------+---------+-------+---------+-------+
X_critical| 32kbps | 100kbps | 250kbps | 500kbps | 1mbps | 1.5mbps | 9mbps |
-----------+---------+---------+---------+---------+-------+---------+-------+
That means we can only expect predictable performance up to 9mbps ?????
Same comment. I imagine performance will be predictable at speeds FAR
ABOVE 9mbps, DESPITE the sub-RTT bursts. Predictable performance means
about the same average rate from one RTT to the next.
I am dumbstruck - it means that the whole endeavour to try and use Gigabit cards (or
even 100 Mbit ethernet cards) is futile and we should be using the old 10 Mbit cards???
Remember that TCP is ENTIRELY based on bursts!!!!! No rate control at
all. And it still gets predictable performance at high rates.
Ian do you have any advice regarding test scenarios? Maybe it was utterly dumb of me
to expect we could do gigabit speeds with CCID 3.
Or is there another explanation?
Hopefully this is the explanation :)
Eddie
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
