Stephen Hemminger wrote:
The bigger problem is that too be effective rate control needs accurate
real time. Linux is doing better at real time, but still providing useful
high speed inter packet spacing is beyond the current capabilities. To get
around this I think most high speed 10G cards provide some form of rate control
in firmware.
-
I understand that timed intervals between individual packets is not
realistic in general. What I have in mind is a fixed granularity
transmission timer, where packets are assigned to buckets, and
transmitted one bucket per timer expiration.
>From a protocol design point of view, the main question is which is
more expensive, rate based timer expiration, or generating ACKs at a
high enough rate to self clock. With 1 Gb/sec reliable transport
protocol, every other packet ACK generation, and Ethernet MTU size
packets, ACKs are generated every 30 usec on average. With Van Jacobsen
style pre-queuing a large percentage of them are wasted overhead,
because a long series of them accumulate in the prequeue before the
receiving thread is activated.
Rate based pacing would trade the overhead of every other packet ACK
processing for the overhead of transmission timer handling. If the
transmission timer runs at a rate comparable to the thread dispatch rate
for VJ-style prequeueing, the total rate based pacing overhead should be
lower with superior performance.
- Mark B.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
