Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reg: oheadbw parameter usage #638

Open
mks75 opened this issue Apr 10, 2019 · 22 comments

Comments

Projects
None yet
5 participants
@mks75
Copy link

commented Apr 10, 2019

Hi,
I am trying to limit the overhead bandwidth usage for srt transfer, so that in case of losses the correction bandwidth is not more than configured.
Regarding overhead bandwidth parameter (oheadbw) please let me know the following:
[1] What's the default value for oheadbw, if it's not specified by user?
[2] What are the minimum and maximum values for oheadbw parameter that can be assigned by user?
[3] Does this parameter needs to be assigned at both sender and receiver host?

Thanks
MKS

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented Apr 11, 2019

Hi @mks75,

  1. The default value is 25%. See SRTO_OHEADBW in API.md.
  2. 5..100
  3. Sender.
@mks75

This comment has been minimized.

Copy link
Author

commented Apr 11, 2019

Thanks @maxlovic ,
I am using srt v132 and sending an 8Mbps of stream and have set oheadbw=5.
During losses in the network, the sender rate increases to compensate for the losses and at some point it increases more than 30Mbps! With oheadbw set to 5%, the sender bitrate should limit to 8.4Mbps or so?

My sender command is:
./srt-live-transmit -s:1000 "udp://@239.1.1.1:1234" "srt://ip:port?mode=rendezvous&latency=4000&oheadbw=5&passphrase=passcode123

Am I missing some parameter here? Please advise.
Here's the sender log snapshot for your reference.

