ratatop: the network box, and why your ISP lies with units

Maneshwar, a developer building git-lrc, a Micro AI code reviewer, has implemented the network box for a btop-style system monitor in Rust using ratatui. The feature displays both bits and bytes per second to avoid ISP unit confusion, uses three-significant-figure formatting to prevent layout shifts, and mirrors the upload graph for a unified visual. The project is open source on GitHub.

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. Day four of building a btop-style system monitor in Rust with ratatui https://ratatui.rs . CPU, memory, disks are done. Today the network box lands, which means three of btop's four boxes are up. Three things in there took actual thought. The unit situation, the shared scale, and the fact that the upload graph is upside down on purpose. Look at that first row again. ▼ 566 Byte/s 4.42 Kibps Same number. Twice. Different units. btop does this deliberately, and once you notice why, you cannot unsee it. Your ISP sells you bandwidth in bits per second. 100 Mbps, 300 Mbps, whatever the sticker says. Your download manager, your browser, and every file transfer you have ever watched report progress in bytes per second. The factor between them is 8. So the "100 Mbps" plan you pay for tops out around 12.5 MB/s in the progress bar, and every few months someone concludes their internet is broken when it is in fact working exactly as sold. btop refuses to pick a side. It shows both, so you can compare against your plan and against your download at the same time without doing mental arithmetic. The conversion in code is unremarkable, which is the point: php fn format bits bytes per sec: f64 - String { const UNITS: &str; 4 = "bps", "Kibps", "Mibps", "Gibps" ; let value, unit = scale bytes per sec 8.0, 1024.0, UNITS.len ; let decimals = decimals value, unit ; format " {value:.decimals$} {} ", UNITS unit } Note Kibps and not Kbps . Dividing by 1024 gives you kibibits; dividing by 1000 gives you kilobits. btop uses 1024, so the label has to say so. Getting this wrong is a 2.4% error that nobody would ever notice and that would still be wrong. Small thing I got wrong and had to fix. My first version formatted rates with a fixed two decimals. Perfectly reasonable, and it produced this: ▼ Top: 4.42 Kibps ▼ Top: 43.80 Kibps ▼ Top: 438.00 Kibps The number changes width as traffic grows, so the whole column shuffles sideways every time the value crosses a power of ten. In a display that redraws twice a second, that is genuinely distracting. The fix is the same three-significant-figure rule the memory box already used: php fn decimals value: f64, unit: usize - usize { if unit == 0 || value = 100.0 { 0 } else if value = 10.0 { 1 } else { 2 } } 4.42 , 43.8 , 438 . Always three digits. Always the same width. This is the second time in this project I have written that exact function, which is usually a sign it should be shared. For now it lives in both places because the memory box counts bytes and this one counts bits, and I would rather have two small honest copies than one abstraction that takes four parameters to explain itself. The two graphs on the left are download on top and upload underneath, and the bottom one is mirrored: it hangs from its top edge and grows downward. flowchart TD subgraph BOX " " D "download graph<br/ grows up from the middle" M "shared baseline" U "upload graph<br/ grows down from the middle" end D --- M M --- U It reads as one figure with traffic flowing outward from a centre line, rather than two unrelated charts stacked by coincidence. My BrailleGraph widget from day one only knew how to fill upward from the bottom, so this needed a new option. The change turned out to be four lines, because the only thing that differs is which end you count the dot rows from: js let offset = if self.inverted { dot } else { dot rows - 1 - dot }; That is the whole feature. Everything else, the braille bit packing, the gradient, the two-samples-per-cell trick, is unchanged. Here is the part that is easy to get wrong and produces a chart that actively lies. Each direction has its own peak. The obvious move is to scale each graph to its own maximum, so both always use the full height of their box. Do that and you get a display where a 3 KB/s upload trickle and a 3 MB/s download flood are drawn at exactly the same height . Two graphs, sitting adjacent, implying a comparison that is off by a factor of a thousand. So the scale is shared, computed once from whichever direction peaked higher: php pub fn graph max &self - f64 { self.download.top.max self.upload.top .max 10.0 1024.0 } Two details worth pointing out. It scales to the peak seen , not the current value. Scaling to the current value means the graph rescales every frame, so a flat line and a spike look identical and the shape carries no information at all. And there is a 10 KiB floor. Without it, an idle interface scales to its own noise, and three stray bytes of ARP traffic render as a mountain range. The floor is why the label in my screenshot reads 20K even though nothing much is happening. Day three needed a syscall because filesystem usage has no file. Today the same thing happened again, and I did not expect it to. The rates all come from /proc/net/dev . Easy. But the 192.168.29.14 in the title has no file behind it. /proc/net/route gives you the gateway, not your address. /proc/net/fib trie contains local addresses, but it is a serialised routing trie, not an interface listing, and parsing it is exactly as unpleasant as that sounds. /sys/class/net/wlo1/ has the MAC, the MTU, the link speed, and no IP. So it is getifaddrs 3 , and my second unsafe block. js unsafe { let mut list: mut libc::ifaddrs = std::ptr::null mut ; if libc::getifaddrs &mut list = 0 { return addresses; } let mut node = list; while node.is null { let entry = & node; node = entry.ifa next; // ... } libc::freeifaddrs list ; } This one is chunkier than day three's statvfs , because it is a linked list. You walk it, you filter to AF INET because an interface carries several addresses and only IPv4 fits the box, you cast a generic sockaddr to a sockaddr in to reach the actual four bytes, and you free the list exactly once through the same pointer you were handed. The line I am most pleased with is this one: node = entry.ifa next; It advances the cursor before the body of the loop touches anything. Do it at the bottom instead and every continue in the loop becomes an infinite loop. There are two continue s in there. A parsing trap for anyone reading /proc/net/dev : Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets ... wlo1: 319815680 240000 0 0 0 0 0 0 137363456 180000 ... Received bytes is the first counter. Transmitted bytes is the ninth , because receive gets eight columns before transmit starts. Grab field 1 for upload and you will be reporting received packets as your upload speed, and it will look plausible enough that you might not catch it. The two header lines take care of themselves, incidentally. Neither contains a colon, and the parser splits each line on the colon to separate the name from the counters, so they drop out before any field indexing happens. I originally wrote a comment claiming the header needed special handling, then actually checked, and it does not. Worth checking your own comments occasionally. btop puts <b wlo1 n in the corner, which is both a label and a keymap: b for the previous interface, n for the next. js KeyCode::Char 'n' = app.net.cycle true , KeyCode::Char 'b' = app.net.cycle false , Loopback is filtered out of the list. It is always present, always busy, and never the thing you opened a monitor to look at. The default selection comes from /proc/net/route : whichever interface carries the route with a destination of all zeroes is the default route, and that is almost always the one you care about. If that lookup fails, it falls back to whichever interface has moved the most bytes. Processes. The last box, and by a distance the biggest. Reading /proc/ pid /stat for every process on every tick, computing per-process CPU deltas, sorting by any column, and making the list scroll with a selection cursor. htop and btop both have a lot of hard-won edge case handling in that area, so I expect to be reading their source more than usual. Code so far: A reimplementation of btop https://github.com/aristocratos/btop in Rust, built on ratatui https://ratatui.rs . The goal is a resource monitor that feels like btop: the four-box layout, braille graphs with gradient fills, mouse-driven navigation, and a themable process manager, but written as a modern Rust TUI. The CPU box works. It samples real data and renders btop's layout: Per-core braille history graphs, a gradient load bar with sub-cell resolution frequency, package temperature, battery, and load averages. Everything else, the memory, network, and process boxes, is still to come. /proc and /sys on Linux first, read directly rather than shelling out. btop's src/linux/btop collect.cpp is the reference for what to read and how often; the BSD/macOS collectors are out of scope for v1.Today's takeaway is small but general: when you draw two things next to each other, you have implied they are comparable. If they are on different scales, you have drawn a lie. Share the axis or separate the charts. AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production. git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free. Any feedback or contributors are welcome It's online, source-available, and ready for anyone to use. ⭐ Star it on GitHub: | 🇩🇰 Dansk https://github.com/HexmosTech/git-lrc/readme/README.da.md | 🇪🇸 Español https://github.com/HexmosTech/git-lrc/readme/README.es.md | 🇮🇷 Farsi https://github.com/HexmosTech/git-lrc/readme/README.fa.md | 🇫🇮 Suomi https://github.com/HexmosTech/git-lrc/readme/README.fi.md | 🇯🇵 日本語 https://github.com/HexmosTech/git-lrc/readme/README.ja.md | 🇳🇴 Norsk https://github.com/HexmosTech/git-lrc/readme/README.nn.md | 🇵🇹 Português https://github.com/HexmosTech/git-lrc/readme/README.pt.md | 🇷🇺 Русский https://github.com/HexmosTech/git-lrc/readme/README.ru.md | 🇦🇱 Shqip https://github.com/HexmosTech/git-lrc/readme/README.sq.md | 🇨🇳 中文 https://github.com/HexmosTech/git-lrc/readme/README.zh.md | 🇮🇳 हिन्दी https://github.com/HexmosTech/git-lrc/readme/README.hi.md | GenAI today is a race car without brakes . It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things : they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production. git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen At a glance: 10 risk categories https://github.com/HexmosTech/git-lrc what-git-lrc-checks-for · 100+ failure patterns tracked https://github.com/HexmosTech/git-lrc what-git-lrc-checks-for · every commit…