Tor Bandwidth Authorities and Weight Assignment

Tor has specialized directory authorities called bandwidth authorities (currently 8 active, run by trusted community members) that measure relay capacity. The measurement process: a bandwidth authority builds circuits through the relay under test and downloads data, measuring actual throughput. Each bandwidth authority independently measures relays and reports results. The consensus (produced by all directory authorities) uses the median of bandwidth measurements for each relay as its consensus weight. This measured bandwidth (not the self-reported bandwidth from the relay's MyFamily and BandwidthRate settings) determines the weight. A relay that reports 100 Mbps but bandwidth authorities can only achieve 5 Mbps through it will receive a weight reflecting 5 Mbps. Accurately measuring relay bandwidth requires consistent availability during the measurement window - relays that are unstable or frequently unreachable receive lower weights.

Two bandwidth figures appear in Tor metrics: self-reported bandwidth (from BandwidthRate in torrc, the operator's stated limit) and consensus weight (measured bandwidth from authorities). Consensus weight is what matters for path selection. A relay's consensus weight is the key performance indicator. New relays receive a low initial consensus weight and scale up over days/weeks as bandwidth authorities measure them (this process is called the Slow Start). The Guard flag requires a relay to have high consensus weight, stable uptime, and predictable bandwidth over time. Maximizing consensus weight: ensure the server's network connection is not saturated (the server should have available headroom above the BandwidthRate limit). Use a VPS with unmetered or high bandwidth allocation. Set BandwidthRate to a value slightly below the actual available capacity (avoid causing bandwidth authorities to encounter rate limiting during measurement, which lowers their measurement).

torrc bandwidth settings: BandwidthRate (sustained bandwidth limit) and BandwidthBurst (instantaneous burst limit). BandwidthBurst allows the relay to serve short spikes above BandwidthRate. Configuration recommendations: set BandwidthRate to your sustained available bandwidth (e.g., 50 MB/s = 50 megabytes per second = 400 Mbps). Set BandwidthBurst to 2x BandwidthRate for typical configurations. The consensus weight measurement reflects BandwidthRate (sustained), not burst. RelayBandwidthRate (only applies to relay traffic, not controller traffic): use instead of BandwidthRate if you run other services on the server. MaxAdvertisedBandwidth: caps the bandwidth advertised to the network regardless of actual capacity. Useful for relays that want to limit their contribution without rate-limiting the server's other traffic.

Server-level optimizations that improve relay throughput and thus consensus weight: (1) Network card tuning: increase TX/RX ring buffer sizes with ethtool -G eth0 rx 4096 tx 4096. (2) TCP buffer sizes: increase socket buffer sizes for high-bandwidth connections: net.core.rmem_max and net.core.wmem_max to 134217728 in sysctl.conf. (3) Increase open file descriptor limit: Tor uses one file descriptor per circuit. Set ulimit -n 65536 in the systemd unit file (LimitNOFILE=65536). (4) CPU affinity: if the server has multiple cores, pin the Tor process to specific cores using taskset to reduce context switching overhead. (5) Network queue discipline: for servers with multiple services, use tc (traffic control) to prioritize Tor's traffic. (6) Kernel version: newer kernels have improved network stack performance. Ensure the server runs a recent stable kernel (5.15+ LTS or 6.x series).

Tor Metrics (metrics.torproject.org) provides comprehensive relay performance data. Relay Search (rs.html): search by fingerprint to see the relay's current status, consensus weight, bandwidth history, and uptime. The 'Details' tab shows flags (Running, Valid, Stable, Fast, Guard, Exit, V2Dir), bandwidth measurements, and the relay descriptor. Bandwidth history graph: shows measured bandwidth over time. A healthy relay shows consistent bandwidth. Drops may indicate: server reboots, network issues, ISP throttling, or resource exhaustion. The Onionoo API (onionoo.torproject.org) provides relay data in JSON format for programmatic access. Use the fingerprint parameter to fetch specific relay data. Custom monitoring scripts can query Onionoo periodically and alert when consensus weight drops below a threshold.