netem | The Linux Foundation
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
LINUX. COM
E VENTS
V IDEO
Home
A bout Us
News & Media
Programs
Collaborative Projects
Workgroups
Publications
Events
Training
Login Register
H ome G roups N etw orking netem
12 Me gusta 39 Tweet 71
P RINT
E MAIL
netem
By Linux Foundatio... - November 19, 2009 - 10:23am NETWORKING
Networking
netem prov ides Network Emulation functionality for testing protocols by emulating the properties of wide area network s. The current v ersion emulates v ariable delay , loss, duplication and re-ordering. If y ou run a current 2.6 distribution, (Fedora, OpenSuse, Gentoo, Debian, Mandriv a, Ubuntu), then netem is already enabled in the k ernel and a current v ersion of iproute2 is included. The netem k ernel component is enabled under: Networking --> Networking Options --> QoS and/or fair queuing --> Network emulator Netem is controlled by the command line tool 'tc' which is part of the iproute2 pack age of tools. The tc command uses shared libraries and data files in the /usr/lib/tc directory .
You must register/login in order to post into this group.
Recent Blog Posts
H ow to C hoose an E mbedded Linux O perating S y stem, P art 2 M arch 15, 2013 Q &A w ith M entor G raphics John C herry : A ndroid or E mbedded Linux? M arch 8, 2013 Intro to E mbedded Linux P art 1: Defining A ndroid v s. E mbedded Linux M arch 6, 2013 M andriv a 'Back in the G ame' With E nterprise S oftw are M arch 1, 2013 C ontest Winner Bjarne Rosengren Will F ollow Tux to LinuxC on N ew O rleans F ebruary 28, 2013 Linux 3.8 is N O T a longterm kernel F ebruary 27, 2013 more
Contents
1 E xamples 1.1 E mulating w ide area netw ork delay s 1.2 Delay distribution 1.3 P acket loss 1.3.1 C av eats 1.4 P acket duplication 1.5 P acket corruption 1.6 P acket re-ordering 1.6.1 C av eats 1.7 Rate control 1.8 N on F IF O queuing 1.9 Delay ing only some traffic 2 FAQ 2.1 H ow come first ping takes longer? 2.2 H ow come TC P is so slow ov er netem? 2.3 H ow can I use netem on incoming traffic? 2.4 H ow to reorder packets based on jitter? 2.5 H ow does the v alue of H Z impact N etem? 3 Links 4 C ontact Info
Examples Emulating wide area network delays
This is the simplest example, it just adds a fixed amount of delay to all pack ets going out of the local Ethernet. # tc qdisc add dev eth0 root netem delay 100ms Now a simple ping test to host on the local network should show an increase of 100 milliseconds. The delay is limited by the clock resolution of the k ernel (HZ). On most 2.4 sy stems, the sy stem clock runs at 100hz which allows delay s in increments of 10ms. On 2.6, the v alue is a configuration parameter from 1000 to 100 hz. Later examples just change parameters without reloading the qdisc Real wide area network s show v ariability so it is possible to add random v ariation. # tc qdisc change dev eth0 root netem delay 100ms 10ms This causes the added delay to be 100ms 10ms. Network delay v ariation isn't purely random, so to emulate
1 de 4
16/03/2013 22:13
netem | The Linux Foundation
that there is a correlation v alue as well. # tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
This causes the added delay to be 100ms 10ms with the next random element depending 25% on the last one. This isn't true statistical correlation, but an approximation.
Delay distribution
Ty pically , the delay in a network is not uniform. It is more common to use a something lik e a normal distribution to describe the v ariation in delay . The netem discipline can tak e a table to specify a non-uniform distribution. # tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal The actual tables (normal, pareto, paretonormal) are generated as part of the iproute2 compilation and placed in /usr/lib/tc; so it is possible with some effort to mak e y our own distribution based on experimental data.
Packet loss
Random pack et loss is specified in the 'tc' command in percent. The smallest possible non-zero v alue is: 232 = 0.0000000232% # tc qdisc change dev eth0 root netem loss 0.1% This causes 1/10th of a percent (i.e 1 out of 1000) pack ets to be randomly dropped. A n optional correlation may also be added. This causes the random number generator to be less random and can be used to emulate pack et burst losses. # tc qdisc change dev eth0 root netem loss 0.3% 25% This will cause 0.3% of pack ets to be lost, and each successiv e probability depends by a quarter on the last one. Probn = .25 * Probn-1 + .75 * Random
Caveats
When loss is used locally (not on a bridge or router), the loss is reported to the upper lev el protocols. This may cause TC P to resend and behav e as if there w as no loss. When testing protocol reponse to loss it is best to use a netem on a bridge or router
Packet duplication
Pack et duplication is specified the same way as pack et loss. # tc qdisc change dev eth0 root netem duplicate 1%
Packet corruption
Random noise can be emulated (in 2.6.16 or later) with the corrupt option. This introduces a single bit error at a random offset in the pack et. # tc qdisc change dev eth0 root netem corrupt 0.1%
Packet re-ordering
There are two different way s to specify reordering. The first method gap uses a fixed sequence and reorders ev ery Nth pack et. A simple usage of this is: # tc qdisc change dev eth0 root netem gap 5 delay 10ms This causes ev ery 5th (10th, 15th, ...) pack et to go to be sent immediately and ev ery other pack et to be delay ed by 10ms. This is predictable and useful for base protocol testing lik e reassembly . The second form reorder of re-ordering is more lik e real life. It causes a certain percentage of the pack ets to get mis-ordered. # tc qdisc change dev eth0 root netem delay 10ms reorder 25% 50% In this example, 25% of pack ets (with a correlation of 50%) will get sent immediately , others will be delay ed by 10ms. Newer v ersions of netem will also re-order pack ets if the random delay v alues are out of order. The following will cause some reordering: # tc qdisc change dev eth0 root netem delay 100ms 75ms
2 de 4
16/03/2013 22:13
netem | The Linux Foundation
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
If the first pack et gets a random delay of 100ms (100ms base - 0ms jitter) and the second pack et is sent 1ms later and gets a delay of 50ms (100ms base - 50ms jitter); the second pack et will be sent first. This is because the queue discipline tfifo inside netem, k eeps pack ets in order by time to send. Caveats
M ixing forms of reordering may lead to unexpected results A ny method of reordering to w ork, some delay is necessary . If the delay is less than the inter-packet arriv al time then no reordering w ill be seen.
Rate control
There is no rate control built-in to the netem discipline, instead use one of the other disciplines that does do rate control. In this example, we use Tok en Buck et Filter (TBF) to limit output. # tc qdisc add dev eth0 root handle 1:0 netem delay 100ms # tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 256kbit buffer 1600 limit 3000 # tc -s qdisc ls dev eth0 qdisc netem 1: limit 1000 delay 100.0ms Sent 0 bytes 0 pkts (dropped 0, overlimits 0 ) qdisc tbf 10: rate 256Kbit burst 1599b lat 26.6ms Sent 0 bytes 0 pkts (dropped 0, overlimits 0 ) Check on the options for buffer and limit as y ou might find y ou need bigger defaults than these (they are in by tes) For more explanation about how to use classful queuing disciplines see: Linux Adv anced Routing HOWTO classes
Non FIFO queuing
Just lik e the prev ious example, any of the other queuing disciplines (GRED, CBQ, etc) can be used.
Delaying only some traffic
Here is a simple example that only controls traffic to one IP address. # tc qdisc add dev eth0 root handle 1: prio # tc qdisc add dev eth0 parent 1:3 handle 30: \ tbf rate 20kbit buffer 1600 limit 3000 # tc qdisc add dev eth0 parent 30:1 handle 31: \ netem delay 200ms 10ms distribution normal # tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 \ match ip dst 65.172.181.4/32 flowid 1:3 The commands mak es a simple priority queueing discipline, then a TBF is added to do rate control, then attaches a basic netem. Finally , a filter classifies all pack ets going to 65.172.181.4 as being priority 3. For more info on traffic classification see LA RTC -- filters
FAQ How come first ping takes longer?
The first ICMP pack et in a ping requires an A RP request/response as well.
How come TCP is so slow over netem?
When y ou run TCP ov er large Bandwidth Delay Product link s, y ou need to do some TCP tuning to increase the maximum possible buffer space.
How can I use netem on incoming traffic?
You need to use the Intermediate Functional Block pseudo-dev ice IFB . This network dev ice allows attaching queuing discplines to incoming pack ets. # # # # modprobe ifb ip link set dev ifb0 up tc qdisc add dev eth0 ingress tc filter add dev eth0 parent ffff: \ protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0 # tc qdisc add dev ifb0 root netem delay 750ms A nother way is to use another machine as an Ethernet bridge , and apply netem to both Ethernet dev ices.
How to reorder packets based on jitter?
Starting with v ersion 1.1 (in 2.6.15), netem will reorder pack ets if the delay v alue has lots of jitter. If y ou don't want this behav iour then replace the internal queue discipline tfifo with a pure pack et fifo pfifo. The
3 de 4
16/03/2013 22:13
netem | The Linux Foundation
following example has lots of jitter, but the pack ets will stay in order. # tc qdisc add dev eth0 root handle 1: netem delay 10ms 100ms # tc qdisc add dev eth0 parent 1:1 pfifo limit 1000
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
How does the value of HZ impact Netem?
In the 2.6 line of k ernels, HZ is a configurable parameter that tak es v alues of either 100, 250, or 1000. Because it affects the granularity with which Netem is able to delay pack ets, it is most beneficial to set HZ to 1000, which will allow for delay s in increments of 1ms. See this mailing list post for a more detailed discussion of the impact of HZ. In k ernel v ersions, 2.6.22 or later, netem will use high resolution timers, if they are enabled. This allows for finer granularity (sub-jiffie) resolution.
Links
Linux C onf A u presentation and paper. dummy net an netw ork emulator in F reeBS D N IS Tnet
Contact Info
Since netem is part of the core Linux subsy stem, all bug reports and patches should be sent to Linux Network Dev elopers mailing list. The netem@osdl.org mailing list is av ailable for user discussions. Mail from non-subscribers is moderated to prev ent spam. To subscribe or unsubscribe use the Netem mailing list interface.
G roups:
12 Me gusta 39 Tweet 71
N ETWORKING P RINT E MAIL
Who are we?
The Linux F oundation is a non-profit consortium dedicated to fostering the grow th of Linux. M ore on the F oundation...
Explore
S earch or Brow se N ew s / A nnouncements Linux Blogs / P ublications Linux E v ents / Linux Workgroups M embership / M embers
Stay Current
Linux C onferences & E v ents Linux F oundation P ublic C alendar Linux Training Linux.com Linux F oundation M onthly N ew sletter
About
F requently A sked Q uestions H ow do I get Inv olv ed? A bout / C ontact U s / C areers S taff / Board M embers P riv acy P olicy / Terms of U se / Trademarks
C opy right 2012 Linux F oundation. A ll rights reserv ed. The Linux F oundation, LS B, Yocto P roject, Tizen and IA ccessible2 are registered trademarks of The Linux F oundation. Linux S tandard Base, LS B C ertified, M eeG o, and the Linux F oundation S y mbol are trademarks of the Linux F oundation. Linux is a registered trademark of Linus Torv alds. P lease see our priv acy policy .
4 de 4
16/03/2013 22:13