======= SRT STATS: sid=1042854671
PACKETS SENT: 1034 RECEIVED: 0
LOST PKT SENT: 33 RECEIVED: 0
REXMIT SENT: 33 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 8.52159 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5136 CONGESTION: 25600 FLIGHT: 51
LINK RTT: 93.577ms BANDWIDTH: 53.724Mb/s
BUFFERLEFT: SND: 12220500 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 1130 RECEIVED: 0
LOST PKT SENT: 131 RECEIVED: 0
REXMIT SENT: 128 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 9.35074 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5137 CONGESTION: 25600 FLIGHT: 56
LINK RTT: 116.854ms BANDWIDTH: 66.156Mb/s
BUFFERLEFT: SND: 12208500 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 1383 RECEIVED: 0
LOST PKT SENT: 400 RECEIVED: 0
REXMIT SENT: 400 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 11.4109 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5438 CONGESTION: 25600 FLIGHT: 366
LINK RTT: 113.003ms BANDWIDTH: 51.108Mb/s
BUFFERLEFT: SND: 11739000 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 1491 RECEIVED: 0
LOST PKT SENT: 477 RECEIVED: 0
REXMIT SENT: 477 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 12.3349 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5159 CONGESTION: 25600 FLIGHT: 81
LINK RTT: 110.495ms BANDWIDTH: 61.416Mb/s
BUFFERLEFT: SND: 12177000 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 2955 RECEIVED: 0
LOST PKT SENT: 1618 RECEIVED: 0
REXMIT SENT: 1992 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 24.3946 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5628 CONGESTION: 25600 FLIGHT: 730
LINK RTT: 128.215ms BANDWIDTH: 59.004Mb/s
BUFFERLEFT: SND: 11158500 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3648 RECEIVED: 0
LOST PKT SENT: 2064 RECEIVED: 0
REXMIT SENT: 3114 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.331 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 6216 CONGESTION: 25600 FLIGHT: 703
LINK RTT: 132.675ms BANDWIDTH: 60.084Mb/s
BUFFERLEFT: SND: 10509000 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3630 RECEIVED: 0
LOST PKT SENT: 956 RECEIVED: 0
REXMIT SENT: 3389 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.1706 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 6777 CONGESTION: 25600 FLIGHT: 532
LINK RTT: 133.126ms BANDWIDTH: 38.688Mb/s
BUFFERLEFT: SND: 9612000 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3687 RECEIVED: 0
LOST PKT SENT: 1460 RECEIVED: 0
REXMIT SENT: 3073 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.5734 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7063 CONGESTION: 25600 FLIGHT: 347
LINK RTT: 125.294ms BANDWIDTH: 42.828Mb/s
BUFFERLEFT: SND: 9196500 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3767 RECEIVED: 0
LOST PKT SENT: 1630 RECEIVED: 0
REXMIT SENT: 1930 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 31.34 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 6914 CONGESTION: 25600 FLIGHT: 1031
LINK RTT: 113.69ms BANDWIDTH: 63.36Mb/s
BUFFERLEFT: SND: 9535500 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3635 RECEIVED: 0
LOST PKT SENT: 1705 RECEIVED: 0
REXMIT SENT: 3402 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.0913 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7201 CONGESTION: 25600 FLIGHT: 597
LINK RTT: 116.394ms BANDWIDTH: 69.252Mb/s
BUFFERLEFT: SND: 9043500 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3690 RECEIVED: 0
LOST PKT SENT: 2276 RECEIVED: 0
REXMIT SENT: 2854 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.5688 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7133 CONGESTION: 25600 FLIGHT: 307
LINK RTT: 117.838ms BANDWIDTH: 32.364Mb/s
BUFFERLEFT: SND: 9000000 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3690 RECEIVED: 0
LOST PKT SENT: 2044 RECEIVED: 0
REXMIT SENT: 2735 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.599 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7333 CONGESTION: 25600 FLIGHT: 547
LINK RTT: 114.833ms BANDWIDTH: 57.264Mb/s
BUFFERLEFT: SND: 8812500 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3689 RECEIVED: 0
LOST PKT SENT: 1743 RECEIVED: 0
REXMIT SENT: 3082 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.4508 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7719 CONGESTION: 25600 FLIGHT: 504
LINK RTT: 117.126ms BANDWIDTH: 63.78Mb/s
BUFFERLEFT: SND: 8262000 RCV: 12286500
======= SRT STATS: sid=1042854671
PACKETS SENT: 3711 RECEIVED: 0
LOST PKT SENT: 2680 RECEIVED: 0
REXMIT SENT: 2892 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 30.654 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7780 CONGESTION: 25600 FLIGHT: 439
LINK RTT: 114.355ms BANDWIDTH: 58.176Mb/s
BUFFERLEFT: SND: 8098500 RCV: 12286500
14:32:05.069423/srt-live-transmE:SRT.d: SND-DROPPED 2 packets - lost delaying for 4021ms
14:32:05.079762/srt-live-transm
E:SRT.d: SND-DROPPED 7 packets - lost delaying for 4021ms
14:32:05.089950/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4021ms
14:32:05.100141/srt-live-transm
E:SRT.d: SND-DROPPED 8 packets - lost delaying for 4021ms
14:32:05.110274/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4021ms
14:32:05.120420/srt-live-transm
E:SRT.d: SND-DROPPED 7 packets - lost delaying for 4021ms
14:32:05.130547/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4021ms
14:32:05.140683/srt-live-transm
E:SRT.d: SND-DROPPED 8 packets - lost delaying for 4021ms
14:32:05.150830/srt-live-transmE:SRT.d: SND-DROPPED 7 packets - lost delaying for 4022ms
14:32:05.160961/srt-live-transm
E:SRT.d: SND-DROPPED 8 packets - lost delaying for 4022ms
.
.
.
.
.
14:32:05.966318/srt-live-transmE:SRT.d: SND-DROPPED 7 packets - lost delaying for 4022ms
14:32:05.976451/srt-live-transm
E:SRT.d: SND-DROPPED 4 packets - lost delaying for 4028ms
14:32:05.986582/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:05.996730/srt-live-transm
E:SRT.d: SND-DROPPED 7 packets - lost delaying for 4028ms
14:32:06.006868/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.017025/srt-live-transm
E:SRT.d: SND-DROPPED 7 packets - lost delaying for 4028ms
14:32:06.027171/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
======= SRT STATS: sid=1042854671
PACKETS SENT: 3663 RECEIVED: 0
LOST PKT SENT: 1441 RECEIVED: 0
REXMIT SENT: 3152 RECEIVED: 0
DROP PKT SENT: 595 RECEIVED: 0
RATE SENDING: 30.392 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 8117 CONGESTION: 25600 FLIGHT: 207
LINK RTT: 118.829ms BANDWIDTH: 57.6Mb/s
BUFFERLEFT: SND: 7695000 RCV: 12286500
14:32:06.037340/srt-live-transm
E:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.047472/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.057605/srt-live-transm
E:SRT.d: SND-DROPPED 7 packets - lost delaying for 4028ms
14:32:06.067754/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.077880/srt-live-transm
E:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.088006/srt-live-transmE:SRT.d: SND-DROPPED 7 packets - lost delaying for 4028ms
14:32:06.098189/srt-live-transm
E:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.108357/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.118563/srt-live-transm
E:SRT.d: SND-DROPPED 7 packets - lost delaying for 4028ms
14:32:06.128757/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.138920/srt-live-transm
E:SRT.d: SND-DROPPED 8 packets - lost delaying for 4028ms
14:32:06.149177/srt-live-transmE:SRT.d: SND-DROPPED 8 packets - lost delaying for 4029ms
14:32:06.159416/srt-live-transm
E:SRT.d: SND-DROPPED 7 packets - lost delaying for 4029ms

