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
While testing the partial fix for #1648 (see PR #1650), I've encountered another possible issue.
Immediately after connection there are packet drops which are not expected. Here is the log from receiver. Wireshark dumps can be found here.
[haivision@big-flop _build]$ bin/srt-xtransmit receive srt://:4200 -v
11:41:15.199749 [D] SOCKET::SRT 0xAF329A0 (srt://:4200) Listening
11:41:15.199973 [D] SOCKET::SRT 0xAF329A0 (srt://:4200) ASYNC Waiting for incoming connection
11:41:18.433971 [D] SOCKET::SRT 0xAF329A0 (srt://:4200) Accepted connection 0xAF3299F
11:41:18.987026/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21130598 delayed for 0.064 ms
11:41:19.048094/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21130656 delayed for 0.094 ms
11:41:19.091233/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21130697 delayed for 0.085 ms
11:41:19.113340/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21130718 delayed for 0.094 ms
11:41:26.136976/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21137393 delayed for 0.063 ms
11:41:26.144371/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21137395 delayed for 5.354 ms
11:41:26.155402/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21137398 delayed for 13.228 ms
11:41:26.166384/SRT:TsbPd!W:SRT.br: RCV-DROPPED 1 packets, packet seqno 21137405 delayed for 16.844 ms
11:41:31.142593 [D] SOCKET::SRT 0xAF3299F read::recv ERROR 2001 Connection was broken
11:41:31.142660 [W] RECEIVE read::recv: Connection was broken
11:41:31.142688 [D] SOCKET::SRT 0xAF3299F Closing. Releasing epolls
11:41:31.142712 [D] SOCKET::SRT 0xAF3299F Closing
To Reproduce
See this comment for steps to reproduce the problem.
rtt=20ms, latency=default, packet loss=10%, packet burst up to 2 packets (packet loss on both ends)
srt-xtransmit app is used for evaluation, branch develop/jitter-trace-rsptime, Submodule path 'submodule/srt': checked out '019e1fd8bf13fd3d097813a5daba7c34f53225d8'
I am using big-flip (CentOS 7) / big-flop (CentOS 7) / small Lanforge setup.
The text was updated successfully, but these errors were encountered:
Drops happen because of the initial value of NAK period.
Loss report on 21130597 was sent once, retransmission was lost, and there was no more loss report for this packet, so after some time, the receiver dropped it.
Periodic NAK was sent only 150 ms after this loss report because the initial NAK interval is set to 300 ms.
Describe the bug
While testing the partial fix for #1648 (see PR #1650), I've encountered another possible issue.
Immediately after connection there are packet drops which are not expected. Here is the log from receiver. Wireshark dumps can be found here.
To Reproduce
See this comment for steps to reproduce the problem.
rtt=20ms, latency=default, packet loss=10%, packet burst up to 2 packets (packet loss on both ends)
srt-xtransmit
app is used for evaluation, branchdevelop/jitter-trace-rsptime
, Submodule path 'submodule/srt': checked out '019e1fd8bf13fd3d097813a5daba7c34f53225d8'I am using big-flip (CentOS 7) / big-flop (CentOS 7) / small Lanforge setup.
The text was updated successfully, but these errors were encountered: