Skip to content
shredstream.sh
Get a connection
All tools
Tool

Calculate shred-feed bandwidth

Convert packet rate and packet size into bits per second, packets per month, and 30-day storage with every unit shown.

Over what period

Sustained rate

54.3 Mbps

6.48 MiB/s payload

Decimal megabits, which is how transit is sold and how an interface counter reports.

Volume over 30 days
17.60 TB
16.01 TiB binary. Providers bill the first, disks report the second.
Packets over 30 days
14,476,320,000
Worth knowing if anything in your path charges or limits per packet.

These are payload bytes unless you add overhead. Solana's traffic is not constant: it moves with network activity, and a busy period runs meaningfully above the mean. Size links and budgets against the peak you are willing to survive, not the average you were quoted.

2 measured inputs reproduce the feed rate

The bandwidth calculator starts with packet rate and mean packet bytes. It returns payload bytes per second, decimal Mbps, binary MiB per second, packets over the selected period, decimal TB, binary TiB, and an optional link-layer overhead estimate.

Defaults come from the running relay measurement on 2026-08-31: 5,585 packets per second and 1,216 mean packet bytes. The published results are 54.3 Mbps and 17.6 TB over 30 days.

Method

Let p be packets per second, s be mean bytes per packet, and d be days.

text

bytes_per_second = p * s
bits_per_second = bytes_per_second * 8
Mbps = bits_per_second / 1,000,000

seconds = d * 86,400
period_packets = p * seconds
period_bytes = bytes_per_second * seconds
TB = period_bytes / 1,000,000,000,000
TiB = period_bytes / 1,099,511,627,776

Network Mbps uses decimal units. Storage TB also uses decimal units in the published product figure. TiB uses powers of two. The tool displays both labels and never calls them interchangeable.

Optional overhead is a scenario, not part of the measured payload figure:

text

wire_Mbps = p * (s + overhead_bytes_per_packet) * 8 / 1,000,000

The user selects IPv4 or IPv6 assumptions, VLAN tags, and tunnel bytes. The component lists every included header rather than supplying an unexplained percentage.

Worked example

Use 5,585 packets per second, 1,216 bytes, and 30 days.

text

bytes_per_second = 5,585 * 1,216
                 = 6,791,360

bits_per_second = 6,791,360 * 8
                = 54,330,880

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

Thirty days contains 2,592,000 seconds.

text

period_packets = 5,585 * 2,592,000
               = 14,476,320,000

period_bytes = 6,791,360 * 2,592,000
             = 17,603,205,120,000

TB = 17.60320512
   = 17.6 rounded to one decimal place

TiB = about 16.01

The arithmetic reproduces every published feed number from the two measured inputs. It also exposes the unrounded byte total for cloud billing and disk plans.

Add wire overhead carefully

Assume 1,216 is UDP payload over ordinary Ethernet and IPv4. One planning model adds 8 UDP bytes, 20 IPv4 bytes, 14 Ethernet header bytes, 4 frame-check bytes, 8 preamble bytes, and 12 inter-frame-gap bytes. That is 66 bytes of additional wire time per packet.

text

wire_bytes_per_packet = 1,216 + 66 = 1,282
wire_Mbps = 5,585 * 1,282 * 8 / 1,000,000
          = 57.27976 Mbps

This is an estimate at a named layer. Packet captures, interface counters, and provider bills may count different bytes. IPv6, VLANs, VPNs, and tunnels change the result.

Packet rate and byte rate size different systems

54.3 Mbps occupies a small fraction of a 1 Gbps link at the mean. 5,585 packets per second still drives receive calls, descriptors, interrupts, timestamps, queue entries, allocations, and decoder iterations.

One per-packet action repeats more than 14.47 billion times over 30 days. A 32-byte metadata record per packet adds about 463 GB decimal before database overhead. A log line per packet can become larger.

Use byte rate for link, storage, and transfer billing. Use packet rate for CPU, queue, interrupt, and metadata planning. Use short-window observed peaks for both.

Convert rate into a cost input

The output can pass 17.60320512 TB into the self-hosting or price comparator tools. Keep the full value for arithmetic and round only for display. A provider that bills decimal GB should receive 17,603.20512 GB under the payload assumption.

Cloud architecture can charge the same bytes more than once through a load balancer, cross-zone hop, packet mirror, object-store write, or replica. Draw each hop and apply its own rate. Incoming internet traffic being free does not make every downstream hop free.

Limitations

The defaults are measured means over one 5.6-hour window on 2026-08-31. They are not protocol maxima, future guarantees, or burst percentiles. Feed behavior changes with network load and protocol changes.

The monthly projection assumes a constant mean for every second of the selected period. Outages reduce received bytes. Higher future load increases them. Storage adds capture framing, timestamps, checksums, filesystem overhead, indexes, and replicas.

The overhead model depends on observation layer. Generic packet capture can omit physical framing. NIC offloads can affect host-visible counters. Cloud meters use provider definitions.

Validate the projection

Count accepted source datagrams and payload bytes over a fixed interval on the receiver. Divide bytes by elapsed seconds and packets by elapsed seconds, then compare those values with interface and application counters. Repeat over 10-millisecond, 100-millisecond, one-second, and longer windows where the instrumentation can keep up.

Keep mean, p95, p99, and maximum window rates. The monthly projection uses the long-window mean. Link, queue, and CPU headroom use the short-window distribution. Record the measurement date and packet layer so another operator can reproduce the conversion.

The calculator sizes quantities, not delivery quality. A link with enough mean capacity can still drop microbursts or face packet-per-second limits. Validate with short-window counters and production-like traffic.

How it works out the answer

Compute bytes_per_second = packets_per_second × mean_packet_bytes, bits_per_second = bytes_per_second × 8, and period_bytes = bytes_per_second × days × 86,400. Report Mbps and TB with decimal divisors, MiB/s and TiB with binary divisors, and optional wire overhead as packets_per_second × overhead_bytes × 8.

Questions

How does 5,585 packets per second become 54.3 Mbps?
Multiply 5,585 by the 1,216-byte measured mean to get 6,791,360 bytes per second. Multiply by eight for 54,330,880 bits per second, then divide by one million for 54.33088 Mbps. The published 54.3 Mbps is that result rounded to one decimal place.
Why does the calculator show both TB and TiB?
TB uses decimal trillions of bytes, while TiB uses powers of two. The same monthly total is 17.60320512 TB or about 16.01 TiB. Network and cloud billing commonly use decimal units, while operating-system storage tools may show binary values. Both labels prevent false disagreement.
Does 17.6 TB include packet-capture and filesystem overhead?
No. The figure follows measured packet bytes at the stated mean over 30 days. Capture record headers, timestamps, checksums, file allocation, indexes, replicas, and optional network headers add capacity. The tool can model named overhead, but the product figure remains the measured packet-byte calculation.