Bandwidth Management

When deploying an RTgms (SmartSockets with SmartPGM), there are two general approaches to rate control. The first approach, and the one recommended for SmartSockets customers, is to establish minimum and maximum rates, and assume RTclients will either keep up, or voluntarily drop out of the group. The second approach uses a technology within SmartPGM known as congestion control to automatically reduce the transmission rate to a level that can be handled by the slowest RTclient. Using congestion control is not generally recommended for SmartSockets customers who prioritize throughput over delivery.

Tuning Rate Control

By specifying the pgm_source_max_trans_rate and pgm_source_min_trans_rate, you can allocate the bandwidth necessary to send messages to subscribers promptly.

Verify that congestion control is turned off.

Verify that the desired rate of the RTgms alone, or in combination with other applications on the network, does not exceed the bandwidth limitations of the network itself.

Verify that the RTgms is located on a machine with a sufficient amount of RAM to maintain the recovery window (pgm_source_transmit_size_buffer * pgm_source_max_trans_rate) without needing to use virtual memory. When the RTgms is forced to access the hard-disk to facilitate loss repair, performance degrades significantly.

Rate Control and Loss

It is common for a RTclient to experience small amounts of non-uniform (random) loss during its lifetime. When a RTclient experiences loss it will send a negative acknowledgement (NAK), unless configured otherwise. It is the responsibility of the RTgms to process NAKs. If the RTgms is unable to service a NAK, for whatever reason, the RTclient will suffer un-recoverable loss and the link between it and the RTgms will be gracefully terminated.


	The most common cause of loss is setting the maximum send rate too high for the RTclients to sustain. If faced with persistent, unacceptable loss, first try reducing the value of the pgm_source_max_trans_rate.

Because SmartPGM is a reliable transport protocol, a RTgms makes recovering from loss the priority by default. When faced with loss, a RTgms will prioritize the transmission of repair data (RDATA) over the transmission of original data (ODATA). A consequence of loss in a single RTclient is the increased probability that latency will be introduced to all RTclients connected to same RTgms. As the amount of loss increases, the likelihood of latency also increases.


	A misconfigured RTclient can suffer catastrophic loss (at or near 100% loss). In most cases a RTclient suffering catastrophic loss will ultimately suffer un-recoverable loss and disconnect. However, in the time prior to disconnect the effects of catastrophic loss on latency can be significant. Its recommended that a policy be established by the user to prevent misconfigured, or rogue RTclients, from arbitrarily connecting to a RTgms.

A RTgms can be configured to reduce the likelihood that latency will be introduced in the presence of loss. pgm_source_transmit_rdata_max_percentage limits the bandwidth that an RTgms allocates for RDATA as a percent of pgm_source_max_trans_rate. pgm_source_transmit_rdata_max_percentage allows the user to shift the priority of SmartPGM from recovery to delivery.

Using pgm_source_max_trans_rate to shift the priority of SmartPGM from recovery to delivery increases the likelihood that a RTclient experiencing high loss will suffer un-recoverable loss and drop its connection to the RTgms. The decision to use pgm_source_max_trans_rate represents a trade-off between reliability and timely delivery.

Congestion Control

Using SmartPGM congestion control, RTgms regulates the transmission rate to accommodate the poorest performing RTclient in the multicast group. When an RTclient sends a negative acknowledgement (NAK), the RTgms reduces the transmission rate until the RTclient catches up and sends an acknowledgement (ACK). After receiving the ACK, the RTgms increases the rate to the specified maximum rate until the RTgms receives another NAK from an RTclient.