Thanks
MKS

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented Apr 12, 2019

As stated in the docs

SRTO_INPUTBW ... Used along with OHEADBW, when MAXBW is set to relative (0), to calculate maximum sending rate when recovery packets are sent along with main media stream (INPUTBW * (100 + OHEADBW) / 100). If INPUTBW is not set while MAXBW is set to relative (0), the actual input rate is evaluated inside the library.

As you don't set input_bw, the oheadbw=5 has no effect.
You should have something like: inputbw=1000000&oheadbw=5&maxbw=0

Very interesting, that you have

PACKETS SENT: 1130
LOST PKT SENT: 131

131 lost packets on 1130 sent packets. 12% loss rate.
Next, 28% loss rate:

PACKETS SENT: 1383 RECEIVED: 0
LOST PKT SENT: 400

Are you sure you have only 5% loss rate in your network?

@mks75

This comment has been minimized.

Copy link
Author

commented Apr 12, 2019

Thanks @maxlovic

The network is usually stable with less than 2% losses, but for the last few days the losses are high at times.
Moreover the network bandwidth is shared by other process, and I don't want the correction bandwidth to over subscribe the channel capacity.

I did some test on another network with 6Mbps stream and included parameters inputbw=750000&oheadbw=5&maxbw=0 and simulated losses by pushing more data on it. The test started with no packet loss, and during simulated error it started dropping the packets (as expected) and the correction bandwidth didn't increase much this time (as expected). But, after the simulated loss was stopped, the transfer should return to normal (as there is no congestion now), but it continued dropping the packets as it was doing during error and didn't recover (I waited for more than 15 minutes). The only way was to stop and restart the transfer.

Why the transfer didn't recover by itself? Please advise.

Sender logs snapshot:

[A] sender log (before error):

======= SRT STATS: sid=26444048
PACKETS SENT: 997 RECEIVED: 0
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.19267 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5914 CONGESTION: 25600 FLIGHT: 198
LINK RTT: 344.077ms BANDWIDTH: 44.076Mb/s
BUFFERLEFT: SND: 11985000 RCV: 12286500
======= SRT STATS: sid=26444048
PACKETS SENT: 998 RECEIVED: 0
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.20183 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5918 CONGESTION: 25600 FLIGHT: 205
LINK RTT: 343.808ms BANDWIDTH: 36.216Mb/s
BUFFERLEFT: SND: 11985000 RCV: 12286500
======= SRT STATS: sid=26444048
PACKETS SENT: 999 RECEIVED: 0
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.18637 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5911 CONGESTION: 25600 FLIGHT: 200
LINK RTT: 343.683ms BANDWIDTH: 39.78Mb/s
BUFFERLEFT: SND: 11985000 RCV: 12286500

[B] Sender log (during simulated error):

