Fwd: [PATCH net-next 1/2] netem: rate-latency extension
|Target version:||1st Public Cerowrt release|
and netem is getting better, too.
---------- Forwarded message ----------
From: Eric Dumazet <email@example.com>
Date: Thu, Nov 24, 2011 at 11:14 PM
Subject: Re: [PATCH net-next 1/2] netem: rate-latency extension
To: Hagen Paul Pfeifer <firstname.lastname@example.org>
Cc: email@example.com, Stephen Hemminger <firstname.lastname@example.org>
Le jeudi 24 novembre 2011 à 18:39 +0100, Hagen Paul Pfeifer a écrit :
Currently netem is not in the ability to emulate channel bandwidth. Only static delay (and optional random jitter) can be configured.
To emulate the channel rate the token bucket filter (sch_tbf) can be used. But TBF has some major emulation flaws. The buffer (token bucket depth/rate) cannot be 0. Also the idea behind TBF is that the credit (token in buckets) fills if no packet is transmitted. So that there is always a "positive" credit for new packets. In real life this behavior contradicts the law of nature where nothing can travel faster as speed of light. E.g.: on an emulated 1000 byte/s link a small IPv4/TCP SYN packet with ~50 byte require ~0.05 seconds - not 0 seconds.
Netem is an excellent place to implement a rate limiting feature: static delay is already implemented, tfifo already has time information and the user can skip TBF configuration completely.
This patch implement rate latency feature which can be configured via tc. e.g:
tc qdisc add dev eth0 root netem ratelatency 10kbit
To emulate a link of 5000byte/s and add an additional static delay of 10ms:
tc qdisc add dev eth0 root netem delay 10ms ratelatency 5KBps
Note: similar to TBF the rate-latency extension is bounded to the kernel timing system. Depending on the architecture timer granularity, higher rates (e.g. 10mbit/s and higher) tend to transmission bursts. Also note: further queues living in network adaptors; see ethtool(8).Signed-off-by: Hagen Paul Pfeifer <email@example.com>
include/linux/pkt_sched.h | 5 + net/sched/sch_netem.c | 40 ++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+), 0 deletions(-)
I like this patch, this is a useful extension.
Only point is why you chose ratelatency instead of rate ?
We want to emulate a real link, and yes, a 1000 bytes packet must be
delayed before we deliver it to the device, but its a detail of how
The usual word we use to describe a 1Mbps link is "1Mbps rate" ;)