Everything is slow at peak hours

During the day everything is fine. Between seven and eleven a web page takes two seconds too long, a video call stutters and gaming is hopeless, while a speed test still gives you a reasonable number. That last part is confusing, and it is also the most important clue.

What it is not: if it is slow all day, this is not your chapter. If it is only slow on Wi-Fi and not on a cable, read Wi-Fi is slow. If only one service stutters, it is that service.

The quick checks, in order

1. Measure the latency while it is busy, not the speed. Run a ping to a fixed address: /ping 1.1.1.1 count=100, first when it is quiet, then during the peak. A good answer is a latency that barely moves. If it jumps from 10 ms to 300 ms the moment someone downloads, you have bufferbloat, and that is the most common cause of exactly this complaint.
2. Is your line actually full? /interface monitor-traffic interface=ether1 on the WAN port. Pinned against your subscription is a simple answer. Sitting at half of it while everything feels like treacle means this is queueing, not bandwidth.
3. Who is using it? /tool torch interface=ether1 sorts live by consumption. Often it is one backup, one game update or one device crowding out the rest.
4. Is the router itself calm? /system resource print. Above 80 percent CPU the router is the bottleneck, not the line. If that is what you see, go to CPU at 100 percent.
5. How many connections are open? /ip firewall connection print count-only. Tens of thousands of connections on a small board cost memory and time.
6. Are your queues doing anything? With QoS on: /queue simple print stats or /queue tree print stats. Counters that do not move mean the traffic is going past them.

The usual causes, most common first

Bufferbloat

Your modem, or your provider's equipment, has a large buffer. The moment someone starts an upload that buffer fills, and every small packet, every DNS query and every game sits at the back of that queue. The speed test stays good, because it measures throughput, and the latency is exactly what you feel.

The fix is to move the queue into your own router. Set a limit at about 90 to 95 percent of your real line speed and let CAKE or fq_codel manage the queue. You give up a few percent of speed and you get back a network that still responds under load.

The line really is full

A household watching four streams in the evening while a console updates itself can simply use up a connection. Fair sharing helps here: nobody collapses because one device takes everything.

One device crowds out the rest

A cloud backup, a large game update or a syncing photo library uses everything available. That is not a fault, that is a device doing its job. A per-host limit solves it.

Your Wi-Fi is busier in the evening too

It is not only your network that gets used after dinner, the neighbours' networks do too. On 2.4 GHz you notice that immediately. If the cable stays fast and Wi-Fi does not, this is it.

The provider's own uplink

Cable connections share capacity in the street, and you notice that at the hour everyone is home. A ping to the first hop beyond your router that also climbs while your own line is not full points that way.

What the configurator does about it

• The QoS / bandwidth section has four settings: off, one total limit, fair share per host with anti-bufferbloat, and priorities through a queue tree. For this complaint, fair share per host with CAKE is the right answer. Put your real download and upload speeds in the fields.
• The section's own introduction says why that works: set the limit slightly below the real line speed, around 90 to 95 percent, so the router manages the queue instead of the modem.
• You can pick fq_codel or PCQ instead of CAKE. PCQ adds a field for a maximum per host.
• Limits per host/network gives one address or one subnet its own ceiling and priority. That is the control for the device crowding out the rest.
• The tool warns as soon as QoS is on: FastTrack is disabled in the firewall, which raises CPU load, and on small routers that costs throughput. It is not a side effect you can avoid: fasttracked traffic bypasses the queue.
• Pick a queue tree with priorities on an older router and enter more than 200 Mbit/s, and the tool is honest about it: this router shapes in software and with FastTrack off it manages an estimated 200 to 300 Mbit/s, so the CPU will most likely be the bottleneck and the priorities stop holding. It recommends fair sharing with CAKE or fq_codel instead.
• Put the internet speed on the internet node on the network board and the check reports a port slower than the subscription, naming a better one.

The honest limits

A queue does not make your line wider. If your subscription is structurally too small in the evening for what the household does, QoS divides the scarcity neatly and nothing more. What happens beyond your router is not yours at all: the capacity in the street, your provider's nodes and the servers at the far end all sit behind your WAN port. And the numbers you put in the QoS fields have to be measured by you at a quiet moment: the tool does not know what your line really does.

Read on: QoS and bandwidth, Measuring speed and Checks about speed.