Timing and Performance

Timing templates

-T sets a bundle of timing defaults. It is the single highest-leverage knob, and -T4 is the everyday choice on a reliable network.

sudo nmap -T4 -p- 10.0.0.5
sudo nmap -T4 --open -sV 10.0.0.0/24
sudo nmap -T1 -p 80,443 10.0.0.5        # deliberately slow and quiet

What the templates actually change, at the two extremes:

-T5 risks marking a slow-but-open port as filtered, because its timeouts are short enough that a loaded host may not answer in time. On an unreliable link, -T4 with a raised --max-retries beats -T5.

Rate control

Rate limits are absolute packets per second across the whole scan, and they override what the template would have chosen.

sudo nmap -p- --min-rate 1000 10.0.0.5           # push a full port scan along
sudo nmap --max-rate 50 -p- 10.0.0.5             # stay under a rate-limit alarm
sudo nmap --min-rate 300 --max-rate 500 -p- 10.0.0.0/24

--min-rate is the fastest way to speed up a full 65535-port scan. Be aware it overrides congestion control, so on a saturated link it causes drops that read as filtered ports, which is a silent accuracy loss rather than an error.

Timeouts and retries

Time values accept a unit suffix: ms, s, m, or h, so 30m and 1800s are the same.

# a heavily filtered host, cap the damage
sudo nmap -p- --max-retries 1 --host-timeout 15m 10.0.0.5

# a lossy WAN, more retries and a longer ceiling
sudo nmap -p- --max-retries 6 --max-rtt-timeout 3s 10.0.0.5

# large sweep with a hard per-host budget
sudo nmap -sS --top-ports 100 --host-timeout 2m 10.0.0.0/16

--max-retries 1 is the single most effective change for a scan that is crawling through dropped probes. Each unanswered port costs retries × timeout, so dropping from 10 to 1 can cut a filtered-host scan by an order of magnitude, at the price of occasionally missing a port that answers intermittently.

Parallelism and host groups

# big sweep: large host groups amortize the setup cost
sudo nmap -sn -n --min-hostgroup 256 10.0.0.0/16

# be gentle with a fragile embedded target
sudo nmap --max-parallelism 1 --scan-delay 1s -p 1-1024 10.0.0.9

# push a LAN scan hard
sudo nmap -T4 --min-parallelism 100 -p- 192.168.1.0/24

Larger host groups improve throughput but delay results, because nmap reports a group only when it finishes. With --min-hostgroup 256 you wait for all 256 before seeing anything, which is why interactive work uses smaller groups and -v.

Delays, and where evasion overlaps timing

--scan-delay enforces a wait between probes to one host. It is listed under timing but it is the practical anti-rate-limit and anti-IDS control.

sudo nmap --scan-delay 1s -p 1-1024 10.0.0.5
sudo nmap --scan-delay 500ms --max-scan-delay 2s -p- 10.0.0.5

Nmap raises the delay on its own when it detects ICMP rate limiting, so a scan that slows down mid-run is usually the target throttling you, not a nmap problem. --max-scan-delay caps how far that automatic backoff can go, which prevents a scan from stretching to hours unnoticed.

Diagnosing a slow scan

sudo nmap -v -p- --stats-every 10s 10.0.0.5     # periodic progress and ETA
# during any scan, press a key for a status line, or 'v' for more verbosity

The ordering that matters: fix DNS first with -n, then retries, then rate. Those three account for most slow scans, and none of them require touching the timing template.