Bandwidth of a Solana shred feed

The measured rate is 54.3 Mbps

shredstream.sh measured the running relay over a 5.6 hour window on 2026-08-31. The feed averaged 54.3 Mbps, 5,585 packets/sec, and 1,216 bytes per packet. At that rate, one destination receives 17.6 TB over a 30-day month.

These are measured means, not protocol maxima or burst limits. A receiver must provision above the mean because block production is bursty, packet sizes vary, and host scheduling creates shorter service windows. The numbers define a credible steady baseline for network, storage, and packet-processing calculations.

Bandwidth answers only one capacity question. Packets per second drives descriptors, interrupts, NAPI polls, socket enqueues, timestamps, and application loop iterations. Byte rate drives link occupancy, copies, capture storage, and provider billing. A design that quotes 54.3 Mbps while ignoring 5,585 packets/sec is incomplete.

The packet arithmetic reproduces 54.3 Mbps

Multiply measured mean packet size by measured packet rate:

1,216 bytes/packet * 5,585 packets/sec = 6,791,360 bytes/sec

Convert bytes to bits:

6,791,360 bytes/sec * 8 bits/byte = 54,330,880 bits/sec

Use decimal network units, where 1 Mbps is 1,000,000 bits/sec:

54,330,880 / 1,000,000 = 54.33088 Mbps = 54.3 Mbps rounded to one decimal place

The independent multiplication agrees with the published measured rate. It also shows the unrounded value used for the monthly calculation rather than multiplying a rounded 54.3.

The 30-day chain produces 17.6 TB

One 30-day period contains:

30 days 24 hours/day 60 minutes/hour * 60 seconds/minute = 2,592,000 seconds

Multiply the unrounded measured byte rate by that interval:

6,791,360 bytes/sec * 2,592,000 seconds = 17,603,205,120,000 bytes

Use decimal storage units, where 1 TB is 1,000,000,000,000 bytes:

17,603,205,120,000 / 1,000,000,000,000 = 17.60320512 TB = 17.6 TB rounded to one decimal place

That is the complete chain from 1,216 bytes and 5,585 packets/sec through 54.3 Mbps to 17.6 TB per 30 days.

Intermediate totals make invoice and disk checks faster:

6,791,360 bytes/sec 3,600 = 24,448,896,000 bytes/hour 24,448,896,000 24 = 586,773,504,000 bytes/day 586,773,504,000 * 30 = 17,603,205,120,000 bytes/30 days

The decimal values are about 24.45 GB per hour and 586.77 GB per day. A daily receiver total materially below 586.77 GB can indicate feed downtime, loss, or a different counting layer. A higher total can include headers, duplicates, unrelated packets, or capture metadata.

Decimal and binary units differ

Network rates use decimal bits per second. 54.3 Mbps means 54.3 million bits per second, not 54.3 mebibits. Storage vendors and cloud invoices often use decimal gigabytes and terabytes, while operating-system tools may show binary GiB and TiB or label binary values ambiguously.

The monthly byte total is 17,603,205,120,000. Divide by 2^40, or 1,099,511,627,776, and the result is about 16.01 TiB. Both 17.6 TB and 16.01 TiB describe the same byte count under different units.

Write the byte count into capacity plans and label every conversion. A disk dashboard showing 16.0 TiB is not contradicting the 17.6 TB product figure. A billing page charging decimal GB should reproduce the decimal calculation.

Packet count reaches 14.48 billion

Packet rate multiplied by the 30-day interval gives:

5,585 packets/sec * 2,592,000 seconds = 14,476,320,000 packets

That is about 14.48 billion datagrams delivered to one destination at the measured mean. Every datagram crosses the NIC, driver, stack, socket, receive loop, and at least part of the decoder. A tiny per-packet allocation or log statement becomes large at that count.

One allocation per packet means more than 14 billion allocations per month. One 100 byte log line per packet creates about 1.45 TB of log text before indexing overhead. The correct ingest path batches system calls, reuses buffers, and aggregates metrics.

Metrics sampling has the same multiplier. Five counters updated atomically for every packet create more than 72 billion atomic operations over the month. Per-thread counters updated in cache-local memory and aggregated once per interval reduce contention. The output accuracy remains adequate because capacity decisions operate on windows, not individual counter-write visibility.

Product bytes are not full wire bytes

The 1,216 byte mean and 54.3 Mbps product figures reproduce each other directly. Full link consumption also includes UDP, IP, Ethernet, and physical framing overhead. Exact overhead depends on address family, VLAN tags, tunnels, and which layer the measured packet byte field represents.

Under the explicit assumption that 1,216 is UDP payload over ordinary Ethernet and IPv4, add 8 bytes UDP, 20 bytes IPv4, 14 bytes Ethernet header, 4 bytes frame check sequence, 8 bytes preamble and start delimiter, and 12 bytes inter-frame gap. That adds 66 wire-time bytes per packet:

1,216 + 66 = 1,282 wire-time bytes/packet 1,282 5,585 8 = 57,279,760 bits/sec = about 57.28 Mbps

This overhead estimate is not the published product rate. It is a labeled capacity calculation under one packet-layer assumption.

IPv6, VLANs, and tunnels add bytes

IPv6 replaces the usual 20 byte IPv4 header with a 40 byte base header, adding 20 bytes per packet before extension headers. One VLAN tag adds 4 bytes at Layer 2. VXLAN, Geneve, WireGuard, GRE, and IPsec add outer headers and may also change the effective MTU.

At 5,585 packets/sec, each additional 4 bytes consumes:

4 bytes 5,585 packets/sec 8 = 178,720 bits/sec = 0.17872 Mbps

