enum counter

Scope: rely

In header: #include <rely/counter.hpp>

Brief Description

The different performance counters available for Rely’s encoder and decoder. See Performance Counters section in the documentation for more information.

Values

Constant	Value	Description
counter::bytes_consumed		The number of bytes that have been consumed by either encoder::consume() or decoder::consume().
counter::bytes_produced		The number of bytes that have been produced by either encoder::produce_data() or decoder::produce_data().
counter::payloads_fragmented		The number of payloads that have been fragmented by the encoder. A payload passed to encoder::consumed() will be fragmented if its size plus the Rely header exceeds the max_packet_bytes configuration parameter passed to encoder::configure().
counter::payloads_consumed		The number of payloads that have been passed to encoder::consume().
counter::payloads_produced		The number of payloads that have been produced by decoder::produce_data(). Each payload will only be counted once although it can be read multiple times before moving to the next using decoder::produce_next().
counter::packets_produced		The number of packets that have been produced by encoder::produce_data(). Each packet will only be counted once although it can be read multiple times before moving to the next using encoder::produce_next().
counter::packets_consumed		The number of packets that have been consumed by decoder::consume().
counter::packets_lost		The number of lost packets sent from the encoder to the decoder. This is calculated based on the packet sequence number added by the encoder. This counter is only availble on the rely::decoder.
counter::packets_old		The number of packets that was too old to be useful. A packet is deemed too old if it contains symbols that are no longer part of the decoder’s stream.
counter::latest_sequence_number		The latest sequence number seen. The rely header includes a strictly increasing sequence number. The sequence number serves two purposes: It is used as the seed to the underlying RLNC (Random Linear Network Code), and it allows us to monitor the raw packet loss observed between the encoder and decoder. The encoder will increase the sequence number each time it generates a packet. On the decoder side the difference between two sequence numbers allows the losses currently observed on the network to be calculated.
counter::first_sequence_number		The first sequence number seen by the decoder.
counter::source_symbols_produced		The total number of source symbols produced. This counter has a different interpretation depending on whether we are looking at the encoder or the decoder: On the encoder, payloads are broken into one or more of source symbols (if fragmentation is needed). Since Rely uses systematic encoding each source symbol will be produced exactly once. On the decoder, source symbols are produced after decoding the incoming mix of source and repair symbols. The source symbols are then passed to defragmentation in order to obtain the original payloads encoded.
counter::source_symbols_triggered		The number of source symbols produced by the encoder which were triggered automatically by Rely.
counter::source_symbols_generated		The number of source symbols produced by the encoder which were generated manually by the user.
counter::source_symbols_expired		The number of expired source symbols. The difference between the source_symbols_consumed and source_symbols_expired is equal to the current coding window size.
counter::source_symbols_dropped		The number of source symbols dropped by the decoder. In some cases the decoder fail to recover source symbols, e.g., if they timeout or if the network packet loss increases beyond the repair rate.
counter::source_symbols_consumed		The source symbols consumed counter has encoder and decoder specific meaning: On the encoder it’s the number of source symbols added to the encoder as a result of fragmentation. If this number equals payloads_consumed it means that no fragmentation is occuring. On the decoder it’s the number of source symbols consumed by the decoder.
counter::repair_symbols_produced		The total number of repair symbols produced by the encoder.
counter::repair_symbols_triggered		The number of repair symbols produced by the encoder which were triggered automatically by Rely.
counter::repair_symbols_generated		The number of repair symbols produced by the encoder which were generated manually by the user.
counter::repair_symbols_consumed		The number of repair symbols consumed by the decoder.
counter::repair_count_expired		Sums the repair count for all expired source symbols. The repair count says how many repair packets a source symbols has been included in. The average repair count for the expired symbols can be calculated by dividing the repair_count_expired with source_symbols_expired. The average repair count can be compared to the repair_interval (if specified) to see if coding windows from different repair packets overlap.
counter::flush_on_expire		The number of flushes performed: On the encoder, a flush is performed when source symbols are expired but they have not been protected, i.e., the source symbols are still missing repair to sufficiently protected them against packet loss. In this case we flush the encoder to generate the needed repair and then remove them from the coding window. On the decoder a flush is performed when a source symbol fails to decode before expiring. In this case a flush is needed to “give up” decoding a specific source symbol and allow the release of subsequent source symbols. In cases where there is a steady flow of incoming payloads or packets, flushing will happen automatically as source symbols start to expire. However, in cases where there is no new incoming data it is necessary that the user manually implements flushing.
counter::stream_disconnected		The number of times the steam has been disconnected. The steam is said to be disconnected if the encoder is so far ahead of the decoder that their coding windows no longer overlap. When this happens any missing symbols in the coder can no longer be repaired. In this case Rely will move the decoder’s stream forward to catch up to the encoder. See Stream Disconnect.
counter::packets_reordered		The number of times a packet reordering is observed. This means that a packet was received where the sequence number is lower than the most recent sequence number seen.
counter::packets_duplicated		The number of times packets, with a previously seen sequence number, has been seen.
counter::unprotected_source_symbols_expired		The number of source symbols that have been dropped without repair.
counter::source_symbols_dropped_by_user		The number of source symbols dropped by the user, i.e., by calling decoder::catch_up().
counter::repair_symbols_linear_independent		The numer of linear independent repair symbols received.
counter::repair_symbols_linear_dependent		The number linear dependent repair symbols received. A linear dependent repair symbol did not help the decoder - although symbols were missing.
counter::source_symbols_linear_independent		The number of linear independent repair symbols received.
counter::source_symbols_linear_dependent		The number linear dependent source symbols received. A linear dependent source symbol did not help the decoder - although symbols were missing.
counter::repair_symbols_excess		The number of excess repair symbols received. A repair symbol received is counted as excess when no source symbols are currently missing release.
counter::source_symbols_excess		The number of excess source symbols received. A source symbol received is counted as excess when no source symbols are currently missing release.
counter::lower_bound_release		The number of lower bound release events. See Lower Bound Release