Cfrtjryk

I would like to study the behaviour of an application streaming from a slow server. I'm trying to take advantage of tc-netem to introduce a network delay.

Before setting up a more complicated scenario, I decided to do this on a virtual machine, which is supposed to emulate the slow server. I access the VM via ssh, so I decided to create a virtual ethernet which will be delayed, while I plan to use the real ethernet device for management.

First I created the fake interface with ip link add link eth0 type macvtap and I assign it with an IP address.

Then I added a 40 milliseconds delay with tc qdisc add dev macvtap0 root netem delay 40000. This effectively allowed me to have a throughput drop (from ~250 MiB/sec to ~6 MiB/sec).

At this point I tried to play a bit with my setup, and I started to realize that the delay was not just affecting the macvtap0 device, but also the eth0 device I was connecting through (in short, my ssh session started to lag).

I think that my netem delay affected the actual NIC. Is this due to the fact I'm working within a VM? Or should I have used something different tan macvtap? Or could it be because I applied my changes to the root qdisc?

EDIT - This is the first time for me entering the apparently huge world of traffic differentiation. Perhaps there's a better approach to this? E.g. can I set up a queue to slow down a selected process? I decided to rename this question to reflect my actual purpose.

I'm not sure about the problem you have, so I'm skipping that.

If you want to fiddle with traffic shaping per process you will need to use a classful queuing discipline. HTB or HSFC are probably your best bet. Using that you can create a tree of queueing disciplines (netem can be attached to one of the leaves) and assign traffic across them with tc filter.

Filtering is quite flexible because of the fw filter method wich can look for an iptables mark, which in turn means that you can select the traffic using iptables. You can also select the traffic directly though.

Having said that, please note that qdiscs are only effective on outgoing traffic. You can have an ingress qdisc but that's very limited and probably won't behave as you'd expect.

For testing purposes, a good bet would be to create a real VM with two interfaces and somehow force-route your traffic through that. Some tricker may be required (i.e. a couple of levels of NATing). In the VM you can then attach whatever qdisc you like on the two interfaces, controlling both directions of the traffic.