Small header differences do not threaten a 1 Gbps link, but they matter when reconciling capture bytes, interface counters, cloud metering, and product payload figures. State the observation layer before comparing totals.

A 1 Gbps link has ample mean headroom

54.3 Mbps is 5.43 percent of a decimal 1 Gbps line rate before full wire overhead. The 57.28 Mbps IPv4 Ethernet estimate is about 5.73 percent. A dedicated 1 Gbps interface therefore has substantial average bit-rate headroom.

The link can still experience microbursts and shared-queue contention. A 10 Gbps storage flow can fill an upstream egress queue even when the feed's own mean is small. Virtual machines can have packet-per-second limits or burst credits below their displayed link speed. Cloud network tiers may cap combined ingress and egress.

Provision from observed one-second, 100 ms, and shorter windows where tooling permits. The mean establishes cost. Burst percentiles establish queue and link headroom.

A nominal 100 Mbps service is a poor choice despite the mean fitting on paper. The IPv4 wire estimate already consumes about 57 percent, leaving limited room for burst ratio, provider policing, and other host traffic. A 1 Gbps port makes the bandwidth margin clear and shifts attention to packet processing and shared virtual-network limits.

Buffer sizing converts rate into time

The measured payload byte rate is 6,791,360 bytes/sec. Payload arriving during a 10 ms pause is about 67,914 bytes. During 100 ms it is about 679,136 bytes. During 250 ms it is about 1,697,840 bytes.

Socket memory consumption exceeds payload because every datagram carries kernel metadata and allocator overhead. A 4 MiB SO_RCVBUF request does not hold exactly 4 MiB of payload, and Linux reports twice the request for bookkeeping. Measure a controlled pause with ss -m and socket drop counters.

Use rate-to-time arithmetic as a lower bound, then validate. A buffer that holds seconds of feed may prevent loss while delivering stale shreds. Maximum residence time is a separate acceptance condition.

Storage depends on what gets retained

Keeping every raw packet continuously consumes the 17.6 TB decimal monthly payload total, plus record framing, timestamps, file-system blocks, indexes, checksums, replication, and capture format overhead. Two replicas can exceed 35.2 TB before those additions. A 30-day circular archive needs deletion and free-space policy.

pcap adds a per-packet record header and a global file header. pcapng overhead varies by block and options and may include interface metadata and timestamps. At 14.48 billion packets, even 16 bytes of per-packet metadata adds about 231.6 GB decimal.

Compression ratio must be measured. Shreds contain high-entropy signatures and encoded data, so generic compression may spend CPU for a modest saving. Compressing on the receive core is unsafe unless tests show substantial headroom.

Cloud ingress, egress, and disk billing differ

Many cloud providers price internet ingress at zero while charging egress, but policies vary by service, region, public IP, transit gateway, load balancer, and cross-zone route. A receiver may pay nothing for the incoming 17.6 TB and still pay to copy it to another zone or object store.

Flow logs, packet mirroring, load balancers, NAT gateways, and managed firewalls can charge per byte or per hour. Sending the full stream through a metered middlebox can cost more than the receiver instance. Billing meters may count Layer 3 bytes and use decimal GB, but the provider definition controls.

Draw the byte path from public ingress through every replication and storage hop. Apply the relevant rate to each hop separately. Do not multiply one published internet price by 17.6 TB and call it total architecture cost.

Capture tools observe different byte counters

ip -s link show dev eth0 reports interface RX bytes and packets. ethtool -S exposes driver and hardware counters with device-specific names. /proc/net/dev provides interface totals. nstat reports IP and UDP protocol counts. The application counts accepted payload bytes.

These totals need not match. Ethernet counters may include headers or exclude some physical overhead. Offloads can affect host-visible packet counts. The interface carries unrelated traffic. UDP counters include all sockets in the namespace. The application can reject packets after the kernel counted them.

Use a strict capture filter for source IP 64.130.40.90 and the configured UDP port, then compare over one interval. Record counter definitions. Agreement within the expected layer overhead is evidence; forced equality is not.

Bursts matter more than the five-hour mean

The 5.6 hour measurement captures a meaningful operating window but not every future leader schedule, network event, or protocol change. Packet production follows slots and transaction load. Coding shreds add recovery traffic. Mean rate can remain stable while short peaks increase.

Collect rolling bytes and packets over one second, 100 ms, and 10 ms buckets in the receiver without logging every datagram. Report p50, p99, p99.9, and maximum bucket rates. Provision socket queues and CPU from the short-window distribution.

Retain the measured date, 2026-08-31, beside the figure. Network behavior evolves. A capacity alert should compare current rolling rates with provisioned ceilings, while site copy changes only after a real measurement update.

Capacity planning needs failure headroom

One destination receives the complete feed. Two independent receiver sites consume 35.2 TB per 30 days at the product payload rate. Dual NIC paths on one host may duplicate packets into the application. Packet capture and decoded storage add further copies.

Size links for feed bursts plus management, clock synchronization, telemetry, and recovery traffic. Size CPU for two-times measured packet rate and injected scheduling pauses. Size storage with retention, metadata, filesystem reserve, and rebuild headroom. Size network billing by hop.

The published mean is a starting number with traceable arithmetic. The production decision comes from measured burst distributions and a documented overload policy. When capacity runs out, UDP drops rather than slowing the source.

Recalculate after any measured rate update using the unrounded packet rate and byte mean. Rounding 54.3 Mbps first and multiplying it by time produces a slightly different byte total. The byte-and-packet source measurements preserve internal consistency across Mbps, daily volume, monthly volume, packet count, and capture expectations.