How much network capacity does one destination need?

Measure bits and packets per second at the destination. Add IP, UDP, link, and tunnel overhead, then select headroom from short-window measurements on the intended path. A peak rate, burst duration, minimum rate, and required headroom multiplier are not currently specified.

How much data arrives in 30 days?

For a 30-day estimate, multiply mean payload bytes per second by 2,592,000. Under the worked 48 Mbps assumption, that equals 15.552 decimal TB. Customer storage needs more capacity for filesystems, indexes, metadata, replication, and backups. The product defines neither compression nor retention behavior.

Why can packets drop below the link's bandwidth limit?

Every packet creates CPU, queue, firewall, and scheduling work. A system can hit a packet-processing or socket-queue limit while aggregate Mbps remains below the nominal link rate. Use one observation window to compare interface, kernel, socket, and application counters, which locates the constraint.

Docs

Bandwidth requirements

This page lets you translate receiver traffic into capacity checks for one receiver path.

Before you start

Know the bandwidth limit of the public interface, virtual machine, firewall, and internal path.
Know whether the receiver stores every payload or processes it in memory.
Have access to network-interface and UDP-drop counters.

Start with receiver measurements

Measure packet rate, mean payload size, and short-window peaks at the destination. Feed traffic follows Solana network activity, so use values from a representative interval on the receiver path. Treat them as capacity inputs, not documented minimums, maximums, or availability guarantees. Peak rate, burst duration, and a required headroom factor are not currently specified.

Provision every component in the path, not only the nominal network link. A firewall, virtual network interface, packets-per-second quota, kernel queue, socket, application queue, decoder, or storage device can become the first bottleneck.

Calculate payload traffic

For this worked case, assume 5,000 packets arrive each second and their mean payload is 1,200 bytes. Calculate payload traffic as follows:

text

5,000 packets/second x 1,200 bytes/packet x 8 bits/byte= 48,000,000 bits/second= 48 Mbps using decimal megabits

This result describes UDP payload bits for the example assumptions. Replace both inputs with values measured at your receiver. IP, UDP, Ethernet, VLAN, tunnel, and other network overhead consume additional link capacity.

At the assumed 48 decimal megabits per second, the payload rate is 6 MB per second, 21.6 GB per hour, 518.4 GB per day, and 15.552 TB per 30 days.

Do not mix decimal network units with binary memory units without labeling the conversion. Firewall and cloud bandwidth displays may use different definitions.

Check packet-rate capacity

Bandwidth alone is insufficient. In the example, the receiver must handle 5,000 packets per second. Per-packet work such as allocation, logging, locking, checksums, queue operations, or context switches can limit throughput before the link is full.

Keep the socket reader small. Reuse buffers when the language and ownership model permit. Batch downstream operations when that preserves complete datagram boundaries. Perform decoding and storage on downstream workers.

No required CPU count, language runtime, queue depth, receive-buffer size, or batching policy is published. Benchmark the actual implementation on the intended host.

Measure the interface

Identify the receiving interface:

bash

ip -br link

Capture a first counter snapshot after replacing eth0 with that interface:

bash

ip -s link show dev eth0

Wait through an interval selected by your operating procedure, then repeat the command. Calculate byte, packet, drop, and error deltas. The product sets no mandatory observation duration.

When interface counters include unrelated traffic, capture only ${SOURCE_IP} and your destination port. Do not run a full payload dump at sustained rate.

Measure the socket and kernel

Record UDP receive counters at both ends of that interval. For a Linux host where net-tools is installed:

bash

netstat -su

Track received datagrams and receive errors. Exact commands and counter names vary across operating systems; the product mandates none.

Read the effective socket receive buffer through the receiver API. The kernel may cap or transform a request. No required size is published because capacity depends on burst behavior and scheduling pauses, which are likewise undefined.

Measure the application

Count accepted datagrams, accepted bytes, source rejections, queue drops, decoder failures, and processing delay. Report counters over fixed UTC windows. Avoid reporting only cumulative totals after a restart.