======= SRT STATS: sid=26444048
PACKETS SENT: 1116 RECEIVED: 0
LOST PKT SENT: 264 RECEIVED: 0
REXMIT SENT: 251 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.91044 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7313 CONGESTION: 25600 FLIGHT: 435
LINK RTT: 351.834ms BANDWIDTH: 20.484Mb/s
BUFFERLEFT: SND: 9778500 RCV: 12286500
======= SRT STATS: sid=26444048
PACKETS SENT: 1115 RECEIVED: 0
LOST PKT SENT: 239 RECEIVED: 0
REXMIT SENT: 251 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.90809 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7406 CONGESTION: 25600 FLIGHT: 319
LINK RTT: 353.342ms BANDWIDTH: 20.4Mb/s
BUFFERLEFT: SND: 9738000 RCV: 12286500
======= SRT STATS: sid=26444048
PACKETS SENT: 1121 RECEIVED: 0
LOST PKT SENT: 236 RECEIVED: 0
REXMIT SENT: 236 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.95855 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 7529 CONGESTION: 25600 FLIGHT: 353
LINK RTT: 354.419ms BANDWIDTH: 17.016Mb/s
BUFFERLEFT: SND: 9535500 RCV: 12286500
.
.
.

04:37:03.250944/srt-live-transmE:SRT.d: SND-DROPPED 5 packets - lost delaying for 4025ms
04:37:03.261139/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
04:37:03.271338/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
04:37:03.281526/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
04:37:03.291717/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
04:37:03.301892/srt-live-transm
E:SRT.d: SND-DROPPED 5 packets - lost delaying for 4025ms
04:37:03.312100/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
======= SRT STATS: sid=26444048
PACKETS SENT: 1206 RECEIVED: 0
LOST PKT SENT: 5 RECEIVED: 0
REXMIT SENT: 195 RECEIVED: 0
DROP PKT SENT: 998 RECEIVED: 0
RATE SENDING: 7.48741 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 8008 CONGESTION: 25600 FLIGHT: 27
LINK RTT: 354.742ms BANDWIDTH: 18.156Mb/s
BUFFERLEFT: SND: 8847000 RCV: 12286500
04:37:03.322324/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
04:37:03.332502/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
04:37:03.342707/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4025ms
04:37:03.352907/srt-live-transm*E:SRT.d: SND-DROPPED 5 packets - lost delaying for 4025ms

[C] Sender log (after test):

04:39:00.811936/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.822128/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.832305/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.842478/srt-live-transm
E:SRT.d: SND-DROPPED 5 packets - lost delaying for 4024ms
04:39:00.852657/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.862838/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.873013/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
======= SRT STATS: sid=26444048
PACKETS SENT: 1216 RECEIVED: 0
LOST PKT SENT: 5 RECEIVED: 0
REXMIT SENT: 242 RECEIVED: 0
DROP PKT SENT: 999 RECEIVED: 0
RATE SENDING: 7.55205 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 8008 CONGESTION: 25600 FLIGHT: 19
LINK RTT: 343.881ms BANDWIDTH: 43.5Mb/s
BUFFERLEFT: SND: 8847000 RCV: 12286500
04:39:00.883249/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.893434/srt-live-transmE:SRT.d: SND-DROPPED 5 packets - lost delaying for 4024ms
04:39:00.903626/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.913830/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.924029/srt-live-transm
E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.934173/srt-live-transmE:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms
04:39:00.944334/srt-live-transm
E:SRT.d: SND-DROPPED 5 packets - lost delaying for 4024ms
04:39:00.954526/srt-live-transm*E:SRT.d: SND-DROPPED 6 packets - lost delaying for 4024ms

Thanks
MKS

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented Apr 18, 2019

@mks75
Could you please collect wireshark captures from the receiver and sender? This might provide a hint.
Please note to start wireshark capture before initiating the SRT transmission to also capture the hand shacking SRT packets.

@maxlovic maxlovic added this to the v.1.3.3 milestone Apr 18, 2019

@ethouris

This comment has been minimized.

Copy link
Collaborator

commented Apr 18, 2019

And really appreciated if you collect also debug logs (-loglevel:debug). Redirect 2> to a file because it's really noisy. And compile with --enable-heavy-logging (option for configure).

@mks75

This comment has been minimized.

Copy link
Author

commented May 8, 2019

ok, I will try to capture the logs.

Regarding inputbw parameter, how accurate this value should be?
For a 6Mbps stream, should we set inputbw to exact 6Mbps or can use some higher value like 8Mbps? What effect will it have?
I have noticed the Sending Rate in stats is always higher than the value mentioned in inputbw - even if there are no Rexmit's. Why this happens?

