Networking Handbook

I once watched a tech spend two hours on a ladder, in full sun, convinced an IP camera was dead on arrival. The camera was at 192.168.1.130, the NVR at 192.168.1.10, ping wouldn't cross, and the verdict was "send it back." The camera was fine: the NVR had a /24 mask and the camera a /26. They lived on the same street — they just disagreed about where the street ended.

That's the whole point: the subnet mask is not a decorative field you fill with 255.255.255.0 "because that's what goes there." It's half of the address. And the good news is that all of subnetting — masks, CIDR, VLSM — boils down to one idea that fits in a row of 32 boxes.

Inside an IP: 32 switches

An IPv4 address is 32 bits: 32 switches that can only be 0 or 1. Since nobody wants to dictate 32 ones and zeros over the phone, we group them into 4 octets of 8 bits and write each octet in decimal: 192.168.1.0. Thirty-two bits give you 2³² combinations — about 4.29 billion addresses — which felt infinite in the eighties and get rationed out with an eyedropper today.

The mask draws a vertical line across those 32 boxes and splits the address in two, like a postal address: the network part is the street name (shared by every neighbor) and the host part is the house number (unique to each device). The mask is a run of contiguous ones from the left — "this is street" — followed by zeros — "this is house." In binary, 255.255.255.0 is 24 ones followed by 8 zeros: the boundary lands exactly on the third dot.

If you want to see any address taken apart bit by bit, the IP converter shows it in decimal, binary and hex side by side. Seeing it in binary once beats reading ten definitions.

CIDR and the jump trick

Typing 255.255.255.192 every time is cruel and unusual, so CIDR notation compresses the mask into one number: how many network bits it has. /24 means "24 ones," /26 means "26 ones." The bigger the number after the slash, the smaller the subnet — yes, it's backwards, and yes, everyone trips over it the first time.