Compare application accepted packets with source-filtered capture counts and kernel receive counters. Differences locate loss between the network interface, kernel, socket, and application queue.

Do not count a malformed or undecodable payload as a network drop. Preserve separate delivery and decoding metrics.

Plan storage explicitly

Calculate raw storage from the byte rate observed at the destination before adding filesystem, index, replication, backup, and metadata overhead. A retention period, compression ratio, storage format, and historical replay feature are not currently specified.

Using the example assumptions, one day of raw UDP payloads is 518.4 GB in decimal units. Multiply your observed byte rate by the customer-selected retention period, then add the overhead of the chosen format and replication policy.

Do not assume that coding shreds, duplicate content, or protocol fields can be discarded unless the downstream use case and chosen Solana decoder explicitly permit it. The product delivers the raw feed and does not document server-side filtering.

Account for cloud limits and cost

Check both bits per second and packets per second on cloud instances, virtual NICs, load balancers, NAT gateways, firewalls, and network appliances. Some platforms tie network capacity to instance size or impose packet-processing limits below the advertised link rate.

Cloud ingress pricing, cross-zone charges, NAT processing fees, and storage cost depend on the customer's provider and are not product facts. Calculate them using the selected provider's current terms.

Avoid placing a TCP-only load balancer in the path. The delivery protocol is UDP, and a product-supported load-balancer configuration is not currently specified.

Choose headroom from measurements

There is no universal headroom percentage. Observe short-window peaks on the actual destination, record drop-free capacity, and choose a margin according to workload and loss tolerance. Recheck after enabling a tunnel, packet inspection, verbose logging, or downstream decoder.

Alert before queue or interface saturation. Exact alert thresholds, peak multipliers, and service-side rate envelopes are not currently specified.

Parameters

Name	Type	Default	Notes
assumed bit rate	decimal Mbps	48	Worked-example value, replace with the receiver measurement.
assumed packet rate	packets per second	5000	Worked-example value, replace with the receiver measurement.
assumed mean payload	bytes	1200	Worked-example value, not a fixed packet length.
example monthly payload volume	approximate decimal TB	15.552	Result from the worked assumptions before customer storage overhead.
required headroom factor	multiplier	not currently specified	Select from measurements on the customer path.

When it goes wrong

Interface drops increase. Example error: `RX dropped 18420`.

Cause. The virtual NIC, firewall, host, or driver cannot sustain the incoming bit or packet rate.

Fix. Compare path counters, remove avoidable per-packet work, and increase the constrained customer resource.

UDP receive errors rise while link utilization looks moderate. Example error: `packet receive errors: 7301`.

Cause. Packet-rate processing, socket buffering, or application scheduling is the bottleneck rather than link bits per second.

Fix. Shorten the receive loop, inspect effective buffers, benchmark packet handling, and add processing headroom.

Storage fills sooner than planned. Example error: `No space left on device`.

Cause. Planning omitted the calculated raw payload volume or customer format overhead.

Fix. Recalculate retention from receiver byte counts, include metadata and replication, and enforce the customer storage policy.

Questions

How much network capacity does one destination need?: Measure bits and packets per second at the destination. Add IP, UDP, link, and tunnel overhead, then select headroom from short-window measurements on the intended path. A peak rate, burst duration, minimum rate, and required headroom multiplier are not currently specified.
How much data arrives in 30 days?: For a 30-day estimate, multiply mean payload bytes per second by 2,592,000. Under the worked 48 Mbps assumption, that equals 15.552 decimal TB. Customer storage needs more capacity for filesystems, indexes, metadata, replication, and backups. The product defines neither compression nor retention behavior.
Why can packets drop below the link's bandwidth limit?: Every packet creates CPU, queue, firewall, and scheduling work. A system can hit a packet-processing or socket-queue limit while aggregate Mbps remains below the nominal link rate. Use one observation window to compare interface, kernel, socket, and application counters, which locates the constraint.