Stats snapshot for 6Mbps stream:
======= SRT STATS: sid=253172978
PACKETS SENT: 994 RECEIVED: 0
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.18537 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5918 CONGESTION: 25600 FLIGHT: 37
LINK RTT: 55.577ms BANDWIDTH: 408.84Mb/s
BUFFERLEFT: SND: 12231000 RCV: 12286500
======= SRT STATS: sid=253172978
PACKETS SENT: 1003 RECEIVED: 0
LOST PKT SENT: 0 RECEIVED: 0
REXMIT SENT: 0 RECEIVED: 0
DROP PKT SENT: 0 RECEIVED: 0
RATE SENDING: 6.21528 RECEIVING: 0
BELATED RECEIVED: 0 AVG TIME: 0
REORDER DISTANCE: 0
WINDOW FLOW: 5918 CONGESTION: 25600 FLIGHT: 41
LINK RTT: 55.59ms BANDWIDTH: 199.32Mb/s
BUFFERLEFT: SND: 12225000 RCV: 12286500

Thanks
MKS

@alexpokotilo

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

Hi all,
we've faced with similar problem on 1.3.2 where sender generates huge traffic in case of probably packet loss between sender and receiver for LIVE streams. I'm not certain as we don't have logs and problem hardly and rarely reproduced. But we don't use SRTO_INPUTBW/SRTO_OHEADBW schema and rather use MAXBW set to absolute value(> 0). What is the difference between MAXBW and SRTO_INPUTBW/OHEADBW schemas ?
How do these methods work? What is the difference between them ? How each method works in case there is package losses.
According to https://github.com/Haivision/srt/blob/master/docs/API.md
SRT recommended value: 0 (relative) is preferred for SRTO_MAXBW
but there is no any clue in docs why it's preferred.

E.g
if we set these params
SRTO_MAXBW = 0
SRTO_INPUTBW = 250000
SRTO_OHEADBW = 25

or just set
SRTO_MAXBW = 312500

what do we have in both cases from SRT behavior POV ?

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

@alexpokotilo
When the following configuration is used, maxbw will be set to 1.25 * inputbw.
SRTO_MAXBW = 0
SRTO_INPUTBW = 250000
SRTO_OHEADBW = 25

Therefore both cases should behave the same way.

Have you tried the release 1.3.2 version or the latest one?

@jeandube

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

@alexpokotilo: The INPUTBW tells the payload rate (what the application submits to the SRT sender) while MAXBW tells the overall output rate including packets headers. Adjusting the output packet pace using INPUTBW is more convenient for most applications as the header sizes are not values readily available and the applications would also need to know the packets pattern to calculate MAXBW (how many pkts/sec for given Bps rate). The application can also set INPUTBW=0 to let SRT evaluate the input bit rate internally and adjust the output packet pace accordingly. But the internally measured rate lags behind the actual input rate and can cause accumulation in the sender' s buffer because the output packet pace is not adjusted fast enough in some case (for example when a motion video emerges from a black screen). An INPUTBW set lower than the actual input rate will have the same effect.

@alexpokotilo

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

@maxlovic,
we're testing on 1.3.2 but now realized that client doesn't set maxbw for all streams actually so probably we see bandwidth spikes just because or that.
If we find something I will file new ticket with appropriate details to reproduce.

@alexpokotilo

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

@maxlovic,
your last reply with simple maxbw = 1.25 * inputbw formula contradicts with @jeandube reply where
INPUTBW is input size without "header sizes". I don't get what is "header sizes" in this case. is it SRT headers or something like that ?

I'd especially appreciate you comment: "and the applications would also need to know the packets pattern to calculate MAXBW (how many pkts/sec for given Bps rate)".
In case of live stream an application usually sends 7*188 of mpegts packages. It's obvious that maxbw should be set according to this mpegts payload overhead. But what should it set for INPUTBW in this case?

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

@alexpokotilo maxbw should be set on the sending side. So if your client sends data, then most probably that is the reason of your reported behavior.