To read a prefix at a glance, anchor yourself on the multiples of 8: /8 cuts after the first octet, /16 after the second, /24 after the third. Everything in between yields to the jump trick: take the "interesting" octet of the mask (the one that's neither 255 nor 0) and compute 256 minus that value. The result is the block size, and subnets start at multiples of that jump.

With /26 the mask is 255.255.255.192, so the jump is 256 − 192 = 64: subnets start at .0, .64, .128 and .192. Someone asks where 192.168.1.135/26 lives? Count multiples of 64 — 0, 64, 128… — and 135 lands past 128: its network is 192.168.1.128, its broadcast 192.168.1.191. No calculator, no binary, done before the other guy finds the app.

Network and broadcast: the two reserved seats

Every subnet loses two addresses before it does any work. The first one — all host bits set to 0 — is the network address: the street name itself, assigned to nobody. The last one — all host bits set to 1 — is the broadcast: the megaphone for yelling at the whole block. That's why usable hosts are 2ⁿ − 2, where n is the number of host bits.

And watch out — in practice you lose a third one: the gateway also eats a usable address. A /26 has 62 hosts on paper, but 61 free chairs once the router sits down. Here's the table worth tattooing on the inside of your eyelids (the full version, /0 through /32, lives in the CIDR table):

A note for the purists: /31 exists (RFC 3021) for point-to-point links with no network or broadcast address, but not every device embraces it warmly; /30 is still the de facto standard in the field. To play with any network-and-prefix combination, the subnet calculator hands you network, broadcast, range and binary instantly.

VLSM: slicing the cake with nothing wasted

Now the real-world case. You're handed 192.168.1.0/24 for an office with Sales (50 devices), Support (20), IT (10) and a point-to-point link (2) to the branch router. The lazy option is cutting it into 4 equal pieces with the FLSM splitter: four /26 blocks of 62 hosts each. It works… but the 2-host link ends up holding 64 addresses — a luxury penthouse for two people.

VLSM (variable-length subnet masking) tailors the fit: each area gets the smallest block that covers it. The one sacred rule is allocate largest to smallest, so every block lands aligned on a multiple of its own size. Here's how it goes:

1. Sort the requirements, largest first: Sales 50, Support 20, IT 10, link 2. Always. Start with the small one and the big ones won't land aligned later.
2. Sales, 50 hosts: 5 host bits give 2⁵ − 2 = 30 (not enough); 6 bits give 2⁶ − 2 = 62 ✓. Prefix: 32 − 6 = /26. Block: 192.168.1.0/26 → hosts .1 to .62, broadcast .63.
3. Support, 20 hosts: 2⁵ − 2 = 30 ✓ → /27. The next free block starts right where Sales ended: 192.168.1.64/27 → hosts .65 to .94, broadcast .95.
4. IT, 10 hosts: 2⁴ − 2 = 14 ✓ → /28. Block: 192.168.1.96/28 → hosts .97 to .110, broadcast .111.
5. Link, 2 hosts: 2² − 2 = 2, a perfect fit → /30. Block: 192.168.1.112/30 → hosts .113 and .114, broadcast .115.
6. Run the balance: you used 64 + 32 + 16 + 4 = 116 addresses, leaving .116 through .255 free — 140 addresses for the growth the client swears will never happen (and will).

The full plan, ready for the project folder:

Sales    192.168.1.0/26    hosts .1–.62     bcast .63   (62 usable)
Support  192.168.1.64/27   hosts .65–.94    bcast .95   (30 usable)
IT       192.168.1.96/28   hosts .97–.110   bcast .111  (14 usable)
Link     192.168.1.112/30  hosts .113–.114  bcast .115  (2 usable)
Free     192.168.1.116 – .255                            (140 addrs)

Want to check my math (or rerun it with your own numbers)? Feed the same requirements into the VLSM planner and compare: it should hand you exactly these ranges.

Wildcard: the mask wearing its jacket inside out

The wildcard is the mask with every bit flipped: where the mask says "this part is fixed," the wildcard says "I don't care about this part." A /26 (255.255.255.192) has wildcard 0.0.0.63, so permit 192.168.1.0 0.0.0.63 in an ACL means "any address in the Sales block."

The three mistakes that cost real money

1. Overlapping subnets. Two blocks that step on each other — a 192.168.1.0/24 here, a 192.168.1.64/26 there — coexist in silence until you bring up the VPN to the other site and routing turns into roulette. Renumbering a production network is paid for in sleepless nights. Before adding any new block, run it through the overlap checker: ten seconds versus a lost weekend.

2. Counting hosts as if they were people. "Sales has 50 people" does not mean 50 addresses: you're missing the gateway, the printer, the AP, the camera, the sensor somebody plugged in without telling anyone, and the slack the DHCP pool needs. Size with headroom and carve out reservations with the DHCP calculator before the pool runs dry on a Monday at 9:00.

3. Misaligning blocks. A subnet can only start on a multiple of its own size: a /27 starts at .0, .32, .64, .96… — 192.168.1.80/27 does not exist, no matter how confident the spreadsheet looks. That's why VLSM allocates largest to smallest: the blocks fall into alignment on their own. Bonus: well-aligned, contiguous blocks can later be summarized into a single route with the CIDR aggregator (two adjacent, aligned /27s = one /26).

Your move

Grab a network you run today and give it an autopsy: how many addresses are assigned versus actually in use? Then build the plan properly — requirements sorted largest to smallest in the VLSM planner, collision check in the overlap checker — and file the table in the project folder. The next camera that won't ping gets solved from the ground, no ladder required.

On a CCTV commissioning job, a colleague of mine carefully wrote down "the NVR's IP" in the project binder: fe80::ba27:ebff:fe12:34c9. Two weeks later, nobody at the remote office could reach the recorder. Of course they couldn't — he'd written down the link-local address, which only exists inside that one network segment. That's like giving "back room, second door on the left" as your mailing address: perfectly accurate if you're already inside the house, useless from anywhere else.

Accidents like that happen because IPv6 looks intimidating, so the natural reflex is to copy-paste it without reading it. Here's the good news: those 128 bits hide less mystery than IPv4 ever did. Let's take it apart.

From 32 to 128 bits: why it looks so weird

An IPv4 address is 32 bits dressed up as four decimal numbers. An IPv6 address is 128 bits dressed up as 8 groups of 16 bits, each group written as 4 hexadecimal digits, separated by colons. That's the whole trick. If it looks long, that's because it is long: written out in full, it's 39 characters.

Since typing 39 characters per address would be cruel and unusual, the standard (RFC 5952) gives you two compression rules:

• Rule 1: inside each group, drop the leading zeros. 0db8 becomes db8, 0000 becomes 0.
• Rule 2: the longest run of all-zero groups collapses into ::. And you can only do this ONCE per address — with two :: you couldn't tell how many zeros went where, and the address would be ambiguous.

So 2001:0db8:0000:0000:0000:0000:0000:0001 shrinks to 2001:db8::1. Same address, 28 characters lighter. If you want to play with this in both directions — expand and compress — the IPv6 calculator does it instantly and also tells you the address type and range.

Anatomy of a GUA: three pieces, not eight

The most common reading mistake is trying to parse the 8 groups the way you'd parse the 4 octets of IPv4. Don't. A global unicast address (GUA) reads as three pieces, like an international phone number — country code, area code, local number:

Look at the proportions: out of 128 bits, you only manage 16. The prefix arrives ready-made, and hosts auto-generate their own interface identifier via SLAAC. The entire "network design" of an IPv6 site lives in 4 hex digits. That's why IPv6 planning ends up simpler than IPv4: the problem got smaller, not bigger.

The address types you'll meet in the field

The first word of the address tells you immediately what you're looking at. These are the ones that show up in real life:

Link-local is the misunderstood star of the show. Every IPv6 interface gives itself an fe80:: address the moment it comes up, without asking anyone, and it's only valid on that physical link. Routers use it to talk to each other, and the default gateway a router advertises via RA is almost always a link-local address. That's why seeing fe80::… as a next hop in a routing table is perfectly normal — and why writing it down as "the device's IP" to reach it from another network is exactly my colleague's NVR mistake.

ULAs are the spiritual heir of 10.0.0.0/8, with one upgrade: the standard (RFC 4193) tells you to generate 40 random bits for your fd…::/48 prefix. That sounds like bureaucracy right up until your company merges with another one and you both used 10.0.0.0/8 — in IPv4 that means renumbering and tears; with randomized ULAs a collision is practically impossible. If you've inherited someone else's networks, the subnet overlap checker tells you in seconds whether two prefixes clash.

And broadcast? It's gone. IPv6 replaced it with well-aimed multicast: ff02::1 reaches every node on the link, ff02::2 only the routers. Even ARP's replacement (NDP) uses targeted multicast instead of shouting at the whole segment. Your switches send their regards.

The golden rule: every LAN is a /64

Tattoo this one somewhere: every VLAN, every segment, every LAN gets a /64. Not a /96 "because it's only a few devices", not a /120 "to avoid waste". A /64. Always.

The reason is technical, not aesthetic: SLAAC — the mechanism hosts use to configure their own addresses — requires exactly 64 bits of interface identifier (RFC 4862). Give it less and SLAAC simply stops working, leaving you dependent on DHCPv6 for everything… and Android does not speak DHCPv6. A "trimmed" /64 is a network where phones can't get an address.

As for the "waste" — let's do the math. A /64 holds 2⁶⁴ addresses: 18.4 quintillion. The entire IPv4 address space is 2³² ≈ 4.3 billion. In other words, each /64 could hold 4.3 billion copies of the whole IPv4 internet — and we still assign one to the VLAN with three printers on it. That's fine. It's designed that way: the 64 host bits aren't inventory that runs out, they're the room autoconfiguration and address privacy need in order to work without coordination.

The hierarchical plan: /48 → /56 → /64

Once the golden rule is settled, planning means handing out /64s. A site /48 leaves you 16 subnet bits: 2¹⁶ = 65,536 /64 networks. The point isn't the quantity — it's how you organize it. The pattern that never fails:

• /48 = the site. What your ISP delegates (or your ULA block).
• /56 = the building (or floor, or zone): 8 bits → 256 buildings per site.
• /64 = the VLAN: another 8 bits → 256 VLANs per building.

Is 256 buildings more than you'll ever need? Doesn't matter. The goal of an IPv6 plan isn't to "use up" the space — it's to make the address read itself: you glance at …cafe:0530::/64 and know it's building 05, VLAN 30, without opening a single spreadsheet. During a 3 AM incident, that's worth its weight in gold.

The nibble boundary: why 4 bits at a time

A nibble is 4 bits — exactly one hexadecimal digit. Split your prefixes on multiples of 4 bits (/48, /52, /56, /60, /64) and every block starts and ends on a whole hex digit, so prefixes can be read at a glance. Cut at /49 or /57 and the boundary lands in the middle of a digit: 2001:db8:cafe:8000::/49 exists and is perfectly valid, but figuring out what it contains requires mental binary arithmetic. Nobody wants that at 3 AM.

There's a bonus prize: IPv6 reverse DNS (ip6.arpa) is delegated digit by digit — that is, nibble by nibble. A nibble-aligned plan translates into clean, delegable PTR zones; a misaligned one, into headaches. The reverse PTR zone tool generates the ip6.arpa names from any prefix, and you'll see it immediately.

Hands on: a complete plan in 6 steps

Say your ISP delegated 2001:db8:cafe::/48 for a campus, and we start with VLAN 10 (data) in building 5:

1. Locate your 16 bits. The first 48 bits (2001:0db8:cafe) are fixed. Your canvas is the entire fourth group: 4 hex digits. The last 64 bits belong to the hosts.
2. Split the group on the nibble boundary: first 2 digits = building (8 bits → 256 buildings), last 2 = VLAN (8 bits → 256 VLANs per building).
3. Building 5 → 05. Its whole block is 2001:db8:cafe:0500::/56: any address whose fourth group starts with 05 lives there.
4. VLAN 10 → 10. The fourth group becomes 0510, so the LAN is 2001:db8:cafe:0510::/64.
5. Compress (RFC 5952): the leading zero drops (0510 → 510) and the zero groups collapse into ::. Result: 2001:db8:cafe:510::/64, with gateway 2001:db8:cafe:510::1.
6. Count what you've got: 256 buildings × 256 VLANs = 65,536 /64 networks from a single /48. Each holding 2⁶⁴ addresses. You can stop rationing now.

Building 5's plan ends up this readable:

site                2001:db8:cafe::/48
building 05         2001:db8:cafe:500::/56
├─ vlan 10 data     2001:db8:cafe:510::/64
├─ vlan 20 voice    2001:db8:cafe:520::/64
├─ vlan 30 cameras  2001:db8:cafe:530::/64
└─ gw vlan 10       2001:db8:cafe:510::1

Every line explains itself: site cafe, building 05, VLAN in plain sight. Paste any of these prefixes into the IPv6 calculator to double-check the expansion, range and type before you configure anything.

What to do next

Pick a real site you manage, sketch its building → VLAN hierarchy, and run it through the IPv6 planner: five minutes gets you a complete nibble-aligned plan. Then go audit any fe80:: addresses written down somewhere as if they were reachable — now you know why they never answer from the other office.

The first time I left a condo camera system "ready to watch from your phone," I drove off feeling like a hero. Port 8080 forwarded on the router, local test flawless, happy client. Two hours later, the phone rings: nothing works from outside. I went back, checked the firewall, redid the port forward, rebooted everything twice… and then I finally looked at the router's WAN IP: 100.72.19.4. It looked public. It wasn't. I learned more about how the internet actually works that afternoon than in any course — and this guide is that afternoon, compressed, minus the embarrassment and the wasted gas.

The private neighborhood: why RFC 1918 exists

An IPv4 address is 32 bits: 4,294,967,296 possible combinations — about 4.3 billion. In the 80s that sounded infinite; today there are more chips with antennas than people on the planet. To avoid burning a globally unique address on every printer and smart light bulb, RFC 1918 set aside three blocks in 1996 that anyone can use inside their own network, no permission required.

Think of it as apartment 4B: it exists in thousands of buildings at once and there's never a conflict, because nobody mails a letter to "apartment 4B, Chile" and expects delivery. Inside the building, the unit number is enough. To reach the outside world you need the street address: the public IP.

The three RFC 1918 blocks add up to 17,891,328 addresses — nearly 18 million — reused in millions of networks simultaneously. The golden rule: these ranges never cross the internet. No router along the path will forward a packet sourced from 192.168.1.20; to get out, somebody has to translate it first.

NAT and PAT: the front desk that translates addresses

If private IPs can't leave the building, how does your laptop browse anything? Picture the front-desk clerk. Outgoing mail carries the building's street address plus a mailbox number, and the clerk writes in the logbook: mailbox 40001 = apartment 4B. When the reply arrives addressed to mailbox 40001, the clerk knows exactly whose door to knock on. That logbook is the NAT table, and the mailbox number is the port.

Technically: NAT (Network Address Translation) rewrites the packet's source IP; PAT (Port Address Translation — the "NAT overload" your router actually does) rewrites both IP and port, letting hundreds of devices share a single public address. Each conversation is identified by the 5-tuple: protocol, source IP, source port, destination IP, destination port. Change any one of the five and it's a different session — a new row in the clerk's logbook.

Here comes the number that rules everything: the port field is 16 bits, so 65,536 values. Ports 0 through 1023 are reserved for well-known services, which leaves 1024 through 65535 for translation: 64,512 ephemeral ports per public IP. In other words, one public address multiplexes on the order of 64 thousand simultaneous sessions. Sounds roomy… until you remember that a phone running WhatsApp, Instagram, Spotify and 30 browser tabs keeps dozens of sessions open without anyone noticing.

Worked example: the day the ports run out

Let's model an office building that reaches the internet through one public IP — the same model behind the NAT/PAT exhaustion calculator, in case you want to plug in your own numbers.

1. Available ports per public IP. Typical ephemeral range: 1024 to 65535. That's 65,535 − 1,024 + 1 = 64,512 ports.
2. Demand. 700 users × 100 concurrent sessions each = 70,000 sessions asking for a port at the same time. (100 per user is not an exaggeration: browser + email + Teams + streaming get there effortlessly.)
3. Compare. 70,000 > 64,512: that's 70,000 − 64,512 = 5,488 sessions left without a free port. Utilization lands at 70,000 ÷ 64,512 = 108.5%.
4. What it looks like in the field. Above 100%, "the internet" doesn't go down — random connections fail. Pages that half-load, apps that keep retrying, video calls that connect on the third attempt. The classic "internet feels weird" ticket nobody can reproduce.
5. Fix. IPs needed = ⌈70,000 ÷ 64,512⌉ = 2 public IPs. Capacity rises to 2 × 64,512 = 129,024 ports and utilization drops to a comfortable 54.3%, with headroom for Monday-morning spikes.

Another way to see the same limit: with a single IP and 700 users, each one gets at most 92 sessions on average. A single machine running torrents — or malware — can chew through thousands of ports on its own and leave the rest of the building queuing at the front desk.

CGNAT: when your "public" IP is private too

Back to the condo and its 100.72.19.4. ISPs face the same problem your office does: they don't have enough public IPv4 addresses to hand one to every customer. Their solution? NAT the customers again, inside the carrier network: Carrier-Grade NAT. For that middle layer, RFC 6598 reserved 100.64.0.0/10 — 4,194,304 addresses that aren't RFC 1918, but aren't public either. No-man's-land between your router and the real internet.

The practical consequence: there are two translations and you only control the first one. The port forward you set up on your router works perfectly… as far as the edge of your house. When someone tries to reach in from the internet, they knock on the ISP's CGNAT — and that box has no idea your camera exists. The packet dies right there, politely and without a word.

Who owns that IP? Autonomous systems in three sentences

We know how the packet leaves your house. Who carries it from there? Three sentences, as promised. One: the internet is not a network — it's roughly 80,000 independent networks called autonomous systems (AS), each with a unique number: the ASN. Two: each AS announces the address blocks it manages via BGP, and its neighbors decide whether to believe it and where to route. Three: your packet hops across several ASes hand to hand — your ISP, one or two middlemen, the destination's AS — and that, literally, is the entire internet.

ASes connect under two kinds of deals: transit (I pay a bigger AS to carry me everywhere) and peering (two ASes swap traffic for free because it benefits both, usually at an internet exchange, or IX). That's why Netflix and YouTube feel instant: their CDNs peer directly with your ISP and the traffic barely leaves town.

About the numbers: ASNs started at 16 bits (up to 65,535) and — same movie as IPv4 — ran out; today they're 32-bit, up to 4,294,967,295. There are two notations: asplain, the flat number (196629), and asdot, in high.low format (3.21 — the same number, because 3 × 65,536 + 21 = 196,629). The dot confuses older gear and breaks more than one regex, so it pays to read both. The ASN converter translates between them and also tells you whether a number is public, private (64512 through 65534 gives you 1,023 private 16-bit ASNs — the "192.168 of BGP") or reserved. A real, verifiable example: in Chile, Entel operates AS27651 — that single number identifies its entire network to the rest of the planet.

Detective mode: investigating any IP

With all the pieces above, investigating an IP takes under a minute. The kit has three tools:

• How does the world see me? My IP shows your real public IP, your ISP's ASN and organization, geolocation and reverse DNS. It's also the quickest CGNAT test: if what it shows doesn't match your router's WAN, you know exactly what happened.
• Who owns this IP? RDAP is the modern WHOIS: instead of free-form text, it returns structured data straight from the relevant registry (LACNIC for this part of the world). You get the owning organization, the full assigned range, and — the gem — the abuse contact: the official inbox for reporting that an IP is up to no good.
• Need to filter the whole range? If you decide to block it or hunt through logs, CIDR to regex turns the entire block into a regular expression and an exact address range, ready for grep or your ACL.

Mini-case: an IP has been hammering your firewall all night. RDAP tells you in seconds that it belongs to a hosting company with a public abuse contact; you report it with logs, date and timezone — and along the way you find out whether that "international attack" was actually a university research scanner that sweeps the whole internet daily (happens more often than you'd think). It won't change the world, but abuse desks really do take down bots — and you stop guessing.

Your move

Open My IP and compare it with your router's WAN: you now know exactly what it means when they don't match. Then run your real numbers through the NAT/PAT calculator before some random Monday runs them for you. And the next suspicious IP in a log gets 30 seconds of RDAP: the internet stops being a cloud and starts being a map.

One Monday at 8:30 a school called me in a panic: “the whole network is dead, the switch must have burned out.” The culprit was a two-meter patch cable that someone, meaning well, had plugged between two wall jacks “so it wouldn’t dangle.” That cable created a loop, the loop spawned a broadcast storm, and the storm took 800 students offline. To understand how two meters of copper can flatten an entire building — and why they almost never manage to — you have to open the switch and look inside. Spoiler: there’s no magic in there. There’s a table, some tags, and a tree.

How a switch learns (no magic involved)

Picture a building concierge on their first day, knowing nobody. Every time a resident hands over a letter to mail out, the concierge glances at the return address and jots down: “Mrs. Pérez lives in 402.” No questions, no guessing: they learn by watching where things come from. A switch does exactly that with every frame it receives: it reads the source MAC and notes in its table, “this MAC lives behind this port.”

When a frame arrives for a known destination, the switch forwards it out that one port only. And if the destination isn’t in the table? The concierge shouts across the lobby: the frame is flooded out every port except the one it came in on. Whoever answers gets learned, and the next delivery goes direct. Broadcasts (destination ff:ff:ff:ff:ff:ff) are always flooded, by definition. And since residents move out, table entries expire: the default aging timer is 300 seconds without seeing traffic from that MAC.

Vlan    Mac Address        Type      Ports
----    -----------        ----      -----
  10    b4:96:91:1a:2f:03  DYNAMIC   Gi1/0/07
  10    f4:39:09:55:c0:11  DYNAMIC   Gi1/0/12
  20    00:11:32:8b:44:9e  DYNAMIC   Gi1/0/24
Total Mac Addresses for this criterion: 3

The frame: an envelope with 20 invisible bytes

The envelope traveling down the wire has a fixed layout: destination MAC (6 bytes), source MAC (6), EtherType (2, declaring what’s inside: IPv4, IPv6, ARP…), the payload (46 to 1500 bytes) and the FCS (a 4-byte checksum at the end). Legal minimum: 64 bytes. Classic maximum: 1518.

But the wire charges more than Wireshark shows you. Before every frame come 8 bytes of preamble + SFD (a clapperboard that syncs the clocks), and after it come 12 bytes of IFG, the mandatory silence between frames. That’s 20 bytes per frame no capture will ever display, yet they burn wire time all the same. With small frames, that tax hurts.

Those 20 bytes explain the most quoted — and least understood — number in switching: how many frames per second a link can carry. Let’s run it at 1 Gbps with minimum-size frames:

1. The smallest legal frame is 64 bytes: 6 (destination) + 6 (source) + 2 (EtherType) + 46 (payload) + 4 (FCS).
2. Add the invisible tax: 8 bytes of preamble+SFD and 12 of IFG. On the wire it occupies 64 + 20 = 84 bytes.
3. Convert to bits: 84 × 8 = 672 bits per frame.
4. Divide the line rate: 1,000,000,000 ÷ 672 = 1,488,095 frames/s ≈ 1.49 Mpps. That’s the theoretical ceiling of a gigabit port under small-frame traffic (think VoIP, or attacks).
5. Sanity check: with 1518 B frames it’s 1,538 × 8 = 12,304 bits, i.e. just 81,274 pps. Same link, 18 times fewer packets — which is why firewalls are specced in pps, not just Gbps.

Want to play with other sizes and speeds without a spreadsheet? The Ethernet frame & PPS calculator runs exactly this math from 1G to 100G, with and without a VLAN tag.

VLAN 802.1Q: virtual walls inside the same box

A VLAN turns one physical switch into several logical ones: cameras on one side, guests on another, and neither sees the other’s broadcasts. The mechanism is almost embarrassingly simple: a 4-byte tag inserted inside the frame, between the source MAC and the EtherType (see the diagram above). Two bytes of TPID (0x8100, “heads up, this is tagged”) and two bytes carrying the PCP (3 priority bits, values 0 to 7), the DEI bit and the 12-bit VLAN ID: 4096 values, of which 4094 are usable (0 and 4095 are reserved).

Back to the building. An access port is an office door: everything coming out of it belongs to that office, so nobody wears a badge indoors — the switch pins the tag on when the envelope enters the hallway and peels it off on delivery. A trunk port is the shared mailroom corridor: envelopes from every office travel through it, each with its sticker on, because without stickers nobody could tell which office owns what. Access = one port, one VLAN, untagged. Trunk = many VLANs, all tagged.

The 3 PCP bits (802.1p) are the “fragile” stamp on the envelope: mark voice with priority 5 or 6 so the switch ships it out ahead of the Windows Update download. And when a service provider hauls your VLANs across its network, it uses Q-in-Q (802.1ad): it wraps your frame, tag and all, inside a tag of its own (the S-TAG, TPID 0x88a8). An envelope inside an envelope: you keep your 4094 VLANs untouched and the provider moves you around as a single customer. The maximum frame grows to 1522 B with one tag and 1526 B with two. You can dissect any tag bit by bit with the VLAN decoder and build the double tagging with the Q-in-Q tool.

STP: the tree that puts out the storm

Now, back to that school cable. Layer 2 has no TTL: a frame can circle forever. Connect two switches with two cables (or one wall jack to another) and every broadcast entering the ring gets forwarded, comes back, gets forwarded again… and since each switch floods it out every port, it doesn’t just loop — it multiplies. Within seconds the links saturate with copies of the same ARP — remember the ceiling: up to 1.49 million frames per second on every gigabit port — CPUs choke, and MAC tables go haywire watching the same source MAC arrive on two ports at once (MAC flapping). That’s a broadcast storm, and it doesn’t fix itself: it stops when the loop is cut.

Spanning Tree (STP/RSTP) cuts the loop for you, deliberately and with criteria. First the switches elect a root bridge: lowest bridge ID wins, which is the priority (0 to 61440 in steps of 4096, default 32768) followed by the MAC address. On a priority tie, the lowest MAC wins — which is usually the oldest switch in the closet, not the best one. Then every switch computes its cheapest path to the root by adding up each link’s cost, keeps that port as its root port, and every redundant link ends up with one blocked port: still there, still listening to BPDUs, ready to take over if the main path dies.

The original short scale ran out of numbers above 10 Gbps (everything costs “about the same”), so 802.1t defined the long scale: 20,000,000,000,000 divided by the speed in bps. That’s where the two values worth memorizing come from: 1G = 20,000 and 10G = 2,000. Watch out on mixed networks: if one switch speaks short and another long, path decisions can get absurd. The STP cost calculator adds up full paths in both scales and tells you who wins as root.

LAG: adding links up, fine print included

When one link isn’t enough, the natural move is laying another one next to it and bundling them with LAG/LACP (802.1AX, formerly 802.3ad). It works, STP sees the bundle as a single logical link and blocks nothing. But the fine print matters: the switch picks which member carries each frame using a hash of the source/destination MACs, IPs or ports. Every frame of a given flow produces the same hash and rides the same member — otherwise packets would arrive out of order. Direct consequence: 4×1G gives you 4 Gbps aggregate, but a single flow never exceeds 1 Gbps. Your NAS backup running over one TCP session has no idea the other three cables exist.

There’s a lesser-known trap too: the hash doesn’t distribute across members, it distributes across buckets, and bucket counts are usually a power of 2 (8 is typical). With 2 or 4 members the split is perfect. With 3 members, 8 buckets split 3, 3 and 2: two members each get 37.5% of the flows and the third gets only 25%. With many similar flows, that imbalance shows. The LAG calculator shows the exact split and the per-flow ceiling for any combination.

Multicast at L2: 32 IPs, one MAC

Last piece inside the box: when a camera streams to an IPv4 multicast group, the frame carries nobody’s MAC in particular. A special MAC is built instead: the prefix 01:00:5e plus the lower 23 bits of the group IP. And here’s a lovely detail: a multicast IP has 28 group bits (the first 4 are fixed, 1110), but only 23 fit in the MAC. Five bits get dropped, so 2⁵ = 32 different IP addresses share the very same MAC. For instance, 224.1.1.1, 225.1.1.1 and 239.129.1.1 all land on 01:00:5e:01:01:01.

The takeaway: filtering multicast by MAC at layer 2 is never exact — the switch (via IGMP snooping) may hand you traffic from a “neighboring” group colliding on the same MAC, and the fine-grained discard happens at the receiver’s IP layer. IPv6 is more generous: prefix 33:33 plus the last 32 bits of the address. The multicast IP ↔ MAC converter shows you the resulting MAC and the 31 IPs that collide with yours — handy when the corporate TV stream shows up in the wrong VLAN.

Open your own box

Now you know what’s inside: a table that learns by reading return addresses, 4-byte tags that raise walls, a tree that cuts loops, and hashes that deal out flows. Go log into your switch: read the MAC table, check who your root bridge is (and whether it deserves the job), and work out the real pps of your links with the frame calculator — before the next two-meter cable does it for you.

A while back we got called in for "the slow WiFi in the meeting room". The phone showed full bars standing right next to the AP, and the video call still froze every couple of minutes. The culprit turned up at the end of the hallway: an ancient IP camera hanging off the same AP, negotiating 6 Mbps from the storage room. Signal was never the problem — the microphone was. WiFi works like karaoke night: one singer at a time, and that camera never let go of the mic.

One microphone: WiFi is a shared medium

A modern UTP cable is full-duplex: every device gets its own dedicated copper pairs and can talk and listen at the same time. Radio can't. On a WiFi channel, one station transmits at a time: the AP and all of its clients share the same air, half-duplex. The protocol that manages the queue is CSMA/CA, and it behaves like a polite conversation: listen before talking, wait a random turn, transmit, and hope for the ACK. If two stations talk at once, the frame is lost and both retry — slower.

Almost everything else follows from that one fact: channels define how many karaoke rooms exist, channel width is the size of each room, the MCS is how fast each singer can go, and airtime is how long each client hogs the mic. Once that clicks, you stop chasing signal bars and start designing cells.

Channels: the map of 2.4, 5 and 6 GHz

The 2.4 GHz band is an old neighborhood with narrow streets. There are 13 numbered channels (in most of the world), with center frequencies every 5 MHz from 2412 to 2472 MHz. The cruel detail: each channel is 20 MHz wide, so neighboring channels overlap each other. With centers 25 MHz apart, only one combination coexists cleanly: 1, 6 and 11.

On paper, 1/5/9/13 would also work (exactly 20 MHz apart), but only if the entire neighborhood agrees — and one router on channel 6 ruins the party. Add microwave ovens, Bluetooth and wireless doorbells all living in 2.4 GHz, and you see why it's the band of inherited problems.

The 5 GHz band is a different world: roughly 25 channels of 20 MHz (depending on local regulation) and no microwave ovens butting into the conversation. The toll is the DFS channels (52 through 144), where WiFi is a guest of weather and military radar. And 6 GHz (WiFi 6E) is the wide-open prairie: up to 1200 MHz of fresh spectrum — 59 channels of 20 MHz, 14 of 80 or 7 of 160 — and Chile was among the first countries to open the full band. Before pinning channels by hand, check the full map in the WiFi channels calculator.

Channel width: more lanes, more friction

Doubling the channel width roughly doubles the rate: going from 20 to 40 MHz multiplies the data subcarriers by 2.08, and from 40 to 80 MHz by 2.17 (guard bands get used more efficiently). Sounds like free money, but a wide channel occupies your neighbor's spectrum: a single 40 MHz channel in 2.4 GHz stomps on two of the three clean channels all by itself, and in 5 GHz four APs on 80 MHz can exhaust the non-DFS channels in the area.

The field rule: in dense deployments (offices, buildings, classrooms) use 20 or 40 MHz in 5 GHz and save 80 MHz for where spectrum is plentiful — a detached house, or 6 GHz. A narrow, clean channel outperforms a wide, contested one: co-channel interference never shows up in the signal bars, but it eats your airtime in retries.

MCS: the signal decides how fast you go

Within the channel, speed is set by the modulation. Think of dictating a phone number: on a crystal-clear line you rattle it off in one go; on a noisy line you end up spelling it digit by digit. The MCS index is exactly that ladder: with poor signal, the client drops to BPSK (1 bit per symbol, slow but sturdy); with excellent signal it climbs to 256-QAM (8 bits per symbol) or, on WiFi 6, to 1024-QAM.

Watch out for the number the driver shows: that's the PHY rate, the instantaneous speed while a frame is on the air. Between preambles, ACKs, contention and inter-frame spacing, real throughput on a healthy cell lands around 65 % of PHY. A client at MCS9 on 80 MHz with 1 spatial stream reports 433 Mbps, but iperf will show close to 280. Nothing is broken — that's just how the 802.11 MAC works.

To see which MCS a Linux client negotiated, just ask the driver:

$ iw dev wlan0 station dump | grep -E 'signal|tx bitrate'
        signal:         -58 dBm
        tx bitrate:     433.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 1

The full ladder by standard, width, guard interval and spatial streams lives in the PHY rate (MCS) table. With WiFi 6 and 1024-QAM, the same 80 MHz channel with 1 stream reaches 600 Mbps PHY — if the signal can sustain the modulation, which is a big ask far from the AP.

Airtime: the slow singer hogs the mic

This is where it all comes together. Since there's only one air, what matters isn't how many megabits each client wants, but how much airtime it needs to get them. And time depends on rate: shipping 1 MB at MCS9 takes milliseconds; the same MB at 6 Mbps takes nearly a full second, with everyone else checking their watches. The math is simple: airtime = requested throughput ÷ (PHY × 0.65). Let's run it for the camera from the story:

1. The old camera sits far away and negotiates PHY 6 Mbps (the slowest 802.11g base rate). Its real ceiling is 6 × 0.65 = 3.9 Mbps.
2. Someone configured a 5 Mbps video stream on it. Airtime needed: 5 ÷ 3.9 = 128 %. It doesn't fit: the camera burns 100 % of the cell's air all by itself, delivers barely 3.9 Mbps, and the video still stutters.
3. The meeting-room laptop negotiates MCS9 on 80 MHz: 433 Mbps PHY, about 282 Mbps real (433 × 0.65).
4. Its video call wants 50 Mbps: 50 ÷ 282 = 17.8 % of the air. Five laptops like that could coexist and there'd still be mic time to spare.
5. The moral, with a number: every megabit from the camera costs 72 times more air than one from the laptop (282 ÷ 3.9 ≈ 72). A single slow client degrades every fast one — not because it moves a lot of data, but because it hogs the turn.

You can play with these scenarios — mix clients, rates and demands, and watch the cell hit the wall — in the airtime and capacity calculator.

Quick design: the cell that performs

With all of the above, decent cell design fits in three rules:

• Cell edge between -65 and -67 dBm, measured with your weakest real client (the cheap phone, not your big-antenna laptop). At that signal, clients hold high MCS and nobody sings at 6 Mbps.
• Alternate channels between neighboring APs: 1/6/11 in 2.4 GHz, and in 5 GHz never repeat a channel between cells that can hear each other. Two APs on the same channel don't add capacity — they share one microphone.
• Moderate power. The link is a round trip: an AP at full power reaches far, but the phone — transmitting a lot less — can't answer back. The result is that lying cell with full bars and packet loss. Aim for AP and client at similar power; you can work out EIRP in the antenna and RF calculator.

And if the problem is getting signal from one building to another, that's not a cell anymore — it's a radio link. Size it with the wireless link calculator instead of stretching an AP past its dignity.

Now, into the field: walk the area watching signal and negotiated rate on your phone, pin channels with the channels calculator, and run your slowest clients through the airtime tool. If the cell is still slow after that, you know exactly whose microphone to take away.

The link went up in the dry season and it was glorious. Solid signal, 2 ms ping, happy customer, photo for the company feed. Then winter arrived, and the link started dropping every rainy afternoon. Bad luck? No — arithmetic nobody did. A point-to-point radio link is not something you "install and see if it works"; you calculate it first, with math that fits on a napkin. This guide is that napkin, with every number shown.

The link budget: one sum on a napkin

Think of the link like your paycheck at the end of the month. Transmit power is income, the path charges tolls, and the antennas are bonuses paid at both ends. What reaches the receiver is:

Prx = Ptx + Gtx − Lcables − FSPL + Grx

Here Ptx is the radio's power in dBm, Gtx and Grx are the antenna gains in dBi, Lcables covers coax and connector losses, and FSPL is free-space path loss — the big toll. Everything is in decibels, and that's precisely the point: dB turn horrible multiplications into grade-school addition. Mind the units, though: dBm is absolute power (referenced to 1 mW), dB is a ratio, and dBi is gain relative to an isotropic antenna. They add up cleanly exactly because ratios scale absolute power. If dBm still gives you the side-eye, spend two minutes with the dBm/mW converter: 23 dBm is about 200 mW, 30 dBm is 1 W, and up it goes.

There is exactly one rule of survival: if Prx − receiver sensitivity ≥ margin, the link lives. Sensitivity is the floor the manufacturer declares for each modulation, and margin is your cushion against the real world — aim for 10–15 dB, not less. Everything else in this guide exists to fill that inequality with honest numbers.

FSPL: the toll the vacuum charges

"Free-space path loss" sounds like the air soaks up your signal, but nothing gets absorbed: it's pure geometry. Energy leaves the antenna and spreads over an ever-growing sphere, while your receiving antenna always captures the same little window of it. Farther away, bigger sphere, smaller slice. The formula, with frequency in MHz and distance in km:

FSPL = 32.45 + 20·log10(f) + 20·log10(d)

$ fspl --freq 5800 --dist 10
FSPL = 32.45 + 20·log10(5800) + 20·log10(10)
     = 32.45 + 75.27 + 20.00
     = 127.7 dB

That 127.7 dB means roughly one part in six trillion of what you transmitted actually arrives. Sounds apocalyptic, but modern receivers hear −90 dBm signals without breaking a sweat, so the math works out. Two properties of the formula let you think fast in the field:

• Doubling the distance always costs +6 dB. And the logarithm does something curious: the first kilometer at 5.8 GHz already costs 107.7 dB; the other nine add barely 20 dB more. Existing is expensive; traveling is cheap.
• Going up in frequency costs too: moving from 2.4 to 5.8 GHz adds 7.7 dB of loss over the same path. In exchange you get cleaner spectrum and more compact antennas for the same gain — at 5.8 GHz the wave is about 5.2 cm long, versus 12.5 cm at 2.4 GHz (play with the frequency and wavelength converter).

EIRP: what actually leaves the antenna

An antenna amplifies nothing — it has no watts to give — but it concentrates. A 14 dBi antenna takes energy that would go everywhere and squeezes it into a beam, like going from a bare bulb to a flashlight. The "apparent" power in the beam's direction is the EIRP:

EIRP = Ptx + Gantenna − Lcables

With a 23 dBm radio, a 14 dBi antenna and a 1 dB jumper: 23 + 14 − 1 = 36 dBm ≈ 4 W equivalent, out of a device that draws less than a light bulb. The antenna and RF converter does these sums for you, including the dBi↔dBd conversions that catalogs use to keep you humble.

On the legal side, two sentences and no more: unlicensed bands carry EIRP limits set by each country's regulator — in Chile, SUBTEL — typically around 36 dBm for point-to-multipoint, with more headroom for point-to-point links using directional antennas. Before cranking up power, check the current rules for your band: the fine always costs more than the better antenna.

The Fresnel zone: the invisible sausage

This is where most "properly installed" links go to die. A radio signal doesn't travel along a string between the two antennas: it occupies a volume shaped like an ellipsoid — an invisible sausage, fat in the middle and tapered at the ends. If anything pokes into that sausage, part of the energy diffracts and arrives out of phase, subtracting from the direct signal. The result: you can see the far tower through binoculars and the link still performs like dial-up.

The first-zone radius at the middle of the path, with d in km and f in GHz:

r = 8.657 × √(d / f)

For our 10 km at 5.8 GHz: r = 8.657 × √(10/5.8) ≈ 11.4 m. In practice you clear 60% of that radius — about 6.8 m of nothing below the line of sight at mid-path — because inside the 60% core, diffraction doesn't bite yet. And note where frequency sits in the formula: dividing. At 2.4 GHz the sausage fattens to a 17.7 m radius. Lower frequencies forgive rain, not obstacles.

Two details separate the engineer who calculates from the one who prays. First, the Earth is curved: over a 10 km path the planet pushes a bulge of about a meter and a half into the midpoint, stacked on top of whatever obstacle is there. Second, obstacles grow: a young pine or eucalyptus gifts you one or two meters per year. The clearance that looks generous today is a support ticket in three winters. The wireless link calculator hands you the Fresnel radius along with the rest of the budget so you don't eyeball it.

Worked example: 10 km at 5.8 GHz, step by step

Let's put it all together. A typical rural link: 10 km between a hilltop and a plant, 5.8 GHz band, integrated radios mounted right at the antenna (cable loss ≈ 0).

1. Write down the inputs. Ptx = 23 dBm, 14 dBi antennas on both ends, sensitivity = −85 dBm for the modulation you need. Careful here: datasheets brag about the sensitivity of the slowest modulation; use the one for the data rate you actually plan to deliver.
2. Compute the toll. FSPL = 32.45 + 20·log10(5800) + 20·log10(10) = 32.45 + 75.27 + 20 = 127.7 dB.
3. Climb the ladder. You leave at 23 dBm, the antenna lifts you to 23 + 14 = 37 dBm of EIRP, the path drops you to 37 − 127.7 = −90.7 dBm, and the receiving antenna pulls you back up: −90.7 + 14 = Prx ≈ −76.7 dBm.
4. Measure the cushion. Margin = −76.7 − (−85) = 8.3 dB.
5. Pass the verdict. The link lights up and looks splendid on a sunny day… but 8.3 dB is below the recommended 10–15 dB. This is, precisely, the link from the first paragraph of this guide: the one that drops when winter shows up.
6. Fix it on paper, where it's free. 20 dBi antennas on both ends add 12 dB to the budget: a 20.3 dB margin, a link built for winter. The other lever is shortening the hop with a repeater; raising Ptx is usually capped by regulation.

Fade margin, VSWR and the coax that charges by the meter

Why 10–15 dB of margin and not 3? Because FSPL is the only polite term in the equation; the rest of the world moves. Reflections off water or metal roofs arriving out of phase (multipath), foliage that doubles its weight in winter water, atmospheric ducts that bend the beam. Dinner-table fact: below 10 GHz, rain itself barely attenuates — at 5.8 GHz, fractions of a dB per kilometer even in a downpour — but everything that comes with the rain (soaked leaves, fresh reflections, wind shaking the dish) absolutely does. Above 10 GHz, in the licensed bands, rain becomes the main character of the calculation. Margin is your insurance against all of it at once.

VSWR: the signal that bounces before leaving

Between the radio and the antenna there's another battlefield. VSWR measures how much signal bounces back at an impedance mismatch: at VSWR 1.5, 4% of the power reflects (you lose 0.18 dB); at 2.0, 11% reflects (0.5 dB). The number looks innocent, and that's the trap: the loss isn't the problem — the symptom is. A climbing VSWR means a badly crimped connector, water inside the cable, or a damaged antenna, and those get worse before they get better. The antenna and RF converter translates between VSWR, return loss and reflection coefficient.

Coax: every meter has a price tag

And the silent classic: the cable. Coax charges by the meter, raises its rates with frequency (proportional to √f), and never negotiates:

Approximate nominal values; at 5.8 GHz multiply by ~1.55. Translation: 20 m of RG-58 at 2.4 GHz is 10.1 dB — more than the entire margin of our worked example, burned inside a plastic tube. The coax loss calculator interpolates by cable type, frequency and exact length.

Now it's your turn: run your next path through the wireless link calculator with real coordinates and real hardware, demand a double-digit margin and 60% Fresnel clearance with the trees three years older. If the sum doesn't work on paper, it won't work on the roof.

The tech swore the fiber was bad. Ten kilometers freshly pulled between two plants, brand-new SFP modules, and a dead link: not a single blink on the port. There was talk of renting an OTDR, calling in a crew, re-pulling the whole run. Then somebody unplugged the patch cord, gave the connector one pass with a cleaning pen, and the link came up before the coffee got cold. Final diagnosis: a fingerprint.

This guide exists so that never happens to you — or so that when it does, you are the one holding the pen. Fiber stops being mysterious the moment you see it for what it is: a toll road for light. Every kilometer, every connector and every splice collects its fee in dB, and your job is to make sure the light reaches the far end with money left in its pocket.

Singlemode and multimode: two ways to move light

Every fiber shares the same anatomy: an ultra-pure glass core where the light travels, a 125 µm cladding that keeps it bouncing inside, and protective layers around it. The difference that matters is the core diameter, and it is dramatic.

Singlemode (SM) fiber has a core of just 9 µm — a human hair (~70 µm) is about eight times thicker. Through a tunnel that narrow, light can only travel one way: a single mode, dead straight. That demands a laser as the source (1310 or 1550 nm), but in exchange the signal doesn't smear and it covers tens of kilometers: a 10GBASE-LR optic does 10 km without breaking a sweat, and 1550 nm parts reach 40 or 80.

Multimode (MM) fiber has a 50 µm core (OM3, OM4 and OM5): about 31 times the area. That wide tunnel accepts light from cheap sources — 850 nm VCSELs — but it lets the light take many paths at once: some rays bounce more, some less, and the pulse arrives smeared out in time. That modal dispersion sets the limit: at 10 Gbps, OM3 reaches 300 m and OM4 reaches 400 m. Hundreds of meters, not kilometers.

In the field, the jacket tips you off before you read any label: yellow = singlemode; aqua = OM3/OM4 (OM4 sometimes ships in violet, OM5 in lime green); orange gives away legacy OM1/OM2 that deserves retirement. Rule of thumb: inside the rack or the data center, multimode keeps the optics cheap; between buildings or beyond 300–400 m, singlemode, no debate. If you're unsure how far each fiber-and-speed combo goes, the fiber reach calculator has the full IEEE table.

The dB is a toll (charged in percentages)

The decibel looks scary because it's logarithmic, but the intuition fits in two lines: −3 dB means "half the light is left" and −10 dB means "a tenth is left". The beauty of working in dB is that the tolls don't multiply — they add. Three 0.5 dB connectors are 1.5 dB, period. If you want to play with conversions between dB, dBm and milliwatts, that's what the dBm calculator is for.

So what does each toll booth charge? Modern singlemode fiber typically loses 0.35 dB/km at 1310 nm and 0.22 dB/km at 1550 nm. In percentage terms: each kilometer at 1310 lets 92% of the light through. Sounds generous — until you compound it and find only 45% left after 10 km. That's why budgets are built with a calculator, not with optimism.

Notice the uncomfortable detail in that table: a single connector can cost as much as two kilometers of fiber. Distance is the predictable toll; connectors are where the budget is won or lost.

The loss budget: do the math before pulling cable

A loss budget answers exactly one question: does the light leaving the transmitter reach the receiver with enough power? Let's run the full numbers on a real link: 10 km of singlemode at 1310 nm, with 4 connectors (patch cord and ODF at each end) and 2 fusion splices along the route. The transmitter puts out −3 dBm and the receiver's sensitivity is −14 dBm.

1. Fiber: 10 km × 0.35 dB/km = 3.5 dB.
2. Connectors: 4 × 0.5 dB = 2.0 dB.
3. Fusion splices: 2 × 0.1 dB = 0.2 dB.
4. Total loss: 3.5 + 2.0 + 0.2 = 5.7 dB.
5. Power arriving: −3 dBm − 5.7 dB = −8.7 dBm.
6. Margin: −8.7 − (−14) = 5.3 dB. The link lights up, with healthy headroom.

Those 5.7 dB mean only 27% of the light that left actually arrives — and it's still plenty, because the receiver hears all the way down to −14 dBm. That 5.3 dB cushion isn't luxury, it's life insurance: fiber ages, connectors get dirty, and one day a rodent or a backhoe will gift you a couple of extra splices.

In the field you verify this with a light source and a power meter: set the reference at one end, measure at the other. If the whiteboard math and the instrument agree within 1 dB, you can sleep well.

Tx (ref) −3.0 dBm
Rx (field) −8.7 dBm
loss 5.7 dB
sensitivity −14.0 dBm
margin 5.3 dB ✓

Enemy #1 is not distance — it's the dirty connector

When a new link won't come up, instinct points at the big stuff: too much distance, broken fiber, fried optics. Field experience points at the small stuff: the connector end-face. Think about the proportions — a singlemode core is 9 µm across, and a common dust particle measures 2 to 5. That's not "a bit of shade": that's a truck parked in the tunnel entrance. A fingerprint is even worse: grease that scatters light in every direction and, at high power, literally bakes onto the ferrule.

The proper ritual has three steps and no shortcuts: inspect, clean, inspect again. Ideally with a fiber scope; lacking one, at minimum clean every time before mating, no exceptions. The tool worth its weight in gold is the one-click cleaning pen: one dry click and done. No blowing on it (that's atomized saliva), no wiping it on your shirt (lint plus scratches).

If the loss is still high after cleaning, then yes: bring out the OTDR or the source-and-meter pair, and hunt for the weak splice or the tight bend. But clean first. Most of the time, the story ends right there.

Windows and WDM: several conversations on one fiber

Why 1310 and 1550 nm, specifically? Because glass doesn't charge evenly: attenuation has valleys at certain wavelengths, and those two are the classic singlemode windows. 1310 is the comfortable window, with nearly zero chromatic dispersion; 1550 is the cheapest in tolls — 0.22 dB/km — which is why it rules long-haul and amplified systems.

And here comes the most profitable idea in modern optics: different colors of light don't mix. You can inject 1310 and 1550 into the same fiber and split them at the far end with a filter, like two conversations in different languages sharing the same room. That's WDM — wavelength division multiplexing. Your home probably uses it already: in GPON, downstream rides on 1490 nm and upstream on 1310, simultaneously, over a single strand.

In its industrial form: CWDM spaces channels every 20 nm (up to 18 channels between 1271 and 1611 nm) using economical optics; DWDM squeezes them every 100 GHz — about 0.8 nm around 1550 — or even tighter, packing dozens of amplifiable channels onto the same strand. The DWDM/CWDM grid tool converts between channel, frequency and wavelength when planning time comes. Bonus fact: inside glass, light travels at roughly 204,000 km/s, so every kilometer adds ~4.9 µs one-way; you can play with that in the fiber latency calculator.

Too much light is also a failure

An optical receiver has a working range, not just a floor. Below sits the sensitivity (−14 dBm in our example); above sits the overload point, where so much light saturates it and bits start to corrupt — typically around 0 dBm on common modules. Sounds like a rich person's problem, but it's a classic: you bench-test a 40 km optic with a two-meter patch cord and the link "mysteriously" drops packets.

The cure costs pocket change: a fixed attenuator of 5 or 10 dB at the receiving end, turning the volume down. The optical Rx margin calculator warns you when you're in saturation territory, on top of computing the margin against sensitivity.

Now put it to work: build the budget for your next link in the loss budget calculator before buying a single meter of cable, and get yourself a one-click cleaning pen today — it's the best return-per-gram tool in your whole kit. Fiber holds no mystery: just add-and-subtract arithmetic, and connectors that reward cleanliness.

It's a textbook scene: two company buildings across a parking lot, some 600 meters of yard between them, and the order to "get 40 gigs from one side to the other". The contractor showed up with a spool of OM4 multimode fiber — "the good one, the thick orange stuff" — and a pair of SR4 modules. Pulled it, spliced it, plugged it in… and the link wouldn't even come up. It's not bad luck or a dead module: at 40G that fiber reaches 150 meters, and the yard is 600. The physics of light doesn't negotiate either.

Picking fiber looks like a specialist's job, but it boils down to three questions with concrete answers: singlemode or multimode? which cable construction for where it runs? and which jacket does the fire code demand? What follows is that decision, in order, with the whys — because a badly chosen fiber link doesn't "run slow", it simply doesn't light up.

Singlemode vs multimode: it's the core diameter

The whole difference starts with one number: the diameter of the core, the glass strand the light travels through. In singlemode (OS1/OS2) that core is a mere ~9 µm — so thin the light can only take one path, a single mode, straight as a ruler. It's driven by a laser at 1310 or 1550 nm, has very low loss, and so it travels kilometers without falling apart.

In multimode the core is far wider: 62.5 µm in the old OM1 and 50 µm in OM2/OM3/OM4/OM5. That big diameter lets light enter at many angles at once — many "modes" — and each ray bounces along a different path inside the glass. It's driven by an LED or VCSEL at 850 nm, cheap optics. The problem shows up far away: the rays that bounce more travel farther than the ones going nearly straight, so they arrive at the far end out of phase. That smearing of the pulse is called modal dispersion, and it's the physical reason multimode is short-legged.

Let's kill a myth once and for all: plenty of people think multimode is "faster" because the cable is thicker and the optics cheaper. It isn't. The thick core is precisely its limit. The thin laser light of singlemode, traveling one single path, is what carries 10, 40, 100 and even 400 Gb/s down the same strand at distances multimode can only dream of. Multimode wins on exactly one turf: short and cheap inside the datacenter or the building.

When to use each? The field rule

The real decision is almost always driven by distance, and second by the link's future.

Choose SINGLEMODE (OS2) when: it's a campus or WAN link, the run exceeds ~550 m, it's a backbone you want future-proof (10G today, 100G tomorrow on the same strand with no re-pull), it goes through long outdoor stretches, or it hands off to a carrier. Choose MULTIMODE (OM3/OM4) when: it's inside a single building or room, the distances are short (datacenter patching, floor links), or when multimode plant already exists and you want to keep using it.

OM/OS grades and real distances (IEEE 802.3)

Each fiber grade has maximum distances that are measured and standardized, not marketing. These are the ones that matter for sizing:

The thing that jumps out: OM4, the best common multimode, reaches only 150 m at 40/100G. OM3 reaches 100 m. Meanwhile OS2 singlemode does 10 km with standard LR4 optics, and 40 km with ER modules. Between 150 m and 10 km lies a chasm, and that chasm is the whole conversation. OM5 doesn't "go farther" than OM4 on a single color: its trick is supporting SWDM (several wavelengths 850–950 nm on the same strand) to multiply capacity on short runs. You can check your run against these limits in the fiber reach calculator before buying a single meter.

Cable construction: where it runs dictates the structure

The very same glass strand can come built in very different ways depending on the environment. Mixing them up guarantees failure within months.

Tight-buffered: each fiber is coated with a firm plastic layer bonded to the glass. It's flexible, easy to terminate, and survives handling. This is the indoor construction: in-building backbones, patch cords, rack cables.

Loose-tube: the fibers float freely inside tubes filled with gel. That gel blocks moisture, and the slack lets the cable expand and contract with temperature without stretching the glass. This is the outdoor construction: between buildings, buried, aerial. If you see gel, it's meant for outside.

Ribbon: the fibers are bonded into flat ribbons of 12, packing 144, 288 or more fibers into an ultra-thin cable. It lets you fuse 12 at a time and feeds high-density MPO connectors. This is what large datacenters and carrier trunks use.

For hostile outdoors there are two reinforcements worth knowing: armor (a corrugated metal tape under the jacket that stops rodents — yes, rats chew fiber — and crushing), and ADSS (All-Dielectric Self-Supporting), a fully dielectric, self-supporting cable hung between poles with no metal messenger, ideal for aerial runs alongside power lines because it doesn't conduct.

Jacket: the fire rating is code, same as copper

The outer jacket isn't just a color: it defines how safe the cable is in a fire and where the code lets you run it. It's exactly the same logic as in copper.

The practical hierarchy: if a space handles air return (the drop ceiling the AC pulls air back through) it demands plenum (OFNP), because a cable burning there spreads toxic smoke across the whole building. Vertical shafts running between floors call for riser (OFNR), which won't let fire climb. Plenum can always replace riser, never the reverse. LSZH is the European and confined-space philosophy: zero halogens, almost no smoke. Fitting a lower-class cable "because it's cheaper" isn't a saving: it's the finding that stalls your project handover.

Connectors: LC, SC and MPO, plus the polish you never mix

The connector is where the light goes in and out, and there are decisions there too. By size and use:

LC: the small one, with an RJ-style latch, almost always duplex (one fiber transmits, another receives). It's today's standard: the sky-high density of SFP+ ports crowned it. SC: the big square push-pull type, rugged, still common on carrier ODFs and GPON gear. MPO/MTP: the parallel connector, packing 12 or 24 fibers into a single face. It's not about more speed per fiber, but about carrying many strands together: it's what feeds 40G and 100G SR4, where the link uses 4 fibers to transmit and 4 to receive in parallel.

Mind simplex vs duplex: simplex is a single fiber (for BiDi or single-fiber); duplex is two, the normal case of a bidirectional link. And the detail that torches projects: the ferrule polish. UPC (Ultra Physical Contact, blue housing) has a flat-polished face. APC (Angled Physical Contact, green housing) is polished at an 8° angle, returning far less reflection and mandatory on sensitive links like GPON and RF video.

Example: 40 Gb/s between two buildings 600 m apart

Back to the opening scene, done right this time, with the standard's numbers:

1. The requirement: 40 Gb/s between two buildings 600 m apart, a campus run across the parking lot.
2. Test the OM4 multimode option: at 40G (40GBASE-SR4) OM4 reaches 150 m. The run is 600 m → 600 > 150. It doesn't reach, not close: short by a factor of 4.
3. What about OM3? Worse: at 40G it reaches 100 m. Ruled out.
4. Test OS2 singlemode: at 40G with LR4 optics OS2 reaches 10 km = 10,000 m. The run is 600 m → 600 < 10,000. Plenty to spare (over 16 times the margin).
5. It's also outdoor and long: the cable must be loose-tube (with gel, for moisture and temperature), ideally armored against rodents, and spliced to an indoor riser/plenum cable at each entry point.
6. Conclusion: pull OS2 singlemode with LR4 modules and LC connectors. It doesn't just solve the 600 m: it leaves the link ready to jump to 100G on the same strand the day it's needed, without touching the yard again.

The field lesson: when the run passes a couple hundred meters or you're going to bump up the speed, the question is no longer "which multimode?", it's "singlemode, for sure". Before buying, verify reach in the fiber reach calculator and close the link with the fiber loss budget to add up connector and splice loss.

Close the link, don't just pull it

Choosing the fiber well is half of it; the other half is making sure the light leaving the transmitter arrives at the receiver with enough power. Each connector adds on the order of 0.3 dB, each splice ~0.1 dB, and each kilometer of OS2 ~0.35 dB at 1310 nm. Add all of that, compare it against the module's power, and you'll see if the link closes with margin. That math is done by the fiber loss budget and the optical Rx margin, and it's worth converting units with the dBm/mW converter so you don't get lost between milliwatts and decibels.

Two useful closers: if the run is very long and you need to squeeze the fiber, wavelength-division multiplexing packs several channels onto one strand — size the grid with the DWDM/CWDM planner. And if the project is delay-sensitive (trading, sync, remote storage), remember light in fiber travels at ~5 µs per kilometer: measure the real delay with the fiber latency calculator. Well-chosen fiber gives no trouble for years; badly chosen fiber won't light up on day one. Choose by distance and by future, and let physics play in your favor.

Every integrator has met this job: the gate camera ended up 130 meters from the rack — "relax, it's good cable" — and the link drops every time it rains. The installer swears it's genuine Cat6, box and all. Doesn't matter: the standard says 100 meters, and physics doesn't negotiate with the brand on the jacket.

The good news is that structured cabling holds no mysteries. The complete recipe has been sitting in the TIA-568 family since the nineties: how much cable, which kind, which order the colors go in, and how much room to leave in the pathway. What follows is that recipe, with the whys — because a tech who understands the why never pulls 130 meters "because it's good cable" again.

The 100-meter channel: 90 + 10, and not an inch more

The famous 100-meter limit is not a round number someone picked out of laziness. It's a channel with two well-defined parts: up to 90 m of permanent link (the solid-conductor cable running through walls, tray or trunking, from the outlet to the patch panel) and up to 10 m of patch cords split between both ends — typically 5 m in the cabinet and 5 m at the desk.

Why that split, instead of just "100 meters of cable"? Because patch cords use stranded conductors (so they can flex without breaking), and stranded wire attenuates on the order of 20 % more per meter than the solid conductor in the fixed run. The standard did its attenuation math with exactly that mix — 90 m solid plus 10 m stranded — and that is where the budget closes. Pull a 100 m permanent link and hang a 5 m patch cord on each end, and you're not "barely over": you're outside the model everything else was designed around. Before promising a far-away drop, run it through the TIA-568 channel calculator and settle it in ten seconds.

Categories, minus the marketing

The cable box promises wonders; the standard promises measurable things. Here is what each category actually delivers over a full 100 m channel:

The number the marketing always leaves out: Cat6 does run 10 Gb/s, but only up to 55 m — and in a bundle with many cables running side by side (where alien crosstalk, the interference between neighboring cables, takes over), the recommendation drops to 37 m. If the project says 10G across a whole floor, the short answer is Cat6A. Worth knowing too: Cat5e supports 2.5GBASE-T at a full 100 m thanks to 802.3bz, which gave a second life to plenty of older plants feeding WiFi 6 access points.

What about shielding?

Shielded cable (F/UTP, S/FTP) isn't simply "better": it's a tool for specific problems. It earns its keep in industrial plants full of VFDs and motors, near radio transmitters, and in dense high-power PoE bundles where the shield also helps carry heat away. Outside those cases, well-installed UTP certifies just fine. And beware: a shield without proper grounding (bonded at the patch panel, with shielded hardware down the whole chain) turns into an antenna — worse than no shield at all.

T568B: the eight colors you should know cold

Across the Americas the de facto standard is T568B (T568A survives in government work and the residential standard). The order, pin by pin, holding the plug clip-down with the contacts facing you:

Here's the detail that separates memorizing from understanding: pins 3 and 6 form a single twisted pair. The twist is what cancels the noise — the two halves of the signal travel wrapped around each other, so interference hits both equally and subtracts itself out. That's why the color order matters: it's not aesthetics, it's guaranteeing every signal rides on a genuinely twisted pair.

Straight-through or crossover? Straight: T568B on both ends. Crossover: B on one end, A on the other (it swaps pairs 2 and 3). These days it's almost trivia: virtually every gigabit port ships with Auto-MDIX and crosses the pairs itself when needed. Still, don't mix A and B within one installation: pick B, write it into the as-built docs, done. If you want the pinout handy in the field, it lives in the color code tool.

PoE: the same cable now carries watts

For twenty years twisted pair carried nothing but signal. Now it powers cameras, APs, phones and even displays: 802.3af delivers 15.4 W from the switch, 802.3at raises that to 30 W, and 802.3bt reaches 90 W. Which introduces a cost that didn't exist before: the cable charges a toll in watts. Under af, up to 2.45 W can stay behind in the copper; under at, 4.5 W; under bt Type 4, up to 18.7 W — nearly a whole LED bulb's worth of heat cooking your cabling.

That toll depends on conductor resistance, and this is where gauge stops being fine print: 23 AWG Cat6 has 21 % less resistance than 24 AWG (66.6 vs 84.0 Ω/km per conductor). Less resistance means less drop, less heat, and more watts arriving at the device. For dense PoE or long runs, 23 AWG pays for itself. Size the total switch load with the PoE budget tool and check what distance costs you with the voltage drop calculator.

Heat also piles up wherever the cable can't breathe. Coiling the 8 spare meters into a tight loop behind the camera was harmless with data alone; with PoE, that coil is a miniature space heater where every turn warms its neighbor. Leave slack in a loose "S" on the tray — or better, cut to length. The same goes for fat bundles of 50 PoE cables: the tighter the bundle, the hotter its core, and attenuation gets worse as temperature climbs.

Pathways: the 40 % rule fills up faster than you think

The NEC caps conduit fill at 53 % with one cable, 31 % with two, and 40 % with three or more. The rule was written for conduit, but use it as the practical ceiling for trunking too: it leaves room to pull without tearing jackets, room to grow, and somewhere for PoE heat to go. Why 40 and not 100? Because cables are cylinders: you couldn't tile the area with circles even if you tried, and forcing them scrapes jackets and crushes twists.

Let's run the full calculation — the same one the conduit fill calculator does:

1. Internal area of the trunking: 40 mm × 25 mm = 1000 mm².
2. Apply the 40 % limit: 1000 × 0.40 = 400 mm² usable (three or more cables, so the 40 % rule applies).
3. Area of one cable: typical Cat6 has an outside diameter (OD) of 6 mm → π × 3² = 28.3 mm². Always use the OD from the datasheet: across brands it ranges from 5.5 to 7.5 mm, and the result swings hard.
4. Divide and round down: 400 ÷ 28.3 = 14.1 → 14 cables. The decimal never rounds in your favor: a cable either fits whole or it doesn't.
5. Check: 14 × 28.3 = 396 mm² → 39.6 % fill. Just under the ceiling.
6. Cable number 15 breaks the rule: you'd land at 42.4 % — out of spec, and in practice already pulling hard enough to scrape jackets.

Patch panels and the moment of truth

The same headroom philosophy applies in the rack. The rule of thumb: 25 % spare on top of day-one drops. Got 38 network points? 38 × 1.25 = 47.5 → 48 ports: two 24-port panels, with one horizontal cable manager per panel (yes, each "wastes" 1U — and it's the difference between a maintainable rack and a patch-cord salad nobody wants to reach into). The full count of panels, managers and rack units comes out of the patch panel planner.

And at the end of the project comes the question that separates a professional installation from a pile of pulled cables: certify, or "test with the LED"? The LED tester checks continuity and wire map — that each conductor lands where it should. Nothing else. It measures no attenuation, no NEXT, no return loss, not even true length. A split pair, an over-untwisted jack or a cable pinched by drywall all sail through the LED test. A certifier, by contrast, compares every link against the standard's limits, frequency by frequency, and produces a per-drop report: that is what backs the manufacturer's warranty (often 20+ years on structured cabling) and what defends you when the client says "the network feels slow".

Certifying costs money; going back on site costs more. If the budget won't cover your own certifier, rent one for handover or subcontract the certification: it's a small line item that deletes an entire category of ghost failures.

Now put it to work: check your runs against the 100 m channel, size pathway with the 40 % fill calculator, and build the rack with 25 % spare using the patch panel planner. The standard did the hard part thirty years ago; your job is simply not to argue with it.

The client asked for "the best cable, spare no expense" for a two-floor office, and the shop salesman sold him pricey rolls of "shielded Cat7". The installer shows up, opens the box, and finds a thick, stiff S/FTP with a drain wire per pair that nobody knows where to ground. He ends up fighting every connector, the rack fills with loose braids hanging in the air, and to top it off the link certifies exactly like a Cat6A U/UTP at half the price. The field lesson is an old one: the "best" cable doesn't exist; the right cable for this job does.

Choosing copper well means understanding five decisions that travel together: the category (how much bandwidth), the shielding (how much noise protection), solid or stranded (stiffness versus flexibility), the AWG gauge (how thick the copper is) and the jacket (what the building code demands). None of them is a matter of taste or of what the box says: each has a measurable why. Let's take them one at a time.

Categories: what each one actually delivers

The category sets the cable's guaranteed bandwidth, in megahertz, and from there comes the speed and distance it can run. The trick is that the box sells you the big number and drops the distance. Here is what each category truly delivers, always over the full 100 m channel:

Cat5e looked retired, but 802.3bz gave it a second life: it runs 2.5GBASE-T at a full 100 m, exactly what a modern WiFi 6 AP asks for. For plain 1 Gb/s it's still perfect and cheap. Cat6 is today's sensible office floor: 1G at 100 m, no drama. The number marketing hides is its 10G: Cat6 does run 10GBASE-T, but only up to 55 m in a good environment, and in a tight bundle with many cables running side by side the recommendation drops to 37 m because of the crosstalk between neighboring cables (alien crosstalk). Cat6A is the one that runs 10G over the full 100 m, which is why it's the answer whenever the project talks about ten gigabit across a floor.

Shielding: when to, and when not to

Shielding protects against external electromagnetic interference (EMI), and it comes in three flavors worth naming properly. U/UTP is unshielded: four twisted pairs and the jacket, that's it. F/UTP adds an overall foil wrapping all four pairs together. S/FTP is the full package: a braided screen around everything, plus an individual foil on each pair. The nomenclature reads "overall-shield / per-pair-shield-UTP".

When should you shield? In industrial plants full of variable-frequency drives, big motors and welding; near radio transmitters; in trays that share space with power; and in very dense 10G installs, where the foil cuts the alien crosstalk between tightly packed neighbors. Outside those cases —which is to say, the vast majority of offices, schools and clinics— a well-installed U/UTP certifies just the same and is far easier to terminate. Shielding adds stiffness, raises the cost of every connector and, above all, demands a flawless grounding chain.

Solid or stranded: each to its post

Copper comes in two builds. Solid is a single wire per conductor: lower attenuation, punches down cleanly into jacks and patch panels, and it's what goes in the permanent link —the fixed run through wall, trunking or tray. Stranded twists several fine wires per conductor: it bends a thousand times without breaking, which is why it's what patch cords are made of. The price of that flexibility is more attenuation, on the order of 20 % more per meter.

That's why the 100 m channel splits into 90 m of solid plus 10 m of stranded: the standard did its math with exactly that mix. Adding extra patch cords, or —worse— punching solid cable into a patch-cord plug (which expects stranded wires), steps outside the model and collects intermittent faults. Rule of thumb: solid for what doesn't move, stranded for what gets plugged and unplugged.

The AWG gauge: thickness matters (especially with PoE)

AWG measures conductor thickness, and it runs backwards from intuition: smaller number, thicker copper. A 23 AWG Cat6 is thicker than a 24 AWG one and has about 21 % less resistance (66.6 vs 84.0 Ω/km per conductor). Less resistance means less voltage drop, less heat and more usable distance, especially when the cable carries power. That's why 23 AWG is the favorite for high PoE and long runs.

At the other end are the "slim" 28 AWG patch cords, those skinny ones that look tidy in the rack. They're handy and take little space, but their thin copper has considerably more resistance: you must shorten the channel distance when you use them (makers publish reduction tables) and you shouldn't run them on links with high PoE. Lovely for 30 cm between panel and switch; bad as a replacement for a 5 m patch that also powers a camera.

PoE and heat: the bundle heats up

Today that same twisted pair carries watts: 802.3af delivers 15.4 W, 802.3at raises it to 30 W, and 802.3bt (PoE++, Type 3 and 4) reaches up to 90 W from the switch. That current heats the copper, and when you bundle 24, 48 or more PoE cables tightly, each one's heat adds up and the core of the bundle climbs in temperature. The problem is twofold: copper resistance rises with temperature (more drop, fewer watts to the device) and attenuation gets worse too. That's why the standards apply a derating: the fuller and tighter the bundle, the lower the current capacity per cable.

The recipe against heat has three parts. First, thick gauge: for PoE Type 3/4, 23 AWG (and, frankly, Cat6A) dissipates and drops less. Second, don't saturate the pathway: leaving air between cables helps the heat escape. Third, don't coil the slack: that tight loop behind the camera was harmless with data, but with PoE it's a miniature space heater where every turn warms its neighbor. Leave a loose "S" or cut to length. You can size the total switch load with the PoE budget tool and check the effect of distance with the voltage drop calculator.

The jacket: it's a code matter, not a preference

The outer jacket doesn't change data performance, but it defines where you're allowed to run the cable under the building and fire-safety code. You don't pick it because it looks nice: you pick it by where it goes.

The costliest confusion is plenum: if the drop ceiling doubles as air-conditioning return (very common in offices and malls), the code requires CMP in that space, because a fire there sends smoke straight into the ducts that ventilate the building. Running CM where CMP was required goes unnoticed by everyone… until the inspection or the fire. And in Chile and much of the world, LSZH is increasingly the default for public spaces, because of the smoke. Always check what the project spec demands before buying the roll.

The decision, no detours

Let's boil it all down to field rules. Cat5e when the project is plain 1G, no heavy PoE, tight budget: it's still honest and cheap, and it even gives you 2.5G for an AP. Cat6 as the sensible floor of a new office when 10G isn't on the horizon or the runs are short. Cat6A when you want 10G at real distance, comfortable PoE++ and a future-proof install: it's today's sweet spot. "Cat7" in an office is almost always marketing, and "Cat8" is datacenter. On shielding: U/UTP by default, and F/UTP or S/FTP only when the environment (industrial EMI or very dense 10G) justifies it and you can ground it properly.

A real case to tie it together: you have to pick cable for a WiFi 6 access point with PoE++ (802.3bt Type 4), 90 m from the switch, and the client wants it "10G-ready" for the next upgrade. The reasoning, step by step:

1. Distance: 90 m of permanent link + patch cords fit inside the 100 m channel. Any category from Cat5e up meets the distance for 1G, so distance alone doesn't decide. Confirm it with the TIA-568 channel.
2. 10G-ready requirement: at 90 m, Cat6 doesn't run 10GBASE-T (its ceiling is 55 m, and less in a bundle). Only Cat6A guarantees 10G at 90–100 m. That already rules out Cat5e and Cat6.
3. High PoE: with PoE++ (802.3bt) the switch delivers up to 60 W per port on Type 3 and up to 90 W on Type 4 (PSE); the load receives about 51 W or 71 W (PD) depending on the type. That current heats the copper and drops with distance, so the thicker conductor is preferable: choose 23 AWG, standard on good-brand Cat6A.
4. Shielding: it's an office, not an industrial plant. A U/UTP Cat6A certifies 10G with no trouble and is easier to terminate; there's no EMI to justify shielding or the hassle of grounding braids.
5. Bundle and heat: since it carries PoE++, don't saturate the trunking and don't coil the slack; leave air. Check the fill with the conduit fill calculator.
6. Conclusion: Cat6A U/UTP, 23 AWG, jacket per where it runs (CMP if it goes above a ceiling with air return, LSZH if the project asks for it). It meets the distance, guarantees the future 10G, and the thick gauge appreciates the high PoE.

With that you have the whole map. Validate distances against the 100 m channel, check the load with the PoE budget, watch the conduit fill, and keep the color code handy when you terminate. The "right" cable isn't the most expensive or the most shielded: it's the one physics and code approve for your job.

The certifier flagged FAIL on fourteen of twenty links and the previous installer swore "the cable was the good Cat6A". It was true: the cable was flawless. The problem was at the ends. Someone had crimped patch-cord RJ45 plugs straight onto the solid wall cable, no panel, no jacks, and plugged them into the switch "to save money". The result: contacts that bite the solid wire badly, intermittent faults every time someone nudges the rack, and a channel that will never certify. The field lesson repeats on every job: a link is worth what its terminations are worth. You can buy the best copper on the market, but if you finish the ends badly, you bought an expensive problem.

This guide is about everything that goes at the ends: the keystone jacks where the solid cable dies, the RJ45 plugs on the patch cords, the patch panels that keep the rack in order and the face plates that finish the work area. Every piece has its rule and its why, and choosing it well matters as much as choosing the cable.

The map first: what gets punched and what gets plugged

Before talking parts, you need the TIA-568 channel model clear: 100 m total, split into 90 m of permanent link (the fixed solid cable, jack to jack) plus 10 m of patch cords (stranded, with plugs). The permanent link starts at the patch-panel jack and ends at the face-plate jack: that is what gets certified, which is why both jacks are part of the link, not an accessory. The patch cords plug in at each end to complete the channel.

From that comes the golden rule the FAIL installer skipped: solid cable gets punched down into jacks and panels; stranded cable gets crimped into plugs. Solid goes in what doesn't move, stranded in what gets plugged and unplugged. The modern exception (MPTL) comes below; the general map is this:

Keystone modules: where the solid cable dies

The keystone jack is the female connector where the solid cable gets punched down, both at the panel and in the wall. And here comes the rule that saves (or wastes) the most money: the jack's category must match the cable's, because the channel certifies by its weakest component. A Cat5e jack punched onto a Cat6A run doesn't "lose a little": it degrades the whole channel to Cat5e, and the certifier will say so with zero anesthesia. If the project is Cat6A, everything is Cat6A: cable, jacks, panel and patch cords.

There are two schools of termination. The classic 110 punch-down: you lay each wire in its slot following the color code and seat it with the impact tool, which inserts and trims in one strike. It's cheap, reliable and fast once your hand is trained. Toolless jacks bring a cap that seats all eight wires at once when you close it: notably faster for new hands and more comfortable on a ladder or above the ceiling, but they cost more per unit. Electrically, well executed, both certify the same: the choice is about productivity and budget, not performance.

If the cable is shielded (F/UTP or S/FTP), the jack must be too: the shielded jack has a metal body that takes the cable's foil or braid and gives it shield continuity all the way to the panel, where the chain gets grounded. A shielded cable terminated in plastic jacks leaves the braid floating, and a floating braid is an antenna. And if the cable is U/UTP, use unshielded jacks: paying for a metal body on a cable with no braid is money down the drain.

RJ45 plugs: the male has its rules

The RJ45 plug (technically 8P8C) is the male connector crimped onto the ends of patch cords. Its contacts are designed to bite stranded cable: the blades sink between the fine twisted strands and hold firm. On a solid conductor, though, the blade can end up leaning against the side and making contact "sometimes": the classic intermittent fault. That's why the everyday plug belongs on the patch cord, not on the wall.

The modern exception is called MPTL (modular plug terminated link): TIA-568.2-D recognizes terminating solid cable directly into a field plug designed for solid conductors, for cases where a box with a jack makes no sense: IP cameras on a pole, access points above the ceiling, sensors. Mind the two conditions: you use plugs specifically rated for solid (the ordinary bag plug won't do) and it's an outlet for devices, not for work areas, which still terminate in a jack and face plate.

Two buying details that prevent grief. First, passthrough plugs: the wire runs through the whole plug and the crimper trims it flush as it closes. They make it easier to verify the color order and keep the untwist short; well crimped, the electrical result is the same. Second, the plug also has a category and a gauge: a plug sized for 24 AWG grips a 23 AWG conductor badly, and a Cat5e plug on a Cat6A patch is the same bottleneck as a wrong jack. You buy the plug by reading the cable's datasheet, not the price of the bag.

Patch panels: four ways to order the rack

The patch panel is where the 24, 48 or 96 cables coming down from the building turn into orderly ports. A typical 1U panel carries 24 ports (48 in high-density versions), and the type defines how much flexibility you keep at ten years:

For an office, the real debate is fixed punch-down versus modular keystone. Fixed wins on price and there's nothing wrong with it if the building is stable. But modular pays back its premium the first day something changes: a broken port gets fixed by swapping one jack, and fiber or a shielded jack lands in the same panel without drama. Angled panels are a density trick: the V points every cord toward the vertical manager at the side and, in racks stacked with panels, saves the horizontal managers in between.

Two design rules apply to every type. First: rear management bar, always. The weight of the bundle coming down the tray ties to the bar, not to eight punched wires: a punch-down under tension is a fault in incubation. Second: leave spare ports and label everything. A panel is sized for the building that's coming, not today's, and every port carries its identifier per TIA-606, identical at the panel, the plate and the drawing. To split work areas, spares and growth without doing the math by hand, lay out the rack with the patch panel planner.

Face plates and outlets: the last inch

At the other end of the link sits the face plate: the wall plate with keystone positions, from 1 to 6 ports, single or double gang. The angled or beveled version points the port downward, and that silly-looking detail solves two real problems: the patch cord exits without forcing its bend radius against the furniture, and dust doesn't collect inside the connector. Where there's no flush box in the wall —warehouses, furniture, labs— the outlet is solved with a surface mount box, from 1 up to 12 ports.

Since the plate is keystone, the same trick as the modular panel applies: in the same outlet you can mix RJ45 + fiber coupler + HDMI + F connector for the TV coax. And don't forget: the face-plate jack is part of the permanent link. The certifier measures jack to jack: a poor jack in the wall ruins the measurement just like a poor one at the panel. The "wall end" is not the cheap end.

Worked example: 40 work areas and 6 PoE cameras

New office: 40 work areas cabled in Cat6A U/UTP and 6 PoE cameras in the hallways. Let's build the complete termination, with the why behind every decision:

1. Count the panel ports: 40 work areas + 6 cameras + 2 spares = 48. Exactly one high-density 48-port keystone panel in 1U. The spares save you when the printer or the access-control unit nobody mentioned shows up. Size the layout with the patch panel planner.
2. Choose the modular panel, not the fixed one: modular keystone because the building will change: a damaged port swaps out in a minute and fiber between floors lands in the same panel with an LC coupler. The per-port premium pays for itself the first time you don't have to throw away a whole panel.
3. Jacks matching the cable: the cable is Cat6A, so Cat6A jacks, because the channel certifies by the weakest component. And since it's U/UTP, unshielded jacks: the metal body is only justified when there's a braid to carry through to ground. Half a shield is an antenna, and a shield without shielded cable is wasted money.
4. Double face plates per work area: a 2-port beveled plate with one Cat6A jack installed (data) and the second position with a blank cap or a second jack depending on budget (voice or spare). The double costs pennies more and avoids opening the wall later. This jack gets certified too: same quality as the one at the panel.
5. Cameras via MPTL: the 6 cameras get the solid cable terminated directly into a field plug rated for solid conductors, no box or jack up high: TIA-568.2-D recognizes this outlet precisely for devices like cameras and APs. Use plugs specific to solid and matched to the cable's gauge (23 AWG): the ordinary plug up there is a guaranteed fault.
6. One color scheme only: the whole project in T568B —the commercial de facto standard—, punched the same at panel and plates, verified with the color code at hand. Mixing A and B between ends builds accidental crossover cables.
7. Management and certification: panel with a rear bar and the bundle tied to it (check the tray fill along the way with the conduit fill calculator), every port labeled per TIA-606, and permanent link certification jack to jack against the limits of the TIA-568 channel. What isn't labeled gets lost; what isn't certified gets argued about.

Summary: each part and its termination

With this, termination stops being the project's blind spot. Split ports and spares with the patch panel planner, punch with the color code in sight, validate distances against the TIA-568 channel, and make sure the bundle reaching the rack doesn't burst the conduit fill. The cable carries the bits; the ends decide whether they arrive.

Every integrator has lived this one: you install 24 cameras on a Tuesday, test everything in daylight, the picture is gorgeous, the client signs off. At 9:47 PM the security guard calls — half the cameras dropped "on their own." It's not a ghost. It's the infrared LEDs waking up with the dark: consumption climbed a few watts per camera, and the switch, already running on fumes, started shutting down ports like a captain throwing cargo overboard. PoE is genuinely modern magic, but it runs a ruthless little budget office: when the watts run out, somebody goes hungry. This guide makes sure that somebody is never your project.

48 volts down the same cable: the trick explained

Power over Ethernet injects DC — nominally 48 V, anywhere from 44 to 57 V depending on the type — over the very same twisted pairs that carry your data. Don't they fight? No: data travels as the difference in voltage between the two wires of each pair, while power rides as the common level of both wires, coupled through the transformers at each end. It's like whistling while you walk: two things at once, zero interference.

The two players have proper names: the PSE (power sourcing equipment — the switch or injector, the one writing checks) and the PD (powered device — the camera, AP or phone, the one cashing them). And here's the first number worth tattooing somewhere: the PSE always sends more than the PD receives, because the cable charges a toll along the way:

• 802.3af (PoE, Type 1): the PSE outputs 15.4 W; the PD is guaranteed 12.95 W.
• 802.3at (PoE+, Type 2): 30 W out of the PSE, 25.5 W at the PD.
• 802.3bt (PoE++): Type 3 at 60 W / 51 W, and Type 4 at 90 W / 71.3 W.

That gap isn't marketing rounding — it's straight physics. Cable loss is I²·R, and the standard's numbers check out to the watt. In 802.3af, up to 350 mA flows through a worst-case 20 Ω loop: 0.35² × 20 = exactly 2.45 W, which is precisely 15.4 − 12.95. In 802.3at it's 600 mA over 12.5 Ω: 0.6² × 12.5 = 4.5 W — that is, 30 − 25.5. And in Type 4, with nearly 1.73 A in play, 18.7 W go missing: one watt out of every five stays behind heating the cable. Which is why — spoiler for the voltage-drop section — 802.3bt spreads the current across all four pairs.

Classes 0–8: the switch reserves the worst case

When you plug in a PD, a silent negotiation happens in milliseconds. First the PSE probes for a 25 kΩ resistance signature ("there's a real PoE device here, not a wet laptop"). Then the PD declares its class — a number from 0 to 8 that says how much power it could possibly need. And here lies the detail behind half the field drama out there: the switch reserves the class maximum, not what the device actually draws.

It's like booking a restaurant table for 8 "just in case": even if only 3 people show up, the whole table stays blocked all evening. A Class 4 camera that sips 8 W in practice still locks 30 W out of the switch budget, because the switch has no way to predict when the IR LEDs, the housing heater, or the PTZ motor will kick in.

The 720-watt trap: your switch's power budget

Now let's assemble the pieces with the industry's most classic gotcha. You bought a "24-port PoE+" switch for your 24 Class 4 cameras. Sounds perfect: 24 ports, 24 cameras. But down in the datasheet's fine print it says PoE budget: 370 W. Let's do the arithmetic the salesperson skipped:

1. Each Class 4 camera forces the switch to reserve 30 W, even if it idles at 8 W. Reservation goes by class, not by consumption.
2. Total demand: 24 × 30 = 720 W requested from the budget.
3. Available budget: 370 W. Shortfall: 720 − 370 = 350 W. The switch covers barely 51% of what's being asked.
4. Ports it can actually power at once: 370 ÷ 30 = 12.3, so 12 ports (12 × 30 = 360 W, with 10 W to spare). Port 13 would push the total to 390 W, and there's nowhere to get it.
5. Net result: 12 cameras running and 12 begging for watts. The datasheet didn't lie — "24 PoE+ ports" means any port can deliver PoE+, not that all of them can at the same time.
6. To feed all 24 Class 4 cameras with 20% headroom you need 720 × 1.2 = 864 W of budget — or two switches, or cameras that negotiate less over LLDP.

Before buying the switch (or promising ports), run your device list through the PoE budget calculator: it totals by class, applies headroom, and tells you on the spot whether the budget holds.

Distance charges too: voltage drop

The second silent toll collector is cable length. Copper has resistance, and Ohm's law doesn't haggle: push 600 mA through a worst-case channel (12.5 Ω loop over 100 m) and 0.6 × 12.5 = 7.5 V vanish along the way. A Type 2 PSE outputs at least 50 V, so the device receives 42.5 V — which is exactly the minimum a Type 2 PD accepts. The standard is engineered to the millimeter: at 100 m with everything against you, you survive on fumes. At 110 m "because it was just a bit further," you don't.

Decent cable buys you slack: real 23 AWG Cat6 runs about 6.68 Ω of loop per 100 m over two pairs, so at full 802.3at load you lose around 4 V and 2.4 W — better than worst case, but still energy you paid for that ends up as heat inside the raceway. And this is where 802.3bt's play makes sense: spreading the same current across all four pairs halves the effective resistance, and the loss with it — those 2.4 W drop to 1.2 W. With 90 W on the line that's not elegance, it's thermal survival.

Two practical takeaways: first, respect the structured channel's 100 m (the TIA-568 channel guide builds the run for you, patch cords included) and sanity-check any doubtful stretch with the voltage drop calculator. Second, if you pack many PoE cables into one tray, all that I²R heat adds up: large bundles call for thermal derating — the same concept the conductor ampacity calculator applies on the electrical side.

Field habits that keep your phone quiet at night

Don't mix sketchy injectors. The 24 V "passive PoE" bundled with some radios negotiates nothing: it shoves voltage down the line without asking whether the far end can take it. Plugging an 802.3af device into a passive injector (or vice versa) is a lottery with a switch port as the stake. Simple rule: 802.3 with 802.3, passive with passive, and never a no-name injector "because it was the one in the van."

Measure real draw, but budget by class. Your 24 cameras may well sip 8 W each at idle — 192 W of real consumption, comfortably inside 370 W. But the switch reserves by class (720 W), and real draw climbs at night when the IR kicks in. The switch CLI shows you both columns:

switch# show power inline
Available: 370.0 W    Allocated: 360.0 W    Free: 10.0 W

Port       State    Class   Alloc(W)   Actual(W)
Gi1/0/1    on       4       30.0       7.9
Gi1/0/2    on       4       30.0       8.4
⋮
Gi1/0/12   on       4       30.0       8.1
Gi1/0/13   off      n/a     0.0        0.0   ← no budget left

Keep 20% headroom. Whatever baseline you budget on (class or negotiated draw), add 20%: it covers the IR LEDs, the housing heater, power-supply aging, and the extra camera the client "just remembered" mid-project. With 192 W of measured draw, budget 230.4 W as your floor — and if you reserve by class, the 864 W from the example. Also configure per-port priority: if watts ever run short, let the switch drop the parking-lot camera, not the boardroom AP.

What to do now

List your PDs with their class and measured draw, run them through the PoE budget calculator, and validate any long or doubtful run with the voltage drop calculator. If the numbers come out tight, upsize the switch or downsize the class — but let arithmetic make that call, not the dark at 9:47 PM.

In February 2025 a grid failure knocked out power to nearly all of Chile, and in a single afternoon everyone found out who had actually sized their backup. Some racks rode it out like nothing happened. Other UPSs — the ones that "lasted an hour" according to the salesperson — died at minute 12, with the client staring at their watch. The difference wasn't luck. It was understanding three or four numbers the datasheet only mumbles. Let's say them out loud.

Watts vs volt-amperes: the pint and the foam

First trap in the UPS aisle: they're sold in VA, but your load lives in watts. They are not the same thing, and mixing them up is the fastest way to buy small.

Picture a pint of beer. The full glass is the volt-amperes (VA): apparent power, everything the circuit has to push around. The beer you actually drink is the watts (W): real power, the part doing useful work. The foam is reactive power — it takes up room in the glass and in your cables, but it quenches nobody's thirst. The power factor (PF) is how good your bartender is: PF = W / VA.

Modern IT gear, with power-factor-corrected supplies, runs at PF 0.9 or better, and most current UPSs are rated with an output PF of 0.9. The rule worth tattooing on your forearm:

1000 VA × 0.9 ≈ 900 usable watts. A "1 kVA" UPS does not feed 1000 W of servers; it feeds 900, and that's if the manufacturer was feeling generous. It works in reverse too: a 500 W load asks the circuit for 500 / 0.9 ≈ 556 VA. If you juggle kW, kVA and amps all day, the three-phase power calculator does the gymnastics for you, single- or three-phase.

Runtime is not linear: the Peukert effect

Second trap, and this one is sneakier: a battery at half load doesn't last twice as long — it lasts more than twice as long. And at full load it lasts less than simple arithmetic promises.

Blame the chemistry. When you pull heavy current from a lead-acid battery, part of the energy burns off in internal resistance and the reaction can't reach all the active material in time: you extract less total energy. It's like running. At a jog you can cover 40 km; at a full sprint you won't finish 10. You don't just tire "proportionally faster" — you blow up.

This is the Peukert effect. For a typical VRLA battery (exponent ≈ 1.2), cutting the load in half multiplies runtime by 2^1.2 ≈ 2.3, not by 2. In numbers: a UPS that gives 10 minutes at full load delivers about 23 minutes at 50% and roughly 53 minutes at 25%. That's why serious manufacturers don't publish "the runtime" — they publish runtime-vs-load curves, and it's why the UPS runtime calculator asks for your actual load, not just the model number.

The three layers of backup

Nobody sizes a single box "for the whole outage". Backup power is designed in layers, each with its own timescale and its own purchasing logic:

The UPS exists for the seconds and minutes: it absorbs the flicker, conditions the power, and buys time for everything else. The DC battery bank (the telecom-heritage 48 V) buys hours. The generator buys days — provided somebody remembered the diesel. As a table:

Worked example: 500 W that can't even blink

A textbook field case: a comms rack with 500 W of measured load — switch, router, radios, a small NVR. The client wants 4 hours of runtime because that's how long outages last in their rural area. Layer by layer:

1. Measure the real load: 500 W. With a clamp meter or the PDU readout — not by adding up nameplates. Nameplates declare worst case and typically inflate reality 2–3×.
2. UPS: convert to VA. 500 W / 0.9 PF ≈ 556 VA. A 1 kVA UPS sits at ~56% load: the comfort zone. The manufacturer's curve at that load gives on the order of 10–15 minutes — enough for the next layer to take over, not enough to survive the afternoon.
3. Battery bank: define the energy. 4 h target × 500 W = 2000 Wh.
4. Convert Wh to Ah with the three factors. Ah = 2000 / (48 V × 0.5 DoD × 0.9 efficiency) = 2000 / 21.6 = 92.6 Ah. The 48 V is the bank voltage; the 0.5 is the depth of discharge that respects lead-acid lifespan; the 0.9 is the inverter's cut.
5. Round up to a commercial battery: 100 Ah. To build 48 V out of 12 V units: 4 × 12 V / 100 Ah batteries in series (series adds voltage, keeps the Ah).
6. Check it backwards. 48 V × 100 Ah = 4800 Wh gross; × 0.5 × 0.9 = 2160 Wh usable; / 500 W = 4.3 h. Target met, with a whisker of margin.

Generator: margin, motors and altitude

When the outage is measured in days, the genset comes in — and here the traps are mechanical as well as electrical.

The running margin

Base rule: running kVA × 1.25. A 40 kW load at PF 0.8 is 40 / 0.8 = 50 kVA running, so the recommended generator is 50 × 1.25 = 62.5 kVA (or the next commercial size up). That 25% isn't padding: it covers voltage regulation, the harmonics from switched-mode supplies, and the growth that "wasn't in scope" but always shows up.

Motors start like brutes

An induction motor with direct-on-line (DOL) starting pulls around 6× its rated current during startup. A 5 kW pump that runs at 6.25 kVA can demand ~37.5 kVA for a second — more than half of our 62.5 kVA generator, just to get spinning. If the genset feeds air conditioning, pumps or compressors, size for the worst start (or specify soft starters / VFDs). The generator sizing calculator accounts for exactly this.

Altitude charges a toll

A naturally aspirated diesel loses power where the air thins out: the rule of thumb is ~3.5% per 300 m above 1000 m. At a site 2500 m up, that's 17.5% less: your "62.5 kVA" generator delivers ~51.6. To get a real 62.5 up there, you need ~76 kVA on the nameplate. In Chile this is no footnote — it's Calama, it's the altiplano, it's half the mining industry.

Breakers: the 80% rule

All this power flows through a circuit breaker, and breakers have their own golden rule: for a continuous load (more than 3 hours straight — in other words, a rack), the breaker should not run above 80% of its rated capacity. The thermal element heats up, and a hot breaker trips when it feels like it, not when it should.

Example: a 3000 VA load at 230 V is 3000 / 230 ≈ 13 A. Minimum breaker: 13 / 0.8 ≈ 16.3 A. On the IEC ladder (6, 10, 13, 16, 20, 25, 32…) the 16 A falls short by three tenths — the right pick is the 20 A. Three tenths of an ampere separate an installation that passes inspection from one that trips every Friday at 6 pm. The load and breaker calculator gives you the standard size directly, single- or three-phase.

PUE: cooling costs money too (the bonus round)

One last number, on the house: every watt that enters the rack leaves as heat, and removing that heat also burns energy. PUE (Power Usage Effectiveness) is total facility power divided by IT power. A PUE of 1.6 — common in small rooms without aisle containment — means that for every watt of compute you pay 0.6 extra in cooling and losses: 37.5% of your electricity bill computes nothing at all.

In money: 10 kW of IT at PUE 1.6 is 16 kW total → 140,160 kWh per year → at $0.15/kWh, about $21,000 a year. Dropping PUE from 1.6 to 1.4 saves more than most maintenance contracts cost. The energy cost and PUE calculator converts your case into currency and CO₂.

Now, off to the field: measure your rack's real load this week (clamp meter or PDU, not nameplates), run it through ups-autonomia and banco-baterias, and write down your batteries' purchase date in the same spreadsheet where you track everything else. Batteries age like contracts do: silently, until the day of the outage.

The building manager is positive: "the camera caught him clean". You open the recording and sure enough, there he is: a guy walking out the gate with a bike over his shoulder, in broad daylight. You zoom into the face and the face is a twelve-pixel smudge under a baseball cap. You can see him, but you can't recognize him — CCTV's most expensive sentence, because it's almost always spoken after the theft, when there's nothing left to zoom. The good news: whether a camera can identify someone is not luck, and it's not marketing. It's a division. And you can do it before you buy.

DORI: putting numbers on "looks sharp"

The EN 62676-4 standard put numbers on sharpness with the DORI criteria: four levels of visual task, each with a minimum pixel density on the target, measured in pixels per meter (px/m). It's not how many megapixels the camera has — it's how many pixels land on each meter of scene in the plane where your subject is standing.

Mind the gap between recognize and identify: recognize works for someone you already know ("that's the night guard from next door"); identify means singling out a stranger with enough quality to hand to the police. Between one and the other sits exactly a factor of two in pixels — and as you're about to see, doubling pixels gets expensive in distance.

From the camera to px/m: one division

The mother formula is this: px/m = horizontal resolution ÷ scene width. A 1080p camera has 1920 horizontal pixels. If its frame covers a plane 7.68 m wide, every meter gets 1920 ÷ 7.68 = 250 px/m: full identification across that entire plane. Point the same sensor at a 40 m parking lot and each meter gets 48 px/m: you'll detect shapes, and that's the end of the story.

So what sets the scene width? Distance and lens. A lens with horizontal field of view (FOV) θ opens, at distance d, a scene 2 · d · tan(θ/2) meters wide. Combine both: px/m = res ÷ (2 · d · tan(θ/2)). Solve it for a 90° FOV — tan 45° = 1, how considerate — on a 1080p camera: you identify out to 1920 ÷ 500 = 3.84 m. Less than four meters from the lens. Beyond that the whole hallway "looks fine": you recognize out to 7.7 m, observe to 15.2, detect to 38.4… but none of that will single out a stranger.

Double the resolution? A 4K camera (3840 px) with the same 90° FOV pushes the identification border from 3.84 to 7.68 m. Exactly double — no miracle — and it charges you double in bitrate and disk, as you'll see below. Before wrestling the trigonometry, the lens & FOV calculator runs this math with your camera's actual sensor and focal length, and draws all four zones on the plan.

Fixed lens, varifocal, and the wide-angle toll

The fixed lens (2.8 or 4 mm on most domes) is cheap and never drifts, but its framing is married at the factory: if the scene doesn't fit, the camera is wrong forever. The varifocal (typically 2.8–12 mm) lets you adjust the framing on site — and the motorized version, from your desk. It costs more, but when you can't measure the scene before quoting, it's insurance against a second site visit.

CCTV's central trade-off lives right here: a wide-angle lens spreads the same 1920 pixels over a huge scene. Lots of coverage, little density. There's an elegant way to see it: with 1080p, identification always happens where the scene is 7.68 m wide — the lens merely decides how far away that plane sits. With 2.8 mm (≈ 90°), it's 3.8 m from the camera. With a ≈ 10 mm telephoto (30° FOV), it's 14.3 m: the same scene, almost four times farther out, in exchange for seeing one narrow corridor and nothing else.

Storage: bitrate × time, no magic

NVR storage holds no mystery: it's total bitrate × retention time, with a ÷ 8 along the way because bits travel eight to a byte. Let's run the canonical project — 8 cameras at 1080p, H.264 at 4 Mbps, 30-day retention — with every decimal in plain sight:

1. Aggregate bitrate: 8 cameras × 4 Mbps = 32 Mbps arriving at the NVR, day and night.
2. Bits to bytes: 32 ÷ 8 = 4 MB/s of sustained disk writes.
3. A day has 86,400 seconds: 4 × 86,400 = 345,600 MB = 345.6 GB/day (43.2 GB per camera).
4. 30 days of retention: 345.6 × 30 = 10,368 GB ≈ 10.37 TB — in decimal units, the same ones disks are sold in, so the comparison is apples to apples.
5. With H.265? The same period drops to ≈ 5.18 TB: the codec delivers similar quality at roughly half the bitrate. Turn on VBR with motion-based recording and the real average falls further still — a parking lot at 4 AM produces far fewer bits than a supermarket checkout at noon.

Better yet, the arithmetic audits itself in production: one day of one camera at 4 Mbps weighs exactly what the formula says it should.

$ du -sh /nvr/gate-cam/2026-07-09/
43.2G   /nvr/gate-cam/2026-07-09/
# 4 Mbps × 86,400 s ÷ 8 = 43.2 GB — the formula doesn't miss

Add 10–20 % of headroom on top: VBR bitrates spike, disks shouldn't run at 100 % full, and the day of the incident always has more motion than the average day. The CCTV storage calculator runs this cascade with resolution, FPS, codec and activity factor; and if your project mixes profiles — four domes, two telephotos, one PTZ — the CCTV project calculator adds up the whole mix at once.

The VMS server: the part nobody sizes

Everyone quotes cameras; almost nobody sizes the machine that records them. A VMS server has three bottlenecks, and none of them is the CPU.

The first is recording bandwidth: how many sustained Mbps the software can write without dropping frames. A typical mid-range server is specced around 300 Mbps — at 4 Mbps per camera that's 75 cameras; our 32 Mbps project has room to spare, but a casino with 120 4K cameras already needs more than one server. The second is RAM: recording is light, what's heavy is analytics and transcoding streams for the video wall; vendors usually ask for 8 GB as a floor and 16 or more with analytics running. The third — the one everybody forgets — is the disks.

CCTV writing is continuous, sequential and eternal: 24/7, 365 days a year. Our "small" example writes 126 TB per year — 63 TB per disk on a mirrored pair. A typical desktop drive is rated for about 55 TB/year of workload and office hours; you'd be running it above its rating from day one. Surveillance drives ("purple", SkyHawk and friends) are rated for 180 TB/year, 24/7 duty and firmware built for streams: they fail less and fail later. The VMS server calculator crosses cameras, bitrate, retention and per-server limits to tell you how many machines and which disks you need.

PoE: your cameras eat lunch too

Every IP camera eats watts through the same data cable, and the switch has a finite budget. A fixed dome draws 4–7 W: 802.3af covers it easily (up to 12.95 W delivered to the device). But long-range IR, PTZ motors or the heater on an outdoor housing change the league: PoE+ (802.3at, 25.5 W) or even 802.3bt for the hungriest. Our 8 cameras at ~6 W add up to 48 W — and an 8-port PoE switch with a 60 W budget is left with 12 W free: the PTZ somebody will request next year no longer fits. Run the sum through the PoE budget calculator before quoting the switch, and if classes, watts and voltage drop still ambush you, the PoE Without Surprises guide takes it all apart.

The recipe fits on a napkin: define the DORI level for each spot, pick the lens with the calculator, multiply bitrate by time before quoting disks, and check that the server and the switch can carry the load. Run the full project through the CCTV project calculator and walk into the meeting with numbers — let "you can see him, but you can't recognize him" be the other guy's install.

One January — high summer in Chile — we got called about "servers shutting themselves off in the afternoon". The "datacenter" was a three-by-three-meter storage room with one rack, a wall-mounted split AC, and a management directive: turn the AC off at closing time, to save money. Every summer afternoon the room climbed from 22 to nearly 40 °C, the servers protected themselves by shutting down, and next morning everything "worked again". Nothing was wrong with the hardware. There was just a misunderstanding with physics.

Your room is already a datacenter

A datacenter is not a building with guards and biometric doors: it's any room where the business keeps its iron. The NVR closet, the rack in the corner, the office that hosts the billing server "just for now". And here's the uncomfortable part: that room obeys exactly the same laws as a Tier IV facility. Electricity turns into heat, heat has to be carried out by air, disks fail on a schedule of their own, and availability is bought with money. The difference between Google and your back room isn't the physics — it's how much budget each law received.

This guide walks through the four calculations that decide whether your room is a small datacenter or a slow oven: space (the rack), heat (BTU), air (flow rate) and promises (the nines). All with verifiable numbers, because in this trade "more or less" gets paid for at 3 a.m.

The rack: 42U of order and physics

The rack unit exists so everything fits: 1U = 1.75 inches = 44.45 mm, a standard that has survived since the days of telephone switchboards. The typical cabinet is 42U: 42 × 44.45 = 1,866.9 mm — 1.87 m of usable space in a frame about two meters tall. In theory that's 42 servers of 1U each. In practice you fit far fewer, and almost never because of space: you run out of power or cooling long before you run out of U.

Weight is the other number everyone underestimates. A switch weighs about 5 kg, a 1U server 12 to 18, a rack-mount UPS with its batteries easily clears 60, and an external battery pack can double that. A moderately populated rack passes half a ton — which is why serious cabinets are rated for 1,000 to 1,500 kg static load, and why placement matters. The rule is load from the bottom: the heaviest gear (UPS, batteries) at the base, servers in the middle, switches and patch panels up top where the cabling arrives. It's not tidiness — it's center of gravity. When you slide a heavy server out on its rails, its entire weight hangs cantilevered in front of the rack; if that server lives near the top, the rack can tip over — with you holding it. Before buying the cabinet, balance U, kilograms and kilowatts in the rack capacity calculator.

Every watt comes in as electricity and leaves as heat

The first law of the datacenter is the first law of thermodynamics: practically every watt your equipment draws becomes heat inside the room. Not "a portion" — all of it. The data a server processes doesn't weigh anything or keep anyone warm; 100 % of that energy ends up in the air. A 10 kW rack is, thermally, five 2 kW space heaters running 24/7 in a closed room. Nobody would leave five heaters on behind a closed door over a long weekend; a medium-density rack is exactly that.

To talk to the HVAC vendor you need to translate units: IT kW × 3412 = BTU/h, which is the unit cooling gear is sold in, and kW ÷ 3.517 = tons of refrigeration (1 TR = 12,000 BTU/h). On top of the IT load, add what the spec sheets forget: a UPS dissipates 4 to 10 % of whatever passes through it, lighting contributes its share, and if the room has a wall facing the afternoon sun, that wall is a heater too. The heat load calculator adds up all the pieces.

Air: cold aisle, hot aisle

Removing heat isn't just "adding cold": it's traffic management. Servers breathe front to back — cold air in through the face, hot air out the rear. If that hot air loops around and enters the front of the neighboring rack (or its own), the equipment breathes pre-cooked air and runs a fever. The fix is decades old and still standard: face the racks toward each other to form a cold aisle where the air is supplied, and let their backs exhaust into a hot aisle that returns to the CRAC overhead. Cold and hot never mix: they wave at each other from a distance.

So how much air do you need to move? The formula is Q = P ÷ (ρ × cp × ΔT): the heat load divided by air density (≈ 1.2 kg/m³), its specific heat (≈ 1005 J/kg·°C) and the ΔT — how much the air warms up crossing the servers, typically 10 to 15 °C. You can play with kW and ΔT in the airflow and CRAC calculator, but let's size the whole 10 kW room by hand, start to finish:

1. Heat to remove: 10 kW × 3412 = 34,120 BTU/h. That's the number your HVAC vendor understands.
2. In tons of refrigeration: 10 ÷ 3.517 = 2.84 TR (same result the other way: 34,120 ÷ 12,000 = 2.84). A 3 TR unit is cutting it close; with N+1 redundancy, two 3 TR units.
3. Airflow at ΔT = 12 °C: Q = 10,000 ÷ (1.2 × 1005 × 12) = 0.69 m³/s.
4. In spec-sheet units: 0.69 m³/s × 2119 ≈ 1,464 CFM. For a mental picture: that's about 2,490 m³/h — 25 bathroom exhaust fans blowing at once, for a three-by-three-meter room.
5. ΔT rules everything: if air mixes and your real ΔT drops to 6 °C, you need double the airflow for the same heat. Aisle containment and plugging gaps isn't cosmetic: it's free airflow.

And how do you know your real ΔT? Your servers already measure it — no extra instruments:

$ ipmitool sdr type Temperature
Inlet Temp       | 04h | ok  |  7.1 | 24 degrees C
Exhaust Temp     | 01h | ok  |  7.1 | 36 degrees C
CPU1 Temp        | 0Eh | ok  |  3.1 | 58 degrees C

Inlet 24 °C, exhaust 36 °C: a ΔT of 12 °C, exactly the one we used. If the inlet reads 30 °C or higher, the problem isn't the CRAC — it's hot air recirculating to the front.

The nines: availability is bought with money

"It can never go down" is the most expensive sentence in the trade, priced per word. Availability is expressed in nines, and the scale is deceptive: between 99 % and 99.999 % there seems to be "almost nothing", but each extra nine divides annual downtime by ten — and multiplies the budget by something suspiciously similar.

How do you climb the steps? With N+1 redundancy: if the load needs N units, you install N+1 so any single failure goes unnoticed. And the golden rule for combining components: in series, availabilities multiply — everything must work, so two 99 % links chained together give 0.99 × 0.99 = 98.01 % (the chain is worse than its weakest link). In parallel, the system forgives: only one needs to work, and two 99 % units in parallel reach 99.99 %. Model the whole chain — utility power, UPS, cooling, server, switch — in the availability and SLA calculator, with the nines and downtime minutes for each configuration.

Disks: RAID is not backup (and writes cost extra)

The painful part first: RAID is not backup. RAID protects against a disk failing; it does nothing against accidental deletion, ransomware or fire — all of which replicate their disaster to the remaining disks enthusiastically and in real time. Backup is another copy, on other hardware, ideally somewhere else. That said, the right RAID level does decide how fast and how tough your storage is, and there's a number almost nobody checks: the write penalty.

Every logical write becomes several physical operations. RAID 10 writes the data and its mirror: 2 operations. RAID 5 must read the old data, read the parity, write the new data and write the new parity: 4. RAID 6, with double parity, needs 6. Run the numbers on a real array: 8 disks at 150 IOPS give 1,200 raw IOPS; with a typical 70 % read / 30 % write mix on RAID 5, you're left with 1,200 ÷ (0.7 + 0.3 × 4) = 632 functional IOPS. Parity ate almost half the array — before the first virtual machine even booted.

Usable capacity and fault tolerance for each level live in the RAID calculator; performance with your actual read/write mix, in the IOPS with RAID penalty calculator.

Growth: don't let 80 % catch you by surprise

Storage never fills up by registered mail: it fills up on a Friday at 6:30 pm. The defense is boring and effective — measure your real monthly growth rate (your business's rate, not the vendor brochure's) and project forward. Careful, though: growth tends to be compound. More customers mean more cameras, more mail and more backups, and the curve steepens on its own.

An example with numbers: you're using 6 TB out of 10, growing 4 % monthly compound. You hit 80 % (8 TB) in 7.3 months and a full disk in 13. Why does 80 % matter? Because above that threshold many filesystems and arrays start degrading performance, and because that's where your room to maneuver ends: migrating, snapshotting or rebuilding a RAID all need free space. Project the exact date with the storage growth calculator and schedule the purchase months ahead: a purchase order moves faster than a dead disk on a Sunday.

The small room and the big datacenter obey the same physics; the difference is who did the math first. Start today: measure your rack's real power draw, convert those kW into BTU and airflow, and write down what one hour of downtime costs you. With those three numbers, every decision in the room — cooling, UPS, RAID, capacity — stops being an act of faith and becomes arithmetic.

A customer lit up their brand-new dedicated 1 Gbps link to the datacenter where everything gets backed up. First night of glory: the backup crawls along at exactly 100 Mbps. They call the provider; the provider runs an iperf with eight parallel streams and clocks 940 Mbps. "The link is perfect." And it is. It's also true that the backup runs at a tenth of what they're paying for. Nobody is lying and nothing is broken: that's TCP doing its job. TCP ships cargo only when the signed delivery slip comes back, and between that office and that datacenter the slip takes 20 ms to make the round trip. This guide is the invoice for that slip.

The signed delivery slip: why TCP waits

TCP promises something borderline miraculous: complete, in-order delivery over a network that drops packets and shuffles them. Its method is old-school warehouse clerk: number every byte and demand a receipt (the ACK). And since it can't ship infinite cargo without knowing what arrived, there's a cap on how much data can travel unconfirmed: the window. Think of a strict courier: he dispatches up to N boxes and, until the signed slip comes back from the recipient, he will not dispatch one more.

If the destination warehouse is next door, the slip comes right back and the flow never stops. If it's 20 ms away round-trip, here's what happens: pushing a 64 KB window down a 1 Gbps link takes a mere 0.52 ms… and waiting for the ACK takes 20 ms. The sender works 2.6% of the time and stares at the ceiling the remaining 97.4%. The link isn't slow — it's idle.

That gives us the most important formula in this guide: max throughput = window ÷ RTT. Notice what does not appear in it: the link's bandwidth. You can buy 10 Gbps and the math won't budge a single bit. That's why the first move on any "it's slow" ticket is never re-reading the contract — it's measuring the RTT.

The three delays that make up your RTT

That 20 ms RTT isn't divine punishment: it's the sum of three delays with very different personalities.

1. Serialization: the time it takes to push the bits onto the wire, one after another. A 1500-byte packet at 1 Gbps is 12,000 bits ÷ 10⁹ bps = 12 µs. At 100 Mbps, 120 µs; at 10 Gbps, 1.2 µs. You pay it at every hop that receives the full packet before forwarding it (store-and-forward), so a path with eight hops charges it eight times.

2. Propagation: physics, folks. Light in fiber doesn't travel at vacuum speed but at about 204,000 km/s (glass slows it down, refractive index ≈ 1.47). Hence the golden rule: ≈ 5 µs per kilometer. 100 km of fiber = 0.5 ms one way = 1 ms of RTT with nobody doing anything wrong. 2,000 km = 20 ms of RTT. And 8,000 km to a faraway datacenter = 80 ms of RTT on propagation alone. No upgrade fixes this one: it's distance, not equipment.

3. Queuing and processing: the moody one. Full buffers on a congested router, deep inspection on the firewall, a cheap switch with its CPU pegged. It's the only one of the three you can fight with QoS and proper sizing — and the only one that produces jitter.

The uncomfortable consequence: upgrading from 1 to 10 Gbps only improves serialization, which drops from 12 µs to 1.2 µs. Inside a 20 ms RTT, that's a rounding error. You can add up all three delays along your path, hop by hop, with the latency budget calculator.

BDP: your link is a pipe (and the window is the lid)

Now let's assemble the pieces. A link behaves like a pipe: the width is the bandwidth (how many bits per second fit) and the length is the RTT (how long they take to cross and get confirmed). The volume of that pipe is called the bandwidth-delay product (BDP): how many bytes must be "in flight" — sent but not yet acknowledged — for the pipe to run full. If your window is smaller than the BDP, the pipe travels with air in it.

Let's run the full numbers, exactly:

1. You want to sustain 100 Mbps over a path with a 20 ms RTT. BDP = 100,000,000 bits/s × 0.020 s = 2,000,000 bits.
2. 2,000,000 ÷ 8 = 250,000 bytes = 250 KB. That's how much must be traveling unacknowledged, at all times, so the pipe never runs dry.
3. TCP's original window field is 16 bits: at most 64 KB (65,536 bytes). Throughput ceiling = 65,536 × 8 ÷ 0.020 s = 26,214,400 bps ≈ 26.2 Mbps.
4. And here's the brutal part: it makes zero difference that the link is 1 Gbps. With a 64 KB window and 20 ms of RTT, the ceiling is still 26.2 Mbps. To fill 1 Gbps × 20 ms you need 2.5 MB in flight — 38 classic windows.
5. The rescue is called window scaling (RFC 7323): an option negotiated in the handshake that multiplies the window by up to 2¹⁴, allowing windows of ~1 GB. Every operating system from this century ships it enabled — but one prehistoric middlebox stripping the option from the SYN sends you straight back to 1994.

How much window and how much RTT do you need to hit your target? That's exactly what the TCP throughput calculator computes: give it RTT, window and loss, and it returns the real ceiling of a single flow.

MTU and MSS: how much fits in each box

So far we've talked about how many boxes fly at once. Now, the size of each box. On Ethernet the maximum payload of a frame — the MTU — is 1500 bytes. Of those, the IP header takes 20 and the TCP header another 20: you're left with 1460 bytes of actual payload, the famous MSS (maximum segment size). So far, clean.

The problem is that every tunnel along the path charges a toll in bytes. PPPoE — the staple of residential GPON connections — inserts 8 bytes of session header and leaves the MTU at 1492. GRE takes 24. VXLAN, the datacenter standard, takes 50. And since the physical limit of the path is still 1500, everything the headers add gets deducted from your letter.

And what if a packet leaves bigger than the path can carry? Two scenarios, both ugly. With fragmentation, the router chops the packet into pieces: lose one fragment and TCP retransmits the whole packet, while reassembly burns CPU at the destination. Fragmentation isn't a workaround — it's slow poison. And with the DF bit set (the default in modern TCP), the router drops the packet and reports back via ICMP so the sender can try a smaller one — the mechanism known as Path MTU Discovery.

Finding the real MTU of a path takes thirty seconds with ping and the DF bit:

$ ping -M do -s 1472 vps.example.com
From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)

$ ping -M do -s 1464 vps.example.com
1472 bytes from vps.example.com: icmp_seq=1 ttl=55 time=19.8 ms

1464 of payload + 8 of ICMP + 20 of IP = 1492: there's PPPoE on the path. The full header math, for any stack of tunnels, is what the MTU and MSS calculator does.

Firewalls don't die of Gbps: they die of pps

Last piece of the puzzle, and the most expensive one to ignore. A network device doesn't process "megabits": it processes packets. Every packet — tiny or full-size — demands the same choreography: route lookup, session, policies, NAT. That's why the metric that kills firewalls is pps (packets per second), not Gbps.

The numbers speak for themselves. At 1 Gbps with minimum 64-byte frames (each occupies 84 B on the wire, counting preamble and interframe gap), the device faces 1.49 Mpps. With full 1518-byte frames, a mere 81,274 pps: 18 times less work for the same "bandwidth". The datasheet that says "1 Gbps firewall" almost always measured with big packets; your real traffic — VoIP, DNS, gaming, TCP ACKs — is full of small ones.

To size honestly there's IMIX, a statistical blend of real traffic: 7 frames of 64 B + 4 of 570 + 1 of 1518, average 353.83 bytes. At 1 Gbps that's about 334,000 pps — four times more demanding than the full-frame scenario. You can dissect per-frame overhead in the Ethernet frame and PPS calculator and size your edge device with the firewall sizing calculator.

Recipes: latency first, parallelism second

With all the physics on the table, the field recipes come down to three.

For interactive apps, low RTT beats high bandwidth. Opening an HTTPS session costs about 4 round trips before the first useful byte: at 10 ms of RTT that's 40 ms and feels instant; at 150 ms it's 600 ms and the user is already complaining. Remote desktop, ERPs, video calls: they all live off the RTT. Picking the closest datacenter is worth more than doubling the link.

When the RTT is unavoidable, parallelize. The window ÷ RTT limit is per flow: four parallel TCP connections, each with its own 64 KB window, move 104.9 Mbps where a single one moves 26.2. That's why the provider's iperf with -P 8 clocked 940 Mbps while the single-stream backup dragged its feet — and why serious transfer tools (parallel rsync, multithreaded robocopy, browsers with their 6 connections) open several flows.

And size with all three units. A link is bought in Gbps, saturated in pps, and exploited according to window ÷ RTT. Before signing off on an upgrade, run the transfer through the transfer time calculator and confirm which of the three is actually holding you back.

Next time a link "runs slow", don't start with the contract: measure the RTT, compute the BDP and check the path's MSS. In that order. Nine times out of ten, the gigabit was intact all along — what was missing was window.

The ticket came in on a Monday: "phone calls break up whenever someone uploads backups". The link graph showed a serene 40% average utilization, and the manager asked — quite reasonably — what the 100 Mbps he paid for was doing. Here's the catch: averages are measured in minutes, congestion happens in milliseconds. One 30 ms burst that fills the egress queue is enough to make a voice packet miss its appointment. That's where QoS comes in, and let's get one thing straight up front: QoS doesn't add a single bit to your link. It's triage.

QoS doesn't manufacture bandwidth

Think of a hospital emergency room. Triage doesn't build operating rooms or hire doctors: it decides who goes first when there isn't enough for everyone. QoS is exactly that for a network interface: when more packets arrive than the wire can carry, somebody has to wait in the queue — or get dropped — and QoS picks who takes the hit. Nothing more, and nothing less.

Two uncomfortable truths follow. One: without congestion, QoS does nothing. With an empty queue, the packet marked as gold and the packet marked as coal leave equally fast; your elegant policy is pure decoration. Two: if the link is congested around the clock, QoS is anesthesia, not a cure — voice will sound pristine while everything else starves, and the real fix is more bandwidth. QoS earns its keep in the middle ground: links that have plenty on average but suffer microbursts. Which is exactly where 90% of real networks live.

DSCP: the sticker on the packet's forehead

To discriminate with any sense, you first have to label. The IPv4 header carries a byte that was born as "Type of Service" and is now the DiffServ field: its top 6 bits are the DSCP (Differentiated Services Code Point) and the remaining 2 are ECN, which is a different movie. Six bits give you 64 possible values, but in practice four of them pay the rent:

EF (Expedited Forwarding) is for traffic that would rather die than arrive late: voice. AF41 gives interactive video a bandwidth guarantee without the voice-grade VIP pass. CS0 is the ordinary citizen. And CS1 — the scavenger class — is the most underrated item in the catalog: mark your backups and OS updates with it and they can hog the entire link at 3 AM, yet yield every last bit the moment somebody else needs it. Sometimes the best QoS isn't promoting voice: it's demoting the backup.

To see the marking live, a tcpdump is all you need: the ToS byte shows up on every packet.

$ sudo tcpdump -n -v -c1 udp portrange 16384-32767
IP (tos 0xb8, ttl 63, id 4211, offset 0, proto UDP (17), length 200)
    10.1.20.14.16402 > 10.1.9.7.16388: UDP, length 172

That tos 0xb8 is EF wearing a different haircut: 46 shifted two bits left (46 × 4 = 184 = 0xB8). All the conversions between DSCP, ToS, binary and class names — with the 21 standard classes — live in the DSCP / QoS calculator.

The boundary: trust or remark

Anyone can slap on a sticker. If your policy says "EF goes first", nothing stops a PC with a "gaming-optimized" network driver from marking its packets EF and cutting in line ahead of your phones. That's why every serious network defines a trust boundary: at the access port you decide whether to believe incoming marks or rewrite them. Corporate IP phone? Trusted. User laptop? Thanks for playing: everything to CS0, and if it carries known voice or video traffic, you re-mark it yourself with an ACL. From the edge inward nobody classifies again: the mark is trusted, period — deep inspection in the core is expensive; misplaced trust is far more so.

And here's the part people forget: the mark alone is decoration. The dirty work is done by queues. A proper switch or router sorts each packet by DSCP into a different queue: EF into the priority queue (served ahead of everything, with a policer on top so voice can never eat the whole link), AF41 into a queue with guaranteed bandwidth, CS0 into the common pool, CS1 gets the crumbs. The mark is the diagnosis; the queue is the treatment.

The bucket of tokens: how "how much may pass" gets measured

Marking and queuing sort the line; you still need the doorman who measures the flow. Nearly every platform uses the same mechanism: the token bucket. It works like an arcade: transmitting 1 bit costs 1 token. Tokens drip into the bucket at a constant rate — the CIR, your committed rate — and the bucket has a maximum size, Bc. When the bucket is full, new tokens spill over and are lost: there is no infinite savings account. Packet arrives and tokens are there? It sails through. No tokens? That's where the doorman's personality comes in — more on that in a moment.

With round, verified numbers: CIR of 1 Mbps and Bc of 8,000 bits. The refill interval is Tc = Bc ÷ CIR = 8,000 ÷ 1,000,000 = 8 ms, which means 125 refills per second of 8,000 bits each — multiply them and you get exactly the CIR back. And since the bucket never holds more than Bc, the maximum instantaneous burst is Bc: 8,000 bits, about 1,000 bytes in one go.

The bucket is what makes real life bearable: traffic is never flat, and Bc defines how much burst you forgive without breaking the average. Now — what happens when traffic arrives and the tokens are gone? Two philosophies:

• Policing — the scissors. Excess is dropped or re-marked to a worse class, on the spot. No queue, no added delay, no memory. Brutal but cheap.
• Shaping — the funnel. Excess is queued and waits for tokens. Nothing is lost (while the queue holds), but the price is delay: the burst comes out ironed flat at the CIR.

Same burst, different fates: 20,000 bits arrive at once with a full bucket. The policer lets 8,000 through (the tokens on hand) and cuts 12,000. The shaper passes the same 8,000 immediately and queues the other 12,000, which drain over the next 12 ms (12,000 ÷ 1,000,000). Everything arrives — just later.

When to use which? Police what you receive: at the inbound edge, so no customer or branch exceeds its contract. Shape what you send toward a slower link or a contracted CIR: better to let your own queue decide what waits — with your priorities — than to let the far-side policer chop blindly. TCP, on top of that, handles delay far better than loss: every policer drop means a retransmission and a window collapse. You can play with the parameters — CIR, Bc, Tc, and whether your burst fits — in the token bucket calculator.

Jitter buffer: buying order with latency

Even with perfect marking and shaping, the network never delivers on a clock. Voice needs one: a codec with a 20 ms ptime emits one packet every 20 ms sharp — 50 per second — and the listener needs them played back on exactly that beat. The variation between arrivals is jitter, and the remedy is the jitter buffer: a waiting room that holds freshly arrived packets a moment and hands them to the codec on a metronome. The trick is that this order is bought with latency — every millisecond of buffer is one more millisecond of delay in the conversation. The practical sizing rule: 2 × the measured jitter. Let's run the full budget:

1. You measure the actual jitter toward the PBX: 20 ms. The call uses a ptime of 20 ms (one voice packet every 20 ms).
2. Buffer = 2 × jitter = 2 × 20 = 40 ms. In depth: 40 ÷ 20 = 2 packets sitting in the waiting room.
3. Mouth-to-ear budget: network 50 ms + buffer 40 ms + codec 15 ms + packetization (ptime) 20 ms = 125 ms.
4. ITU-T G.114 puts the comfort limit at 150 ms one-way: 125 ≤ 150 → a fluid conversation, with 25 ms to spare.
5. Cross-check: if jitter climbs to 40 ms, the buffer grows to 80 ms and the total to 165 ms — over the limit, and the walkie-talkie effect kicks in, with both parties talking over each other. Jitter charges you twice: it scrambles arrivals and inflates the buffer.

That's the deep reason to mark voice EF and give it a priority queue: it's not about the megabits (a call weighs almost nothing), it's about keeping jitter down so the buffer can stay small. Size the buffer and the mouth-to-ear budget with the jitter buffer calculator, and get the real per-call bandwidth — headers and all — from the VoIP calculator.

Video: reserve by percentile, not by average

Video is the elephant in the QoS room: a single camera can outweigh your entire phone system. Its bitrate depends on resolution, frame rate, codec and quality (bits per pixel), and the big lever is the codec: at comparable quality, H.265 asks for roughly half of what H.264 does. A 1080p30 stream at 0.1 bpp works out to 1920 × 1080 × 30 × 0.1 ≈ 6.2 Mbps in H.264 and ≈ 3.1 Mbps in H.265. Estimate yours — with your resolutions and quality targets — in the video bitrate calculator.

The detail that breaks networks: that figure is an average, and modern video is variable-rate. Static scene, barely anything; someone walks past the camera or an I-frame lands, and the bitrate jumps to 2 or 3 times the average for a few hundred milliseconds. If you sized the AF41 queue from the average, every spike arrives precisely when the guarantee runs out — and the video pixelates exactly at the interesting moment. Reserve by percentile (the p95 of the measured bitrate, not the datasheet), and let shaping absorb whatever pokes above it.

The short recipe

Serious QoS is four moves: confirm the congestion is real (in milliseconds, not 5-minute averages), mark at the edge and remark whatever you don't control, give each class a queue with a real guarantee, and smooth your egress before someone else's policer chops it. Start today: check with tcpdump whether your voice leaves the building marked EF — it takes a minute, and the answer is usually half the diagnosis.

The complaint always arrives in the same words: "it sounds like a robot". The manager was closing a deal over the phone and the voice on the other end dissolved into metallic gibberish. The first thing support checked was bandwidth — and there were gigabits to spare. That's the trap with voice over IP: it's almost never a weight problem. A phone call is one of the lightest flows crossing your network, and by far the most impatient. It doesn't ask for room. It asks for punctuality.

Punctuality, not weight

Let's put numbers on "light". A G.711 call — the classic, uncompressed codec — consumes 87.2 kbps per direction with all its Ethernet overhead included. A single 5 Mbps HD video stream equals 57 simultaneous calls. On any modern link, the sheer volume of voice is a rounding error.

What voice demands is something else. Think sushi delivery: nobody cares that the order is small — it has to arrive fresh, and the rolls have to arrive in order. Recommendation ITU-T G.114 sets the budget: 150 ms maximum mouth-to-ear, one way. Up to that point conversation flows; beyond it, both sides start talking over each other and the call turns into a walkie-talkie session. Add two more limits: jitter under 30 ms (the variation between packet arrivals) and loss under 1%.

Why so strict? Because voice rides RTP over UDP, with no retransmissions. And that's the right call: a word that arrives late is useless — playing it two seconds later would be an absurd echo, so the late packet simply gets dropped. TCP, with its "say that again?", is perfect for files and hopeless for conversation. The practical consequence: in VoIP, nothing rescues you from an unpunctual network. It arrives on time, or it doesn't arrive at all.

Packet anatomy: 160 bytes of voice, 58 of paperwork

Let's dissect a G.711 call. The codec samples audio 8,000 times a second at 8 bits per sample: 64 kbps of raw voice. The phone doesn't ship samples one by one: it collects 20 ms of audio — 160 bytes — and sends them off in one packet. That's 50 packets per second, in each direction of the call.

Those 160 bytes never travel alone: 12 bytes of RTP (sequence number and timestamp, for reordering and measuring jitter), 8 of UDP and 20 of IP. Layer-3 total: 200 bytes, which at 50 packets per second works out to 80 kbps. And on the LAN there's still the outer envelope: the Ethernet frame adds 18 more bytes (header plus FCS), leaving 218 bytes on the wire — that is, 87.2 kbps of real bandwidth per direction.

Look at the ratio: 26.6% of the packet is bureaucracy. And watch out for a field classic: calls are bidirectional, so on a symmetric link you reserve 87.2 kbps each way. You can play with codecs, packetization and layer-2 overhead in the VoIP bandwidth calculator.

Codecs: the call's vocal cords

The codec decides how much the voice weighs and how it sounds. Three names cover 95% of what you'll meet in the field:

• G.711 — the reliable grandfather (1972 and still going). No compression: 64 kbps of bitrate and the exact sound of a landline. Its MOS of 4.1 is the yardstick everything else is measured against. It's a spender, but adds almost no delay or CPU.
• G.729 — the penny-pincher. It squeezes voice down to 8 kbps (8× less!) in exchange for a MOS of 3.9, some CPU, and 15 ms of algorithmic delay. It sounds slightly "compressed" but perfectly serviceable. It was born for expensive WAN links, and that's still where it earns its keep.
• Opus — the modern one. Royalty-free, variable bitrate and wideband: it captures up to twice the spectrum of the human voice, which is why its MOS of 4.3 beats the good old landline. It's the WebRTC codec, so you already use it in every browser call.

Notice the table's paradox: compressing 8× (G.729) only cuts real consumption to a third, not an eighth. Blame the 58 bytes of headers, which don't compress: the smaller the payload, the bigger the paperwork's share. The full comparison — with AMR-WB, G.722 and friends — lives in the voice codec calculator.

MOS and its three assassins

The MOS (Mean Opinion Score) is the grade a human ear gives the call, from 1 (unintelligible) to 5 (perfect). Above 4.0 nobody can tell it's VoIP; below 3.5 the complaints start and people hang up and redial. Codecs start out with their factory grade — the one on the thermometer — and the network can only drag it down from there.

So what pushes it down? Three assassins, in order of how quickly your ear notices them:

• Delay — the most annoying and the first one people notice. It doesn't degrade the sound: it degrades the conversation. Past 150 ms one-way, turns start colliding; at 300 ms you're on a walkie-talkie. And it accumulates silently: codec, packetization, queues, distance (fiber adds about 5 ms per 1,000 km) and the jitter buffer itself.
• Jitter — packets leave every 20 ms sharp but arrive like a drummer with jet lag: 18, 25, 19, 40… The jitter buffer re-aligns them, until the variation exceeds what the buffer tolerates and it starts discarding latecomers. Above 30 ms of jitter, it's already dropping.
• Loss — the most forgivable, thanks to PLC (packet loss concealment), which patches holes by interpolation. Up to 1% of scattered loss is barely audible; a burst of 3 back-to-back packets is 60 ms of vanished syllable, and that you hear.

The good news: all three are measurable from a capture. RTP packets carry their own sequence numbers and timestamps, so Wireshark or tshark compute jitter and loss for you:

$ tshark -q -z rtp,streams -r call.pcap
========================= RTP Streams =========================
Src 10.1.20.14:16384 → Dst 190.98.x.x:18210   SSRC 0x4C3A11F2
Payload: g711U   Pkts: 2890   Lost: 6 (0.2%)
Max jitter: 11.3 ms   Mean jitter: 4.1 ms     [OK]

How many trunks? Erlang without tears

So far we've talked about one call. The other question in every telephony project is how many simultaneous calls you must support — in other words, how many trunks to buy. The answer has had a surname since 1917: Erlang B, the formula Agner Erlang used to size Copenhagen's exchanges. The unit is the Erlang: 1 Erlang equals one line busy 100% of the time.

The tempting intuition is "5 Erlangs of traffic = 5 lines". Nope: calls arrive whenever they please, entirely uncoordinated. Sometimes 3 are up, sometimes 8. Erlang B computes the probability that a peak finds every trunk busy — the blocking — and you decide how much blocking the business tolerates. A full worked example:

1. Measure busy-hour traffic. Your PBX logs 100 calls per hour, averaging 3 minutes each: 100 × 3 = 300 minutes of conversation per hour. In Erlangs: 300 ÷ 60 = 5 Erlangs.
2. Set the service target. Blocking ≤ 1%: at most 1 in 100 busy-hour calls hits a busy tone.
3. Discard the intuition. With 5 trunks for 5 Erlangs, Erlang B says 28.5% blocking: more than one in four calls rejected. Randomness charges a steep fee.
4. Iterate upward. With 8 trunks, blocking drops to 7.0%; with 10 it reaches 1.84% — close, but still not compliant.
5. With 11 trunks: 0.83%. The first count that dips below 1%. Answer: 11 trunks — more than double the average traffic, and that margin is exactly what you're paying to absorb the peaks.
6. Translate it to bandwidth. If the trunk is SIP with G.711: 11 × 87.2 kbps = 959 kbps ≈ 1 Mbps symmetric reserved for voice. Check the whole exercise in the Erlang calculator — and while you're there, look at Erlang C, which answers the sibling question: how many agents a call center needs.

QoS: voice flies first class

You now know what a call needs (punctuality) and how many fit (Erlang). What's left is guaranteeing it when the link fills up — because it will, right in the middle of the important call. The standard recipe has three ingredients:

• Mark voice as EF (Expedited Forwarding, DSCP 46) as close to the phone as possible, and SIP signaling as CS3. The DSCP/QoS converter translates between all the notations when a box asks for the number in a different currency.
• Strict priority queue for EF on every interface that congests — typically the WAN router. Strict priority means voice leaves first, always; the policer that comes with it stops mismarked traffic dressed up as EF from starving everyone else. The fine detail — queues, shaping, token buckets — is in the QoS for Real guide.
• A well-sized jitter buffer at the receiving end. It's a trade, not a free knob: every millisecond of buffer absorbs jitter but adds to the mouth-to-ear delay — it spends your G.114 budget. Modern adaptive buffers float between 30 and 50 ms on their own; size yours and check the total delay with the jitter buffer calculator.

One border warning: your DSCP marking rules inside your network, but ISPs routinely wipe or rewrite it at their edge. Over Internet links, real priority is enforced by your egress router, queueing before the bottleneck — don't expect the cloud to honor your EF.

Operational summary: reserve 87.2 kbps per G.711 call (or 39 with Opus) each way, size trunks with Erlang B instead of guessing, mark EF and queue with priority before the bottleneck. Keep delay under 150 ms, jitter under 30 and loss under 1%, and the call sounds like a person instead of a robot — and the manager closes the deal without ever learning your name, which is the definition of success in telephony.

Boardroom, brand-new 4K display, equipment rack 20 meters away. The previous installer ran a bargain-bin HDMI cable with "4K" printed on the jacket, and the result is a genre classic: screen goes black for two seconds, picture comes back, white sparkles whenever someone moves the mouse. The vendor blames the TV, the client blames you, and the actual culprit is physics: a 4K60 signal weighs 14.26 Gbps, and passive copper HDMI starts giving up past 5 meters at that rate. The good news: the math that explains all of it fits on a napkin.

The math that saves installs

Over an HDMI or DisplayPort cable, video travels uncompressed: every pixel of every frame, all of its bits, sixty times a second. No codecs, no miracles — pure brute force, which is why the numbers get so big.

One detail throws people the first time: the signal carries more pixels than you see. Between lines and between frames travel "blank" pixels (the blanking interval), inherited from CRT tubes that needed time to swing the beam back to the start. A 1080p picture shows 1920×1080 but transmits 2200×1125; 4K shows 3840×2160 and transmits 4400×2250. Blanking isn't dead weight anymore — audio and metadata ride in it — so it counts. With that, the full formula:

1. Bandwidth = total pixels per frame × frames per second × bits per pixel. At 8 bits per color with no subsampling (4:4:4), each pixel weighs 24 bits.
2. 1080p60: 2200 × 1125 = 2,475,000 total pixels. × 60 frames = 148.5 million pixels per second (the famous 148.5 MHz pixel clock). × 24 bits = 3.564 Gbps. Any halfway-decent cable passes that — which is why "it worked at the house".
3. 4K60, 8-bit: 4400 × 2250 = 9,900,000 pixels. × 60 = a 594 MHz pixel clock. × 24 bits = 14.256 Gbps. HDMI 2.0 carries 14.4 Gbps of actual data: it fits with about 1% to spare. Barely.
4. 4K60, 10-bit, HDR: same pixel clock, but 30 bits per pixel: 594 MHz × 30 = 17.82 Gbps. That no longer fits in HDMI 2.0. You need HDMI 2.1, DisplayPort — or fewer color bits, which is the next chapter.
5. Takeaway: quadrupling pixels (1080p → 4K) quadruples the Gbps, and HDR stacks another 25% on top. Before quoting cables and extenders, run the format through the HDMI/DP bandwidth calculator and you'll know exactly which ceiling you're fighting.

Chroma subsampling: the discount your eye never sees

Your retina is lopsided by design: it resolves changes in brightness with surgical precision and changes in hue only roughly. Professional video has exploited that asymmetry for decades: transmit luminance (Y) in full and dilute the color (chroma). The 4:x:x notation describes how many color samples survive in each 2×2 pixel block:

The trick is so good that nearly every movie and TV show you've ever watched is 4:2:0: Blu-ray, streaming, broadcast. On moving pictures, nobody notices. Where does it fall apart? On hard, static color edges: thin red text on a white background, the lines of a CAD drawing, the 12 px font of a spreadsheet. There, diluted color turns crisp edges into smudged fringes.

HDMI, DisplayPort and the fine print

Brochures advertise the raw number (18, 48, 80 Gbps), but part of those bits is packaging: line coding that keeps the signal stable on the wire. HDMI through 2.0 uses 8b/10b — 2 of every 10 bits are cardboard — so of the 18 raw Gbps, 14.4 carry data. HDMI 2.1 switched to 16b/18b (48 → 42.67) and DisplayPort 2.1 to 128b/132b, where almost everything is payload. Comparing brochures without subtracting the packaging is like comparing salaries without asking if they're gross or take-home.

And about cables: at 1080p (3.5 Gbps) almost anything passes, which is why the bargain cable "works" in the quick test. At 4K60 you're asking for 6 Gbps per lane, and that's when the sparkles, dropouts and HDCP handshake failures show up. Buy cables with real certification — Premium High Speed (18 Gbps) or Ultra High Speed (48 Gbps), with the holographic label and scannable QR — and past 7 or 8 meters at 4K, forget passive copper: go active or optical (AOC), which reaches 30, 50 or 100 m. The word "4K" printed on the box is not a specification. It's decoration.

Past 10 meters: HDBaseT and AV over IP

When the distance exceeds what HDMI tolerates with dignity, you change vehicles. HDBaseT packs video, audio, control (RS-232 and IR), Ethernet and even power (PoH) into a single Cat6 twisted pair run: Class A reaches 100 m, Class B 70 m. The classic generations move the equivalent of HDMI 1.4 (10.2 Gbps raw), so 4K60 travels as 4:2:0 (7.13 Gbps: it fits); HDBaseT 3.0 raises that to 18 Gbps over Cat6A and passes 4K60 4:4:4 with no tricks. The operational beauty: the cable is ordinary UTP — pulled by the same tech who wires the network and certified with the same tools. Variants and reach are in the HDBaseT calculator.

AV over IP is the other philosophy: instead of a dedicated matrix, one encoder per source and one decoder per display, all hanging off a switch. On a 1 Gbps network it travels compressed (H.264/H.265, a few frames of latency — fine for signage, marginal for live presenting); on 10 Gbps (SDVoE, JPEG-XS) compression is so light and latency so low that it competes with the matrix. And it scales like the network it is: another display? Another switch port, not a new chassis.

Pocket rule: point-to-point up to 100 m → HDBaseT; big matrix, many floors or unpredictable growth → AV over IP. If you go IP, size the switch with multicast and proper IGMP snooping: twenty 900 Mbps streams don't route themselves.

Projection and walls: the screen gets calculated too

That leaves the other half of the project: how big the picture is and from where. For projectors the key is the throw ratio: distance divided by image width. A projector with a 1.5 TR filling a 2.4 m wide screen needs 1.5 × 2.4 = 3.6 m of distance — not a centimeter of faith involved. It works backwards too: a 0.8 short-throw hung 4.2 m away would paint a 5.25 m wide image, wider than the wall. That's why you pick the projector to match the room and not the week's special offer; the projection calculator solves it in both directions, lumens included.

And a video wall? Tile arithmetic, with one treacherous detail: the bezel. Take the classic 3×2 with 55" video-wall panels: an active area of 1210.6 × 681 mm per panel and 3.5 mm of combined bezel between neighbors. Total width: 3 × 1210.6 + 2 × 3.5 = 3638.8 mm ≈ 3.64 m. Height: 2 × 681 + 3.5 = 1365.5 mm ≈ 1.37 m. Combined resolution: 5760 × 2160 = 12.4 megapixels — 50% more pixels than 4K, and the wall controller has to feed every one of them. Pixel pitch lands at 0.63 mm: sharp even from a meter away.

Before promising a client a wall, run the panel grid through the video wall calculator: dimensions, resolution, pitch and minimum viewing distance come out on their own — and you find out in time that the "3×3 of 65-inch panels" doesn't fit on the 4-meter wall once the ceiling molding has its say.

The checklist before you quote

Every video project boils down to four questions: how many Gbps the signal weighs (calculate them), which link in the chain is the weakest, how many meters it has to travel, and what image size the room demands. Answer them with numbers before buying a single cable, and that display 20 meters away lights up on the first try — no sparkles, no black screens, no second site visit.

A store once called us because "the amplifier shuts itself off when we turn it up". In the back room we found the crime scene: twenty 8 Ω ceiling speakers, all wired in parallel, hanging off a living-room HiFi amp. Twenty 8 Ω loads in parallel make 0.4 Ω — to the amplifier that's not a sound system, it's a short circuit with background music. The amp was doing the only sensible thing (going into protection), right at peak hour. The fix wasn't a bigger amplifier: it was a different philosophy. Welcome to the 70V line.

The problem: ohms don't add up, they divide

In parallel, total impedance is one speaker's impedance divided by the count: 8 Ω ÷ 20 = 0.4 Ω. A typical amplifier tolerates down to 4 Ω; at 0.4 Ω the current skyrockets and the output stage waves the white flag. You could build series-parallel combinations to raise the impedance — and for two or four speakers in a meeting room that works fine; the speaker impedance calculator does that gymnastics for you. But for twenty speakers spread across a store it's punishment: every speaker you add or remove changes the whole equation, and power splits evenly even when aisle 3 needs twice as much as the checkout.

There's a second, quieter problem: at low impedance, pushing 200 W means 22.4 A through the cable. That demands thick conductors, and on long runs the cable eats an embarrassing share of your power. Twenty speakers easily means 100 or 200 meters of wire. Bad business.

The 70V line: think like the power company

The electrical grid solved this a century ago: transmit at high voltage and low current, then step down with a transformer at every house. Commercial audio copied the trick wholesale. The amplifier publishes a constant-voltage 70V line, and each speaker hangs off it through a small transformer with a tap selector: a knob that decides how many watts that speaker draws — 5, 10, 30 W — without asking anyone else's permission.

The consequences are delightful. Every speaker sits in parallel on a single daisy-chained cable, and impedance stops being your problem: as long as the sum of taps stays under the amplifier's power, the line is healthy. Moving 200 W at 70 V takes just 2.86 A (versus 22.4 A for the low-impedance approach), so the cable can be thin and long. And each zone sets its own relative volume by turning its tap: warehouse loud, fitting rooms gentle, without touching the amp.

The full math: grocery-store arithmetic

Here's the best part: sizing a 70V line requires no circuit algebra. It's literally adding up watts, like totaling receipts. The store, step by step:

1. Add the taps. 20 speakers, each with its tap set to 10 W: 20 × 10 W = 200 W. That's the entire load the amplifier will see.
2. Leave headroom. An amplifier running at 100 % lives a short life and sounds worse. Add 20 %: 200 × 1.2 = 240 W. The next commercial size up is a 250 W amplifier. That's the one you buy.
3. Check the minimum impedance. The 70V line frees you from thinking in ohms, but the amp still sees an impedance: Z = V² / P = 70² / 200 = 4900 / 200 = 24.5 Ω. If you measure the installed line with an impedance meter and get less than that, there are extra taps (or a speaker connected without its transformer) hanging on the cable.
4. Size the cable with the real current. I = P / V = 200 / 70 = 2.86 A. A 16 AWG conductor strolls through that — compare it to the 22.4 A the same system would draw at low impedance.
5. Enjoy the scalability. They want one more speaker in the new aisle tomorrow? Hang it on the cable, set its tap, add it up: 210 W. As long as the sum fits in the amplifier with its headroom, nothing else gets recalculated. The 70V line calculator tracks the sum, the impedance and the headroom for you.

The available taps are printed on the speaker's selector, and each tap is equivalent to a fixed impedance on the line (Z = 4900/P at 70 V):

SPL: how much reaches the ear

You know how many watts each speaker draws. The client's question is different: will people actually hear it? Answering takes two datasheet numbers and one law of physics.

Number one is sensitivity: how many dB SPL the speaker produces with 1 W, measured at 1 m (typically 86 to 95 dB). Number two is the tap power. And the law of physics is the inverse-square law: every time you double the distance, you lose 6 dB. The whole formula fits on one line:

SPL = sensitivity + 10·log₁₀(W) − 20·log₁₀(d)

Real example: a warehouse horn with 90 dB sensitivity, tap set to 30 W, listener at 8 m: 90 + 10·log₁₀(30) − 20·log₁₀(8) = 90 + 14.77 − 18.06 = 86.7 dB. Is that enough? A warehouse with forklifts runs 70-75 dB of ambient noise, and for a page to be intelligible you want 10-15 dB above it: 86.7 dB passes — barely, but it passes. The SPL calculator runs this both ways: it tells you what arrives, or what power you need for a target dB.

Two decibel traps before we move on. Doubling the power only adds 3 dB — barely noticeable. And for something to sound "twice as loud" to the ear you need +10 dB, meaning ten times the power. That's why the cheap road to more level is almost never a bigger amplifier: it's a more sensitive speaker or, better yet, more speakers well distributed. Which brings us to the ceiling.

Ceiling coverage: circles that touch

A ceiling speaker doesn't light up the whole room: it paints a circle of sound at ear height, the way a shower head paints a circle of water on the floor. Outside the circle, level and clarity fall off fast. Coverage design is therefore a geometry problem: tile the floor plan with circles.

For the typical ceiling speaker with 90° dispersion, the rule is a gift: the radius of the circle at ear height equals the distance from ceiling to ear (tan 45° = 1 — the friendliest trigonometry in the trade). With a 3.0 m ceiling and seated listeners (ears at 1.2 m): r = 3.0 − 1.2 = 1.8 m. For background music and general paging it's enough for the circles to touch edge to edge: one speaker every 2 × r = 3.6 m. Standing crowd? Ears at 1.5 m, radius 1.5 m, speakers every 3 m. Critical intelligibility (evacuation messages)? Overlap the circles: spacing of r·√2 ≈ 2.5 m.

Note the counterintuitive detail: with higher ceilings the circle grows and you need fewer speakers per square meter — but each one needs a higher tap to make up for the extra distance to the ear (the −6 dB staircase takes no prisoners). Geometry and SPL get calculated together, never separately.

Delay: sound is late everywhere

Sound travels at c = 331.3 + 0.606·T m/s — at 20 °C, about 343.4 m/s. In field units: almost 3 ms per meter (2.912 ms, to be exact). The light in your VLANs waits for no one; sound, on the other hand, arrives late everywhere, and in large rooms you can hear the tardiness.

Classic case: a stage with its main speakers and a fill row under the mezzanine, 10 m further back. For the audience at the rear, the fill (right next to them) sounds before the stage: two separate arrivals, smeared sound, and if the gap grows, outright echo. The fix is elegant: electronically delay the near speakers so their audio leaves just as the stage's audio arrives. The 10 m difference is 10 ÷ 343.42 = 29.1 ms of delay, which at 48 kHz is 1,398 samples — DSPs work in whole samples, hence the ugly number. The audio delay calculator converts meters to ms and samples, temperature included.

Dante and AES67: audio takes over the network

One last leg: moving the audio between the console, the DSP and the amplifiers. The 40 kg copper multicore lost its throne to a network cable: Dante (and its interoperability standard AES67) carries uncompressed audio over ordinary Ethernet. The math is reassuring: one channel at 48 kHz and 24 bits weighs 48,000 × 24 = 1.152 Mbps of pure audio — with IP headers it stays under 1.5 Mbps — so 64 channels are about 74 Mbps and a gigabit link carries hundreds of channels without breaking a sweat; the audio-over-IP calculator gives you the exact figure with overhead. Typical network latency is 1 ms — less time than sound needs to cross 34 cm of air — meaning that moving audio 100 m over fiber costs less than moving it from the speaker to your shoulder.

The price of the elegance is network discipline: a dedicated VLAN for audio, DSCP-based QoS honored on every switch (the PTP clock rules), and no WiFi anywhere in the channel path. Dante marks its own traffic; your job is making sure the switches don't treat it like just another torrent:

PTP (clock)   → DSCP 56 (CS7)  → highest-priority queue
Audio         → DSCP 46 (EF)   → high queue
Control       → DSCP 8  (CS1)  → normal
Everything else → DSCP 0 (BE)  → best effort

Next time someone asks you to put sound in a venue, you have the full recipe: add up taps and headroom in the 70V line calculator, check with the SPL calculator that the page beats the noise, tile the ceiling with circles, and give networked audio its own VLAN with QoS. The amplifier will live for years and the client won't notice a thing — which, in commercial audio, is exactly the goal.

During an audit at a small business we found the NVR password on a sticky note: "P@ssw0rd!". The IT guy was relaxed — it had an uppercase letter, a number and a symbol, so it "met the policy". We ran it against a leaked-password dictionary and it fell before the coffee got cold: it's on every list on the planet. Meanwhile "correct horse battery staple" — which looks like a joke — would have outlived the company. The difference between the two isn't opinion or magic: it's arithmetic, and by the end of this guide you'll be able to do it in your head.

Entropy: strength is length × log₂(alphabet)

An attacker doesn't "read" your password: they guess it by trying combinations. A password's strength is, quite literally, the size of the haystack it's hiding in. That size is measured in bits of entropy, and the formula fits on a napkin: entropy = length × log₂(alphabet size). Every additional bit doubles the combinations an attacker has to try.

Think of a bike lock: adding weird symbols makes each dial slightly bigger; adding characters adds whole dials. A lowercase letter is worth log₂(26) = 4.70 bits; a character drawn from all four classes (94 printable ASCII symbols) is worth 6.55. The per-character difference is small — the difference from length is brutal, because length multiplies.

So what about "P@ssw0rd!"? On paper, 9 characters × 6.55 = 59 bits. But the formula assumes every character was chosen at random, and that's the catch: "P@ssw0rd!" is the word "password" with the a→@ and o→0 mutations that every cracking tool tries first, by rule. Its real entropy is a handful of bits: it sits a couple million guesses from the front of the line, not 2⁵⁹ deep. A passphrase does the opposite: it picks words at random from the EFF list of 7776 words, and each word is worth log₂(7776) = 12.92 bits even though it reads like a bedtime story.

The worked example: your password vs a GPU

Realistic scenario: a service got its database leaked and the passwords were stored with a fast hash (SHA-256, no salt, no stretching — it happens more than you'd think). A single desktop GPU tries on the order of 10¹⁰ hashes per second, and on average finds the password after searching half the space. Let's run the whole thing:

1. The formula: entropy = length × log₂(alphabet). For 8 lowercase letters: 8 × log₂(26) = 8 × 4.70 = 37.6 bits, i.e. 26⁸ ≈ 2.09 × 10¹¹ combinations.
2. Average time = (2^bits ÷ 2) ÷ rate. At 10¹⁰ guesses/s: 2.09 × 10¹¹ ÷ 2 ÷ 10¹⁰ ≈ 10.4 seconds. Your 8-lowercase password lasts less than a coffee run.
3. Move up to 12 characters with 4 classes (pool 94): 12 × 6.55 = 78.7 bits → 94¹² ≈ 4.76 × 10²³ combinations. Average: 2.38 × 10¹³ seconds ≈ 754,000 years. Same GPU, same attack.
4. The passphrase: 4 random EFF words = 4 × 12.92 = 51.7 bits → ≈ 2.1 days against a fast hash. Borderline. With 6 words: 77.5 bits → ≈ 350,000 years, and you can memorize it on the walk to your car.
5. The takeaway: going from 4 to 6 words multiplies the attacker's work by 7776² ≈ 60 million times. Entropy doesn't add — it multiplies.

Two honest caveats. First, this is an offline attack against a fast hash: if the service stored bcrypt or scrypt, the rate collapses to around 10⁴ guesses/s and those same 8 lowercase letters go from 10 seconds to about 4 months (121 days). Second, an online attack against a rate-limited login is orders of magnitude slower still. Play with policies, rates and scenarios in the entropy and crack-time calculator.

The password manager: the logical conclusion

Follow the math all the way. You need unique passwords per service — because when that RC-plane forum you signed up for in 2019 gets breached, the first thing attackers do is try that same email and password against your bank, your VPN and your work email (it's called credential stuffing and it's the most profitable attack there is). And each one needs 75+ bits. Nobody memorizes eighty random 12-character strings: the arithmetic leaves exactly one way out.

That way out is the password manager: one master passphrase of 6 words (77.5 bits, memorable, written down nowhere) and everything else machine-generated — 20 characters, unique, never meant to be remembered or typed by hand. The manager isn't a convenience: it's the only architecture where the formula balances. And wherever the service offers it, a second factor on top.

Hashes: a fingerprint, not encryption

New topic, same numeric spirit. A hash is a one-way function: anything goes in — a single letter, a 2 GB firmware — and a fixed-length fingerprint comes out. Like an actual fingerprint: it identifies you without letting anyone reconstruct you. Here lives the most repeated misconception in the trade: hashing is not encryption. Encrypted data can be decrypted with the key; a hash has no way back — there is no "unhash". And it has the avalanche effect: change one letter of the input and the whole fingerprint changes.

Use 1: verifying integrity. You downloaded a firmware and the vendor publishes its SHA-256: if your hash matches, the file arrived intact and nobody tampered with it along the way. It looks like this (and yes, one different letter would have produced an unrecognizable fingerprint):

$ echo -n "redzilla" | md5sum
e9b5a2402e7ab94f63d139974709317a  -
$ echo -n "redzilla" | sha256sum
bcff34d1effbe914707d30410323f9ead560f3f610c8aa6aa710f95993551d15  -

Use 2: storing passwords. A well-built service never stores your password: it stores its hash, under two conditions. A unique salt per user — a random value mixed with the password before hashing, so two users with the same password don't share a hash and precomputed tables become useless. And an algorithm that is slow on purpose: bcrypt, scrypt or Argon2 run thousands of iterations precisely so the GPU from our example drops from 10¹⁰ to 10⁴ guesses per second. MD5 and SHA-1 are the opposite: designed in the 90s to be fast, which is exactly what you don't want facing an attacker.

Field bonus: hashes can be identified by eye from length and format. Practice with the hash calculator and the hash identifier:

Inside a JWT: a laminated ID, not a sealed envelope

JWT tokens carry half the sessions on the internet and drag along the same misunderstanding as hashes. A JWT is three Base64URL blocks joined by dots: header (the algorithm), payload (the data: who you are, when it expires) and signature. The right analogy is a laminated ID card: anyone who picks it up can read your name and date of birth — the plastic hides nothing. What the hologram (the signature) does is expose whether someone altered it.

Try it yourself — decoding the header requires no secret whatsoever, just undoing the Base64:

$ echo 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9' | base64 -d
{"alg":"HS256","typ":"JWT"}

Hence the two golden rules. One: never put secrets in the payload — no keys, no sensitive data, nothing you wouldn't show the token's holder, because they (and any proxy along the way) can read it with two lines of terminal. Two: the iat (issued at) and exp (expires) claims are Unix seconds, and a short exp isn't backend fussiness: a stolen JWT can't easily be "revoked", so its lifetime is your only brake. Paste any token into the JWT decoder — it runs 100% in your browser — and see what it's declaring inside.

Base64, UUIDs and other disguises

You've already met the reason the payload is readable: Base64 is encoding, not encryption. It turns arbitrary bytes into 64 harmless characters so they survive trips through email, JSON or URLs — and anyone can reverse it without a key, paying a 33% size tax along the way. Writing in Greek doesn't hide the message from someone who reads Greek. If you ever see data "protected" with Base64, run it through the encoder and say hi to the plaintext.

And to complete the kit, UUIDs in one sentence each. UUID v4: 122 bits of cryptographic randomness — impossible to guess, perfect as a public identifier. UUID v7: puts a millisecond timestamp up front, so IDs are born in chronological order and don't wreck your database indexes. Generate both (plus ULIDs) in the UUID generator — but remember an identifier is not a credential: the thing that guards access is called a token, and it gets signed.

That's practical security in three habits: a long passphrase for the one thing you memorize, a manager for everything else, and an instant reflex of distrust toward anything that "looks" encrypted but is merely encoded. Run your current policy through the entropy calculator and crack open one of your own tokens in the JWT decoder: numbers persuade better than any lecture.

The phone rings: "the internet is down." You show up (or remote in) and, naturally, the internet is fine — it's the billing system that won't load. After enough field calls you learn that nearly every "the internet is down" is one of four things: the name doesn't resolve, the machine doesn't answer, the port is blocked, or the problem belongs to someone else — the hosting company, the ISP, the domain somebody forgot to renew. The good news: all four can be checked in minutes, in order, with evidence you can paste straight into a ticket. This guide is that order.

The detective's four questions

Before rebooting anything "just in case," ask the questions in sequence. Each one rules out an entire layer, and each "no" points at a different suspect:

• Does the name resolve? If the domain won't translate to an IP, nothing else matters. Tool: dig or the DNS lookup.
• Does the IP answer? A name can resolve perfectly to a machine that's powered off. Tool: ping.
• Is the port open? The machine can be alive with the service dead, or a firewall in the way. Tool: the port tester.
• Who owns it, and how does the path look? If everything on your side checks out, you need to know who to call. Tool: WHOIS / RDAP and traceroute.

The order isn't cosmetic: if the name doesn't resolve, testing the port is a waste of time; and if the IP answers but the port stays silent, you already know the cable isn't the problem. Troubleshooting is ruling out layers, not guessing.

The full case: from "it won't load" to a ticket with evidence

Let's run the flow on a classic: the branch office reports that billing.example.com "won't open," while the rest of the internet works. Stopwatch running:

1. Does it resolve? dig +short A billing.example.com returns 203.0.113.80. The answer carries TTL 287 out of the original 300: the resolver cached it 13 seconds ago, meaning someone else just asked the same thing. The name is healthy. Next.
2. Does the IP answer? ping -c 4 203.0.113.80: 4 sent, 4 received, 0% loss, average rtt 45.2 ms. The machine is alive and the route works. (If ping stayed silent, careful: that's not conclusive — plenty of firewalls drop ICMP on purpose. Move to step 3 anyway.)
3. Is the port open? TCP test against 443 with the port tester: the SYN goes out and after 3 seconds… nothing. State: filtered. That is not a dead service — a dead service answers instantly with an RST ("closed"). Total silence is the signature of a firewall dropping packets.
4. Who owns it? RDAP on 203.0.113.80: AS64500, "Hosting Ejemplo SpA". It's the right provider — nobody hijacked the IP and the domain didn't expire. The problem sits at their door.
5. The ticket. You grab your public IP from My IP (198.51.100.22) and write: "DNS resolves to 203.0.113.80, the IP answers ping at 45 ms, but TCP 443 shows filtered from our IP 198.51.100.22 since 09:40." Four commands, about three minutes, and the provider can't answer with "reboot your router."

$ dig +short A billing.example.com
203.0.113.80

$ ping -c 4 203.0.113.80
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max = 43.8/45.2/47.1 ms

$ nc -zv -w 3 203.0.113.80 443
nc: connect to 203.0.113.80 port 443 (tcp) timed out

The journey of a DNS query

To troubleshoot DNS with any confidence you need to know who asks whom. It works like finding a person in a city you don't know: you ask the front-desk concierge; the concierge doesn't know either, but knows exactly who to ask — and once the answer comes back, writes it down for the next person who asks.

• The stub is your device: all it knows is how to hand the whole question to its configured resolver.
• The recursive resolver (your ISP's, or 1.1.1.1, or 8.8.8.8) is the concierge: it does the legwork and caches every answer.
• The root servers — 13 named identities, a through m.root-servers.net, replicated across hundreds of anycast instances worldwide — know exactly one thing: who runs each ending. ".com? Ask the .com registry."
• The TLD (.com, .cl) doesn't know your IP either: it knows which servers are in charge of example.com.
• The authoritative server is the homeowner: it holds the zone with the real records and answers with authority.

Here's the detail that kills the industry's favorite myth: every answer travels with an expiry date — the TTL, in seconds. Until it expires, the resolver answers from cache without asking anyone. Which is why the famous "DNS propagation" does not exist: there is no process pushing your new record around the world. There are thousands of caches that stored the old value and will each let it go when their own TTL runs out. "Waiting for propagation" is, quite literally, waiting for the yogurt to expire.

The records you'll actually use

A DNS zone is a table of typed facts. These six cover 95% of an integrator's work — you can query them all from the DNS lookup tool:

PTR deserves one more sentence: it lives in a mirror zone (in-addr.arpa for IPv4, ip6.arpa for IPv6) where the IP is written with its octets reversed — 203.0.113.80 is looked up as 80.113.0.203.in-addr.arpa. If you need to build those names without pain, the reverse PTR zone tool generates them from an IP or CIDR.

When two resolvers disagree

You migrated billing.example.com to a new server yesterday, and today half the users still land on the old one. Black magic? No: caches. Ask two different resolvers the same question and compare:

$ dig A billing.example.com @1.1.1.1 +noall +answer
billing.example.com.   287   IN   A   203.0.113.80

$ dig A billing.example.com @8.8.8.8 +noall +answer
billing.example.com.   5100  IN   A   198.51.100.7

Cloudflare (1.1.1.1) already has the new IP. Google (8.8.8.8) is still serving the old one — and the middle number tells you exactly how long is left: 5100 seconds, 85 minutes of remaining cache. It isn't "propagating slowly": it cached the record before the change, with the old TTL, and will drop it when that expires. Not one second sooner. The DNS propagation tool runs this comparison against several public resolvers at once — the civilized way to answer "has it propagated yet?": no, Google's yogurt has 85 minutes left.

Mail that lands: SPF, DKIM and DMARC

Half of modern DNS troubleshooting is mail landing in spam. Email was born with zero authentication — anyone can write "From: ceo@example.com" on an envelope — so three layers were bolted on, all published as TXT records in your zone:

• SPF is the guest list: which servers may send mail on the domain's behalf. v=spf1 include:_spf.provider.com -all means "these ones yes, everyone else no."
• DKIM is the notarized signature: the sending server cryptographically signs each message and publishes the public key at selector._domainkey.example.com. Unlike SPF, the signature survives forwarding, because it travels with the message.
• DMARC is the policy: it tells receivers what to do with mail that passes neither SPF nor DKIM aligned with the visible From domain — and where to send you reports (rua) about who's sending in your name.

DMARC is adopted as a ladder, not a switch:

Start at p=none and read the reports for two to four weeks: that's where the CRM, the multifunction printer and that legacy system nobody remembered sends email all show up. Once every legitimate sender passes SPF or DKIM, move up to quarantine (with pct=25 it applies to 1 in 4 messages, so you brake slowly) and finally reject. The SPF/DKIM/DMARC tool fetches and explains all three records for a domain in one pass. And don't forget the PTR from the previous section: plenty of servers flat-out refuse mail from an IP with no coherent reverse.

Ports: open, closed or filtered

The last link in the flow earns its own section, because the three states of a port tell three different stories. Picture yourself knocking on a door:

• Open: someone opens. The SYN got its SYN/ACK — a service is listening and the firewall lets it through. If the application still fails, the problem lives higher up (TLS, credentials, the app itself).
• Closed: someone yells "nobody's home!" An immediate RST came back — network and firewall work, but no service listens on that port. Dead service or wrong port. In firewall terms: REJECT behavior.
• Filtered: dead silence. The packet died along the way with no reply — the signature of a firewall in DROP mode. For troubleshooting this is gold: it tells you there's a rule in the middle, and the ticket goes to whoever owns the firewall, not the server.

One detail that saves confusion: the port tester looks at your host from the internet. A port can be open on the LAN and filtered from outside (NAT or perimeter firewall), and that's not a bug — it's exactly the difference you want to measure. For the same reason, when you report a block that depends on the source, include your public IP — My IP hands it to you with ASN and organization included.

Next time someone yells "the internet is down," take a breath and run the four questions: name, IP, port, owner. Ten minutes and four tabs — DNS, ping, ports and RDAP — leave you with a defensible diagnosis instead of "looks like the provider's fault." And if the problem is email, same recipe with SPF/DKIM/DMARC: evidence first, policy second.

Same week, three conversations: a vendor swears his radio "pushes 400 mW", the SFP datasheet talks about a 28 dB optical budget, and a client wants to know why the WiFi reads −72 dBm "when the router is brand new". Milliwatts, dB, dBm — they sound like three languages, but it's one language with three accents. And the whole grammar fits on a napkin: one logarithm, a few magic numbers, and a reference. Let's take it apart, no drama required.

A dB is not a unit: it's a comparison

First, the uncomfortable part: a decibel measures nothing on its own. It's a way of saying "how many times more" (or less) between two quantities:

dB = 10 · log10(P2 / P1)

That's it. Everything else — dBm, dBi, dB SPL — is a variant of this one formula where somebody nailed down the reference P1. If someone tells you "the signal is 40 dB" without saying relative to what, they're telling you "my house is at 40" without saying 40 what.

So why drag a logarithm into something as simple as dividing? Because in RF and optics the ratios are monstrous. A 10 km link at 5.8 GHz loses a factor of almost six trillion along the way (a 6 followed by 12 zeros). Nobody does arithmetic with numbers like that. The logarithm squashes them down to human scale: that atrocious loss becomes 127.7 dB, a number you can jot on a napkin. Think of the logarithm as a zero counter: 10 dB for every zero in the ratio.

And the logarithm brings the gift that justifies the whole invention: multiplying ratios equals adding their dB. A chain of amplifiers, cables and air — every stage multiplying or dividing the power — collapses into grade-school addition: +14 here, −127.7 there, +14 on the way back in. That's why link budgets are added: not a convention for the lazy, but the mathematical property that makes the decibel useful.

The magic numbers: 3, 10 and their combinations

To work in dB you don't need to compute logarithms. You need to memorize two equivalences and combine them:

• +10 dB = ×10 exactly. Straight from the definition: log10(10) = 1. From there, +20 dB = ×100 and +30 dB = ×1000.
• +3 dB ≈ ×2. The real value is ×1.995 — a quarter of a percent short of doubling, and nothing in the field measures that finely. Its mirror image: −3 dB ≈ ÷2 (×0.501).

With those two pieces you build anything, LEGO-style: +6 dB = 3+3 = ×4 (really 3.98). +13 dB = 10+3 = ×20. −23 dB = ÷200. And +1 dB? That's ×1.26 — a quarter more — but honestly, the 3 and the 10 cover 95% of your life. The dB converter supplies the decimals when the napkin runs out.

dBm: the dB that actually is a quantity

Enter the star of the family. A dBm is a dB whose reference got fixed by decree: P1 = 1 mW. Pin the reference and the comparison becomes absolute: 0 dBm isn't "zero power", it's exactly 1 mW. From there, the ladder runs in steps of 10:

• +30 dBm = 1 W (1 mW × 1000).
• 0 dBm = 1 mW — the reference, the zeroth rung.
• −30 dBm = 1 µW, −60 dBm = 1 nW, −90 dBm = 1 pW.

Look at the span: from −90 to +30 dBm is a factor of one trillion, and the scale covers it in 120 equal little steps. Your entire working day lives on that ladder: a WiFi radio transmits around +23 dBm (200 mW), a fiber receiver is comfortable at −8 dBm (0.16 mW), and a well-designed WiFi cell delivers about −65 dBm at the edge — which is 316 picowatts, and your phone holds a video call on it. Modern radio is, quite literally, the art of listening to picowatts.

Because the reference is fixed, the unit algebra stays clean: dBm + dB = dBm (you apply a gain or loss to a level), and dBm − dBm = dB (the difference between two levels is a ratio). When you need real decimals, the dBm/mW converter handles both directions.

Calculator head: dBm to mW in one afternoon

The mental conversion trick is to break the number into tens and threes, starting from the nearest multiple of 10:

$ dbm 23
23 dBm = 20 dBm + 3 dB = 100 mW × 2 = 200 mW   (exact: 199.5)
$ dbm 27
27 dBm = 30 dBm − 3 dB = 1000 mW ÷ 2 = 500 mW  (exact: 501.2)

That's the whole method: anchor on 0, 10, 20 or 30 dBm and adjust by ±3. One afternoon of practice and you'll translate datasheets faster than the vendor's page loads:

Notice the 26? That's the vendor's radio from the opening: "pushes 400 mW" translates to 26 dBm, and now you can compare it against anything without reaching for your phone. To go from dBm to dBW, subtract 30 and you're done: +23 dBm = −7 dBW (which is why almost nobody uses dBW indoors — the negatives get confusing).

The dB family: same movie, different opening scene

Once you see the pattern — generic dB + fixed reference = absolute unit — you recognize the whole clan:

• dBi: antenna gain relative to an isotropic antenna, the ideal sphere that radiates equally in all directions. It doesn't physically exist; it's the measuring stick.
• dBd: the same, but relative to a half-wave dipole, which has gain of its own. The conversion is fixed: dBi = dBd + 2.15. Watch the catalogs: the same antenna "performs better" in dBi, and some marketing department knows it.
• dBµV: voltage level relative to 1 µV, common in cable TV and broadcast. Party trick: 0 dBm into 50 Ω equals 107 dBµV (224 mV).
• dB SPL: sound pressure relative to 20 µPa, the threshold of human hearing. That's why microphone calibrators scream at 94 dB SPL — it's exactly 1 pascal. If you install audio too, the speaker SPL calculator runs on this very scale.

Same formula, same mental trick, different yardstick. You learned one unit and got five for free.

10·log or 20·log: the fine print of the square

You may have noticed dBµV and dB SPL use 20·log instead of 10·log. It's not a different definition — it's the same one. Power grows with the square of voltage (P = V²/R) and of sound pressure, and the logarithm pulls the square out front as a ×2: 10·log10(V²) = 20·log10(V). That keeps the dB consistent across worlds: doubling the voltage is +6.02 dB, exactly the same as quadrupling the power (+6 dB = ×4, really 3.98). One language, no translation. The working rule: power quantities (watts) take 10·log; field quantities (volts, amps, pascals) take 20·log. The dB converter has both modes, so the square doesn't bite you.

The example that ties it all together: 10 km at 5.8 GHz

Let's borrow the exact link from the point-to-point links guide — the guides around here greet each other — and look at it purely through decibel glasses. A 23 dBm radio, 14 dBi antennas on both ends, 10 km of air at 5.8 GHz (a wavelength of about 5.2 cm, by the way — the frequency and wavelength converter will confirm it):

1. You leave the radio at +23 dBm. You can read that without a calculator now: 20 + 3 → 100 mW × 2 = 200 mW.
2. The transmit antenna adds its gain: 23 + 14 = +37 dBm EIRP. In linear terms, about 5 W equivalent concentrated in the beam — you just multiplied by 25 without multiplying: you only added 14.
3. The path charges its toll: free space at 5.8 GHz over 10 km takes 127.7 dB. In ratios: one part in almost six trillion arrives. In dB: 37 − 127.7 = −90.7 dBm. A subtraction.
4. The receive antenna pulls you back up: −90.7 + 14 = Prx = −76.7 dBm. There's the entire magic in one line: +23 + 14 − 127.7 + 14 = −76.7. Four additions modeling twelve-digit multiplications.
5. Translate the result: −76.7 dBm is about 21 pW. Yes, picowatts: you left with 200 mW and arrive with the power of a dying firefly — and it works, because the receiver claims −85 dBm sensitivity. Margin: −76.7 − (−85) = 8.3 dB. Too thin to sleep well; how to fatten it up is exactly what the point-to-point links guide covers.

If the install had 10 meters of coax between radio and antenna, it would enter the same sum as one more negative term — the coax loss calculator tells you how many dB for your cable and frequency. That's the elegance of the system: air, cable, connectors, antennas and amplifiers all speak the same language, and they all join the same sum.

Now the drama is back where it belongs: in the soap operas. Drill the ladder with the dBm/mW converter until 23 → 200 comes out without thinking, sanity-check your ratios in the dB converter, and next time a datasheet talks to you in milliwatts, translate it yourself before the page finishes loading.