search

Haivision / srt

Secure, Reliable, Transport
https://www.srtalliance.org
Mozilla Public License 2.0
3.11k stars 849 forks source link

[Statistics] The calculation of accumulated (Total) statistic is not necessary #1232

Open mbakholdina opened 4 years ago

mbakholdina commented 4 years ago

The calculation of accumulated (Total) statistic is not necessary. Ideally, we should delete the calculation of accumulated statistics and let people do this in the application by summing up the interval-based statistics.

In case we will decide to leave the calculation of accumulated statistics in the library, we should leave only one parameter in the structure (without Total), e.g., pktRcvLoss instead of two values pktRcvLoss and pktRcvLossTotal, and make a function with the argument return_total = 1 which will return either accumulated or interval-based statistics.

mbakholdina commented 4 years ago

Jean: Doing so may break existing applications and force an extra layer. Imagine an application with 2 threads getting stats(ex: NAE and U/I service), they would reset each other stats and both will be wrong. I don't see a big benefit of removing complexity from SRT lib to offload it to the application, unless I am missing something. I experienced something similar with MXD: summing stats over multiple reconnected SRT sockets (stats lost when socket destroyed) and it was not fun.

Maxim: That is a good point: two separate threads trying to retrieve the same stats. One workaround is the clear argument of the stats retrieval function: SRT_API int srt_bstats(SRTSOCKET u, SRT_TRACEBSTATS * perf, int clear); If clear=false, then the values keep accumulating.

A motivation for removal is to: Reduce extra memory usage for every socket (although not dramatically high). Simplify the API, because the CBytePerfMon is pretty large and self-repeating. Do not do what the application can easily do when needed, especially given that the Total stats are signed 32-bit integers, but should rather be unsigned 64-bit integers