Docs /List sizing & hardware

DOCS / LIST SIZING

List sizing & router hardware.

Last updated: 2026-08-12

Address lists live in your router's RAM, and importing one costs CPU. A list that is unremarkable on a CCR can destabilise a 64 MB hEX. This page explains the size band and memory estimate shown on every list, where those numbers come from, and what to do when a list is too big for your hardware.

1. The short version

• Every list on /lists carries an estimated on-router memory figure and a size band.
• Tiny and Small lists are fine anywhere, including 64 MB devices.
• Medium lists want 128 MB or more, and the import is noticeable on low-end CPUs.
• Large lists want 256 MB or CCR-class hardware. Do not put one on a 64 MB device.
• The numbers are estimates. They are calibrated against real rendered output, but your router's actual usage depends on its RouterOS version and everything else it is doing.

2. Why this matters

This is not hypothetical caution. The predecessor of this project distributed a list large enough that 64 MB routers subscribed to it ran out of memory, kernel-panicked and rebooted — repeatedly, dozens of times — until the operator force-downgraded those devices to a smaller list from the server side. Separately, an RB2011 importing roughly 30,000 entries was reported as CPU-bound rather than memory-bound: it had plenty of RAM left, but the import itself was the bottleneck.

Both failure modes are real, and they are different. That is why the band is computed from both the estimated memory and the entry count, and why the worse of the two wins.

3. The bands

A list is placed in the worse of its two bands. A list can be cheap in RAM and still be a slog to import on a low-end CPU, so entry count is scored on its own axis rather than folded into the memory number.

4. How the estimate is derived

4.1. Download size — measured

The rendered size of a list is measured, not guessed. Each entry becomes one add list=… address=… line, so the cost per entry is stable and depends only on the shape of the entries. Measured on 2026-08-12 against real catalogue data, rendered through the same code path that serves.rsc to your router:

Two clean populations fall out. Lists whose entries carry a per-entry comment (threat feeds, bogons) cost roughly 78–86 bytes each; country allocation lists, which are bare CIDRs with no comment, cost roughly 49 bytes each. A list we have not measured is estimated at 50 bytes per entry if it is a country list and 86 bytes otherwise — the top of each measured range, so an unmeasured list is never under-stated.

The v6 and v7 renders are byte-identical for every list measured — only the command menu path differs, and that lives in the header, not the per-entry lines. One estimate therefore covers both.

4.2. On-router memory — extrapolated, and labelled as such

We cannot measure your router from here. The memory figure is the rendered size scaled by a factor of 5.4×, anchored to the only real-world measurement available: a roughly 190,000-entry address list that was reported as taking about 54 MB to load and about 50 MB resident on RouterOS.

Converting that to a per-byte ratio needs an assumption about how that list rendered, so we deliberately took the assumption that produces the largest multiplier. The practical effect: for comment-bearing lists our figure over-states memory rather than under-stating it. When the failure mode is somebody's router rebooting in a loop, that is the correct direction to be wrong in.

Treat the memory number as an order-of-magnitude guide for deciding whether a list belongs on a given device — not as a budget to fill to the last megabyte.

5. If a list is too big for your router

• Pick a narrower list. Most of the value in a country list is in the specific ranges you actually want to block; a threat list is usually a better ratio of protection to memory.
• Use the bundle builder to combine only what you need into a single subscription URL, rather than scheduling several lists side by side.
• Import off-peak. The import is the CPU-expensive moment. Schedule it for a quiet hour rather than mid-day.
• Check before you commit. Run /system resource print on the device and look at free memory before adding a Medium or Large list.

6. WinBox and large address lists

Worth knowing before you blame a list for a busy router: leaving IP → Firewall → Address Lists open in WinBox while a large dynamic list is loaded causes WinBox to re-fetch the table continuously. On a large list that is measurable bandwidth and CPU — the predecessor project measured it at around 5 Mbps — for as long as the tab stays open.

This is RouterOS/WinBox behaviour, not a fault in the list, and there is no setting that fixes it. It was raised upstream and described as expected behaviour. The remedy is simply to close the tab when you are finished looking at it. If you need to inspect entries, the list detail page has a searchable table that costs your router nothing.

7. What is not covered here

• Firewall matching cost. The estimates cover storing and importing the list. Matching traffic against an address list is cheap in RouterOS and is not modelled.
• Multiple lists. The figures are per list. If you subscribe to several, add them up — and leave headroom for everything else the router does.
• Your specific hardware. Device class is a rough proxy. A 128 MB device already running a heavy queue tree has less to spare than a bare one.

Status: the byte measurements are real and reproducible from this repository's render path; the memory multiplier is an extrapolation from a single third-party measurement and is labelled as such everywhere it is shown. Drift discipline: if the estimator's constants or bands change, this page changes in the same turn. Better silence than wrong claims — see /docs/threat-model.