You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm testing the performance of srt-file-transmit , when I used the tc & netem tool to get an environment with 1% packet loss, I came across a "Floating point exception" with srt-file-transmit.
Related Info: SRT version : v1.4.0, Commit fe2858d OS : Client - Ubuntu 18.04 64bits, Server - Ubuntu 16.04 64btis Network : 1Gbps Lan NetEm command : tc qdisc add dev eth0 root netem loss 1% srt command : ./srt-file-transmit -s:1000 -pf:csv -statsout:statsnd.csv -logfile:log.txt -logfa:general file:///home/lzx/srt/4K2013.mp4 srt://10.48.40.251:7708
I used the netem command to set up the network and then used the srt command to send a file ~200MB. I exchange the client and server, and it made no difference.
The exception was located in "FileCC::slowdownSndPeriod", Line 497:
const int pktsInFlight = m_parent->RTT() / m_dPktSndPeriod;
const int numPktsLost = m_parent->sndLossLength();
const int lost_pcent_x10 = (numPktsLost * 1000) / pktsInFlight;
It supposed pktsInFlight wouldn't be 0, but actually the in this case, m_parent->RTT() kept decreasing and m_dPktSndPeriod kept increasing, then m_parent->RTT() < m_dPktSndPeriod and the FPE came out.
I insert some test code to show the process. RTT stands for m_parent->RTT() , PSP for m_dPktSndPeriod and loss size for losslist_size.
It looks a little weird because as i tried the same srt command in a real network with packet loss, everything seems all right. I tried to get the log file but only one-line connection information was logged.
I smell division by 0. Might even be that this pktsInFlight was the divisor. I don't know where these above logs come from, but if this pktsInFlight represents what is defined in congctl.cpp:495 line, this would definitely do it in this case:
const int lost_pcent_x10 = (numPktsLost * 1000) / pktsInFlight;
I modified slowdownSndPeriod() and generated the logs above , to see why pktsInFlight kept decreasing to zero, and it's excactly the pktsInFlight defined in congctl.cpp:495.
If it wouldn't affect the performance, #888 surely fix it.
Thanks for quick response!
Thanks; I wouldn't have quickly an env for testing it, just was 99.9% sure that this will exactly fix it. Therefore thanks for making it 100% certainty.
I'm testing the performance of srt-file-transmit , when I used the tc & netem tool to get an environment with 1% packet loss, I came across a "Floating point exception" with srt-file-transmit.
Related Info:
SRT version : v1.4.0, Commit fe2858d
OS : Client - Ubuntu 18.04 64bits, Server - Ubuntu 16.04 64btis
Network : 1Gbps Lan
NetEm command : tc qdisc add dev eth0 root netem loss 1%
srt command : ./srt-file-transmit -s:1000 -pf:csv -statsout:statsnd.csv -logfile:log.txt -logfa:general file:///home/lzx/srt/4K2013.mp4 srt://10.48.40.251:7708
I used the netem command to set up the network and then used the srt command to send a file ~200MB. I exchange the client and server, and it made no difference.
The exception was located in "FileCC::slowdownSndPeriod", Line 497:
It supposed pktsInFlight wouldn't be 0, but actually the in this case, m_parent->RTT() kept decreasing and m_dPktSndPeriod kept increasing, then m_parent->RTT() < m_dPktSndPeriod and the FPE came out.
I insert some test code to show the process. RTT stands for m_parent->RTT() , PSP for m_dPktSndPeriod and loss size for losslist_size.
It looks a little weird because as i tried the same srt command in a real network with packet loss, everything seems all right. I tried to get the log file but only one-line connection information was logged.
Any idea why the problem happened? Thanks!
The stats file was attached.
statsnd.zip
The text was updated successfully, but these errors were encountered: