How to add delay to ingress with netem?

Installing and Using OpenWrt
1

1 - What is the command to add delay to ingress?
2 - What is the command to remove the delay?

2

Could you post output of

ubus call system board
3 
{
        "kernel": "5.15.150",
        "hostname": "OpenWrt",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "Ubiquiti EdgeRouter X SFP",
        "board_name": "ubnt,edgerouter-x-sfp",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.3",
                "revision": "r23809-234f1a2efa",
                "target": "ramips/mt7621",
                "description": "OpenWrt 23.05.3 r23809-234f1a2efa"
        }
}
4

It is more than one command.

5

Wow, I saw it there and I didn't understand anything. Which one should I use?

6

Depends on what problem you are about to solve.

7

I just wanted to add a delay to the download. The easy-to-understand tutorials out there only teach you how to add a delay to the upload.

8

You need to run all commands, just choose netem as ifb qdisc.

9

How do I do this? Here are the tutorials I saw:

https://openwrt.org/docs/guide-user/network/traffic-shaping/sch_netem

10

You add ifb pseudo-device where you can shape input traffic, hopefully more than one command is not too much.

11

Attention: the netem qdisc has specific requirements that make it somewhat incompatible with non-work-conserving qdics, no catastrophic failure IIRC, but netem not fully working as intended. The upshot is, run netem on a dedicated node in your network path where it is not 'competing' with other qdiscs. I note this was also recommended by one of the iputils maintainers.

Sidenote: I am not sure, but it might be enough to use dedicated veth to isolate netem from other qdics on the same host, but I never tried....

12

Sorry for the delay, but how do I do this? Could you give me the command?

13

Do you know the commands I need to create an ifb device and add delay?

14

It would be helpful if you could explain why exactly you want to add a delay to your download traffic. I suspect this might be related to gaming, so here are a few ideas:

You can use qosmate for this purpose:
QoSmate Forum Thread

  1. Choose HFSC as the root qdisc.
  2. In the HFSC tab under "Game Queue Discipline" choose netem and change the desired delay and packet loss settings.
  3. To apply the delay to specific connections, you’ll need to tag the desired traffic with a DSCP value using QoSmate. This will classify the traffic into the realtime class.

Keep in mind: QoSmate applies NetEm in both directions (upload and download). For example, if you set a delay of 10ms, it will be applied in both directions, resulting in a total round-trip delay (RTT) of 20ms.

Important: If you use NetEm for the HFSC realtime class, all connections classified into the realtime class will also be subject to the delay. Connections assigned to other classes will not be affected.

15

Regarding netem in combination with other qdiscs see (iproute2 maintainer) Stephen Hemminger's words of wisdom:
https://lists.bufferbloat.net/pipermail/bloat/2024-October/018125.html#

[Bloat] The NetEm qdisc does not work in conjunction with other qdiscs

Stephen Hemminger stephen at networkplumber.org
Fri Oct 25 17:02:30 EDT 2024

On Fri, 25 Oct 2024 21:55:21 +0200 Maximilian Bachl via Bloat <bloat at lists.bufferbloat.net> wrote: > From my experience (experimented with it last year), it still behaves > weirdly. You can use htb for the shaping and you can create delay using > netem by using it on another (virtual) host on a link that does not have > any other qdiscs and where the link is not the bottleneck. > > Best regards, > Max
Yes, netem has expectations about how inner qdisc behaves, and other qdisc used as inner have expectations about how/when packets are sent. There is a mismatch, not sure if it is fixable with in the architecture of how Linux queue disciplines operate. The best way is to use netem on an intermediate hop and not expect it to work perfectly when used on an endpoint. The same is true of Dummynet and other network emulators; they are uses as man-in-the-middle systems.

So a combination might or might not work depending on the specifics, if reliable functionality is desired moving netem to its own node is the best way forward.

1 Like
16

Thank you for the additional information. This means that the way QoSmate uses netem is likely not optimal. As far as I can recall, the original intention/idea was simply to manipulate gaming packets to simulate higher ping, jitter, or even packet loss for gaming purposes (which I personally find concerning as it affects the game in a way that could resemble exploitative behavior.). From what I can tell, it worked, but it was never meant to be a 100% accurate network testing tool and likely wasn't thoroughly tested.

Here's a brief test:

Without netem:

Ping wird ausgefĂĽhrt fĂĽr 1.1.1.1 mit 32 Bytes Daten:
Antwort von 1.1.1.1: Bytes=32 Zeit=6ms TTL=58
Antwort von 1.1.1.1: Bytes=32 Zeit=6ms TTL=58
Antwort von 1.1.1.1: Bytes=32 Zeit=6ms TTL=58
Antwort von 1.1.1.1: Bytes=32 Zeit=6ms TTL=58

With netem delay 20 ms (10 + 10):

Antwort von 1.1.1.1: Bytes=32 Zeit=25ms TTL=58
Antwort von 1.1.1.1: Bytes=32 Zeit=25ms TTL=58
Antwort von 1.1.1.1: Bytes=32 Zeit=26ms TTL=58
Antwort von 1.1.1.1: Bytes=32 Zeit=25ms TTL=58

However, I have to admit that during testing, I found a few bugs that prevented the qdisc from being added correctly in some setup constellations. I have since fixed those issues.

17

Can this application apply delay only to ingress? Why doesn't your application appear in the openwrt packages?

18

No, it applies the delay in both directions. That doesn’t mean it’s impossible, but it’s simply designed that way.

Once again, could you explain why you specifically want the delay to apply only on ingress and why you need an artificial delay in the first place?

19

I'm testing lag compensation. I've edited my answer!

20

I had a feeling this might be about gaming.

To be honest, I don’t think messing around with artificial latency will help you much, but feel free to try it out yourself.

In modern online games, the server makes all the decisions. This means that if you artificially delay your gaming packets coming from the server to your game (ingress), you likely won’t improve your experience. The server may have already decided you lost the gunfight, and that response will simply take a little longer to reach you, potentially causing even more issues.

If you’re looking to influence latency and the server in any way, try egress instead, though also that is likely to have a negative impact.

Because it’s not an official package yet (though it might be in the future—that’s the plan, at least). But it’s very easy to install. Essentially, it’s just three commands, and then you can configure everything through the UI.