Documentation
RMS3(NB) Extreme Compression Protocol
Deploy RMS3(NB) for BTC and LTC and understand the up-to-99.6% public traffic reduction result, compatibility limits, tuning, and rollback.
RMS3(NB)
RMS3(NB) is an extreme-compression protocol for BTC and LTC mining-farm links. Under specific test conditions, it can reduce public-network traffic by up to 99.6%, making it useful for large sites, constrained uplinks, and expensive cross-region transport.
99.6%is a best result from a specific coin mix, connection scale, configuration, and test environment. It is not a fixed guarantee for every site. Validate production performance locally.
Compatibility Boundaries
- Supports
BTCandLTConly. - The RMS client must select
RMS3(NB). - The RustMinerSystem listener must also select
RMS3(NB). - It cannot connect to RMS3, RMS3(Zstd), or RMS2 listeners.
- Coin, port password, and synchronized compression options must match on both ends.
- Every target in a multi-address mapping must use the same coin and NB protocol.
Deployment
- Create a BTC or LTC RMS3(NB) proxy port in RustMinerSystem.
- Set its listener, upstream pool, password, and advanced compression options.
- Confirm the port is reachable from the mining site.
- Synchronize or manually add the matching RMS local port with RMS3(NB).
- Enter the same coin, password, and remote address.
- Begin with
3–6outbound connections for each local port. - Connect a small miner group and verify workers, hashrate, rejects, CPU, and traffic.
- Expand in batches and allow metrics to settle after each batch.
Why BTC and LTC Only
NB is specialized for the traffic shape of BTC/LTC mining links. Use RMS3 or RMS3(Zstd) for other coins; do not bypass the coin restriction by modifying configuration or mixing protocols.
Tuning Priority
- Prove the basic link and exact protocol match.
- Set compression to suit the RustMinerSystem server CPU.
- Adjust the outbound connection count per port.
- Observe CPU, network, rejects, and hashrate through a stable interval.
- Only then increase miner count or compression strength.
Too few outbound connections can add CPU and latency pressure; too many reduce consolidation. 3–6 is a starting point, not a universal optimum.
Acceptance Metrics
| Layer | Metrics |
|---|---|
| RMS | Inbound/outbound connections, CPU, memory, send/receive traffic, port state. |
| RustMinerSystem | Online workers, port hashrate, errors, and disconnect records. |
| Upstream pool | Hashrate curve, reject rate, latency, and revenue continuity. |
| Site uplink | Peak/average bandwidth, packet loss, jitter, and reconnections. |
Do not judge NB only by a traffic percentage. Hashrate, rejects, stability, and resource use must all pass before production approval.
Rollback
Keep a direct RustMinerSystem bypass address, the current RMS mapping and connection count, a RustMinerSystem port JSON backup, and the previous protocol parameters. During a major incident, first raise the outbound count or reduce compression. If instability remains, return the pilot miners to the bypass address. To change protocols, create a new matching pair of local and server ports instead of mixing an NB port with RMS3 or RMS3(Zstd).
