Bandwidth of a Solana shred feed

Feed rate follows network activity

Solana activity determines the sustained rate observed on the shredstream.sh feed. No fixed throughput or monthly-volume figure remains accurate across future traffic, leader schedules, network events, and protocol changes.

A receiver must measure its current sustained rate and short bursts. Block production is bursty, packet sizes vary, and host scheduling creates shorter service windows. Current observations establish the baseline for network, storage, and packet-processing calculations. Burst percentiles establish headroom.

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 must account for both.

Packet arithmetic converts rate to bandwidth

Take a packet rate of p and a mean packet size of s. Payload byte rate is p multiplied by s, and payload bit rate is that result multiplied by eight.

For an illustrative calculation, use a flow of 6,400 packets each second with 1,125 payload bytes on average:

1,125 bytes/packet * 6,400 packets/sec
= 7,200,000 bytes/sec

Convert bytes to bits:

7,200,000 bytes/sec * 8 bits/byte
= 57,600,000 bits/sec

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

57,600,000 / 1,000,000
= 57.6 Mbps

These are assumed inputs, not a measurement of the shredstream.sh service. Substitute current receiver observations before making a capacity decision.

The 30-day chain follows from byte rate

One 30-day period contains:

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

Multiply the illustrative byte rate by that interval:

7,200,000 bytes/sec * 2,592,000 seconds
= 18,662,400,000,000 bytes

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

18,662,400,000,000 / 1,000,000,000,000
= 18.6624 TB

Intermediate totals make invoice and disk checks faster:

7,200,000 bytes/sec * 3,600 = 25,920,000,000 bytes/hour
25,920,000,000 * 24 = 622,080,000,000 bytes/day
622,080,000,000 * 30 = 18,662,400,000,000 bytes/30 days

For this example, a daily receiver total materially below 622.08 GB can indicate 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. A rate in Mbps uses millions of bits per second, not 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 illustrative monthly byte total is about 16.97 TiB after division by 2^40, or 1,099,511,627,776. Both unit values describe the same byte count under different conventions.

Write the byte count into capacity plans and label every conversion. A disk dashboard using TiB is not contradicting a billing page using decimal TB when both start from the same byte count.

Packet count multiplies per-packet work

Packet rate multiplied by the 30-day interval gives the monthly datagram count. Under the illustrative assumption:

6,400 packets/sec * 2,592,000 seconds
= 16,588,800,000 packets

Every datagram crosses the NIC and driver before traversing the network stack, socket, receive loop, and at least part of the decoder. A small per-packet allocation or log statement becomes costly at that count.

One allocation per packet means nearly 16.6 billion allocations in this example. A 100-byte log record for every packet creates about 1.66 TB of text before indexing overhead. The ingest path should batch system calls, reuse buffers, and aggregate metrics.

Metrics sampling has the same multiplier. 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.

Payload bytes are not full wire bytes

Full link consumption includes UDP, IP, Ethernet, and physical framing overhead beyond application payload. Exact overhead depends on address family, VLAN tags, tunnels, and which layer a measured packet-byte field represents.

Assume explicitly that the 1,125-byte mean is UDP payload over ordinary Ethernet and IPv4. Add 8 UDP bytes, 20 IPv4 bytes, a 14-byte Ethernet header, 4-byte frame check sequence, 8-byte preamble and delimiter, plus a 12-byte inter-frame gap. That adds 66 wire-time bytes per packet:

1,125 + 66 = 1,191 wire-time bytes/packet
1,191 * 6,400 * 8 = 60,979,200 bits/sec
= 60.9792 Mbps

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

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 the illustrative rate of 6,400 packets/sec, each additional 4 bytes consumes:

4 bytes * 6,400 packets/sec * 8
= 204,800 bits/sec
= 0.2048 Mbps

Small header differences may not threaten a fast link, but they matter when reconciling capture bytes, interface counters, cloud metering, and application payload. State the observation layer before comparing totals.

Link headroom needs current observations

Divide the current full-wire bit rate by the link rate to estimate average utilization. The illustrative 60.9792 Mbps wire estimate uses about 6.1 percent of a decimal 1 Gbps line rate, but that example does not establish the service's present requirement.

The link can still experience microbursts and shared-queue contention. A 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. Sustained rate establishes cost. Burst percentiles establish queue and link headroom.

Buffer sizing converts rate into time

Under the illustrative 7,200,000 byte/sec payload rate, traffic arriving during a 10 ms pause is about 72,000 bytes. During 100 ms it is about 720,000 bytes. During 250 ms it is about 1,800,000 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

Continuous raw-packet storage includes payload plus record framing, timestamps, file-system blocks, indexes, checksums, replication, and capture format overhead. 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. Under the illustrative monthly packet count, even 16 bytes of per-packet metadata adds about 265.42 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 incoming traffic 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 internet price by a stale volume figure and call it total architecture cost.

Capture tools observe different byte counters

Interface RX byte and packet totals come from:

ip -s link show dev eth0

Driver and hardware statistics come from ethtool -S 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 the configured UDP port. Require each packet's source address to equal 203.23.178.228, then compare over one interval. Record counter definitions. Agreement within the expected layer overhead is evidence. Forced equality is not.

Bursts matter more than a long mean

Packet production follows slots and transaction load. Coding shreds add recovery traffic. A mean can remain stable while short peaks increase, and any observation window can miss a later traffic pattern.

Collect rolling bytes and packets over one-second, 100 ms, and 10 ms buckets without logging every datagram. For bucket rates, summarize the middle bucket, upper one percent, upper 0.1 percent, and observed peak. Provision socket queues and CPU from the short-window distribution.

Record each observation time and duration in internal capacity data. Compare current rolling rates with provisioned ceilings. Site copy should remain qualitative because the underlying rate changes.

Capacity planning needs failure headroom

Each destination receives the complete feed. Independent receiver sites, duplicate NIC paths, packet capture, and decoded storage add further copies.

Size links for feed bursts plus management, clock synchronization, telemetry, and recovery traffic. Give CPU capacity headroom above measured packet throughput, including injected scheduling pauses. Size storage with retention, metadata, filesystem reserve, and rebuild headroom. Size network billing by hop.

The production decision comes from current burst distributions and a documented overload policy. When capacity runs out, UDP drops rather than slowing the source. Recalculate from unrounded packet and byte counters whenever the observed rate changes.