Regarding inputbw, this is the place where inputbw and maxbw are considered. As you can see, if m_llMaxBW is specified, it is passed to m_CongCtl->updateBandwidth(...), otherwise withOverhead(m_llInputBW) is passed. And here this value results into time interval between consequitive packets being sent.
I think what Jean meant is that if you specify the INPUTBW, SRT will add some overhead on top of that, to take into account UDP headers and possible retransmissions. But it you want to limit maximum utilized bandwidth, you should rather set maxbw.

@mks75

This comment has been minimized.

Copy link
Author

commented May 28, 2019

Hi,
In most of the cases, it's difficult to tell the input bandwidth of a stream, although CBR but it changes slightly. So, I am not sure that if we assign some inputbw value which differs from actual bandwidth - what impact it will have?
As per SRT technical overview document, I am using the 2nd option on the sender side.
inputbw=0
maxbw=0
oheadbw=10
This should allocate 10% overhead bandwidth on top of the actual calculated bit rate by SRT. But still during congestion conditions, I find the actual usage more than this calculation. I am not sure why?

image

Please let us know your views.
Thanks
MKS

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented May 29, 2019

@mks75 This mode (inputbw=0, maxbw=0) is tricky. We have it in our TODO list for review.
First thing, from my memory, it works about half a second with 30 Mbps bandwidth limit before being able to use the actual input bitrate for this. This input bitrate (feeding rate) depends on the rate of the abuve application to pass data to the library, and in case the sending buffer gets full, it will block srt_sendmsg, thus indirectly reducing the input bitrate. These all has to be taken into account when this mode is used.

Would you be able to, e.g. collect and share CSV statistics from the sender, it will provide an insight on what is happening in your case.

srt-live-transmit SRC DST -s:<bitrate/(8*1500)> -statsout:srtstats.csv -pf:csv
Use srt-live-transmit -help to get help.

@maxlovic maxlovic modified the milestones: v.1.3.3, v.1.3.4 May 29, 2019

@mks75

This comment has been minimized.

Copy link
Author

commented May 29, 2019

@maxlovic,
So which option do you recommend to effectively control the overhead bandwidth?

thanks
MKS

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented May 29, 2019

@mks75 If you know exactly what limit you want to have, then better to use just SRTO_MAXBW.

@alexpokotilo

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

Regarding inputbw, this is the place where inputbw and maxbw are considered. As you can see, if m_llMaxBW is specified, it is passed to m_CongCtl->updateBandwidth(...), otherwise withOverhead(m_llInputBW) is passed. And here this value results into time interval between consequitive packets being sent.

Still not clear. Let me provide and example and then ask a question.
Here is an example:
I have a stream with bandwidth from 1Mbps to 2Mbps. If I don't much care about latency but care about stable delivery so I set latency to 2000ms and MaxBW to 4Mbps/8 = 500000byte/s. I'm fine to double bitrate if necessary to re-transmit packages in case of losses on the wire.

Question is about "this value results into time interval between consequitive packets being sent". From my understanding MaxBW should influence on package delivery interval taking into account latency as well so we send packets with up to MaxBW speed but don't even try to send/re-transmit packets if they are out of latency interval. But in anyway we should never go beyond maxbw.
Am I right in that ? Thanks for patience BTW !

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented May 29, 2019

In short, if you set maxbw to 500000 byte/s, SRT will convert this into roughly (500000 / 1500)=333 packets/s. And then minimum allowed time between consecutive packets will be
106μs / 333 = 3 ms. Refer to this.

Now normally if you have 2 Mbps input, you will send one packet each 6 ms. Once you need to retransmit a packet, you can do this not earlier than in 3 ms, with the above maxbw specified.
Packet retransmissions have higher priority over regularly sent packets.

Latency joins the game at the receiving party, and does not influence the sending rate.

@alexpokotilo

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

Latency joins the game at the receiving party, and does not influence the sending rate.

I probably got it. so receiver just don't ask to retransmit packaged beyond latency interval

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented May 29, 2019

so receiver just don't ask to retransmit packaged beyond latency interval

Exactly. Both parties know the latency, so they know when they can stop trying to retransmit a lost packet.

@maxlovic

This comment has been minimized.

Copy link
Collaborator

commented May 30, 2019

Looks like the actual behavior in TSBPD mode is a bit different. Refer to #713.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.