test over starlink #8
Comments
|
./udpst -4 -u fremont.starlink.taht.net |
|
Enabling ecn via -m 2 the speed difference is mostly because I ran this back to back with the previous test and starlink had given me 24mbit of bandwidth to play with. Bug: Doesn't track any transitions on the other side ./udpst -4 -m 2 -u fremont.starlink.taht.net ./udpst -4 -m 2 -d fremont.starlink.taht.net |
|
./udpst -4 -m 2 -u fremont.starlink.taht.net you can set ecn and have fq_codel set it, as for what effect it has, don't know. Looks real easy to see if A) the diffserv and ecn bits are preserved and b) if there's an ecn-enable AQM on the path. this is with the sqm-scripts set to 6mbit down and up to force fq_codel (cake in this case) to mark like crazy. It still remarkably gets the right bandwidth!!! ./udpst -4 -m 2 -u fremont.starlink.taht.net UDP Speed Test |
|
Hi Dave,
So, when the max capacity is achieved in the *last* sub-interval:
Sub-Interval10<sec>: 10, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 1/6/28, RTTVar(ms): 8-57, Mbps(L3/IP): 58.15
then this might also be a candidate to use the Type C algorithm, where we added enough dynamics to adapt to radio conditions (and other sources of instability). The Type C algorithm reaches higher sending rates faster than Type B, but Type B usually works well in the range of the rates you measured here, so it would be interesting to compare B and C.
I also see that the “fast” sending rate increase mode of Type B probably ended early in the test, with large delay variation reported:
Sub-Interval1<sec>: 1, Delivered(%): 99.84, Loss/OoO/Dup: 4/0/0, OWDVar(ms): 0/74/110, RTTVar(ms): 0-138, Mbps(L3/IP): 23.53
and the additional search was limited to 1Mbps adjustments every 50ms or so.
Al
From: Dave Täht ***@***.***>
Sent: Monday, October 31, 2022 11:55 PM
To: BroadbandForum/obudpst ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [BroadbandForum/obudpst] test over starlink (Issue #8)
this is 802.11n wifi on the laptop, running fq_codel, so it is bound by that on the download
***@***.***:~/git/obudpst$ ./udpst -4 -d fremont.starlink.taht.net
UDP Speed Test
Software Ver: 7.5.0, Protocol Ver: 9, Built: Oct 31 2022 20:39:49
Mode: Client, Payload Default[Max]: 1222[8972], Authentication: Available, SendMMsg(): Available
Downstream Test Int(sec): 10, DelayVar Thresh(ms): 30-90 [RTT], Trial Int(ms): 50, Ignore OoO/Dup: Disabled, Payload: zeroes,
SendRate Index: , Cong. Thresh: 3, High-Speed Delta: 10, SeqError Thresh: 10, Algo: B, IPv4 ToS: 0
Sub-Interval1<sec>: 1, Delivered(%): 99.84, Loss/OoO/Dup: 4/0/0, OWDVar(ms): 0/74/110, RTTVar(ms): 0-138, Mbps(L3/IP): 23.53
Sub-Interval2<sec>: 2, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/4/13, RTTVar(ms): 0-24, Mbps(L3/IP): 11.77
Sub-Interval3<sec>: 3, Delivered(%): 99.63, Loss/OoO/Dup: 10/0/0, OWDVar(ms): 1/22/77, RTTVar(ms): 2-86, Mbps(L3/IP): 23.60
Sub-Interval4<sec>: 4, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 1/14/76, RTTVar(ms): 8-100, Mbps(L3/IP): 32.09
Sub-Interval5<sec>: 5, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 1/29/88, RTTVar(ms): 8-95, Mbps(L3/IP): 43.26
Sub-Interval6<sec>: 6, Delivered(%): 81.91, Loss/OoO/Dup: 709/0/0, OWDVar(ms): 32/183/213, RTTVar(ms): 61-220, Mbps(L3/IP): 29.32
Sub-Interval7<sec>: 7, Delivered(%): 95.97, Loss/OoO/Dup: 155/0/0, OWDVar(ms): 1/81/201, RTTVar(ms): 5-215, Mbps(L3/IP): 31.88
Sub-Interval8<sec>: 8, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/4/13, RTTVar(ms): 7-39, Mbps(L3/IP): 33.36
Sub-Interval9<sec>: 9, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/4/11, RTTVar(ms): 5-41, Mbps(L3/IP): 47.37
Sub-Interval10<sec>: 10, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 1/6/28, RTTVar(ms): 8-57, Mbps(L3/IP): 58.15
Downstream Summary Delivered(%): 97.70, Loss/OoO/Dup: 878/0/0, OWDVar(ms): 0/42/213, RTTVar(ms): 0-220, Mbps(L3/IP): 33.43
Downstream Minimum One-Way Delay(ms): 47 [w/clock difference], Round-Trip Time(ms): 39
Downstream Maximum Mbps(L3/IP): 58.15, Mbps(L2/Eth): 58.85, Mbps(L1/Eth): 60.03, Mbps(L1/Eth+VLAN): 60.23
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/BroadbandForum/obudpst/issues/8__;!!BhdT!hDJykvNwMPHbE2o81Khqftzu-eE-4-j2_L5aqaYCc4HqQwUxXYUxl4XsRMw4wFxLE-6JKC3Bq_lQGBqKrDJxpQ$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACILYGHSHWVSUWMD3VBURDDWGCIARANCNFSM6AAAAAARTV5CXY__;!!BhdT!hDJykvNwMPHbE2o81Khqftzu-eE-4-j2_L5aqaYCc4HqQwUxXYUxl4XsRMw4wFxLE-6JKC3Bq_lQGBonWN_Wgw$>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>
|
|
Dave, |
|
ecn bit transitions, e.g. 2 - 3 |
|
I get it now! While we support packet marking, it’s a static capability. We don’t support ECN.
This is a Valid observation and Issue.
From: Dave Täht ***@***.***>
Sent: Wednesday, November 2, 2022 12:48 AM
To: BroadbandForum/obudpst ***@***.***>
Cc: MORTON JR., AL ***@***.***>; Comment ***@***.***>
Subject: Re: [BroadbandForum/obudpst] test over starlink (Issue #8)
ecn bit transitions, e.g. 2 - 3
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/BroadbandForum/obudpst/issues/8*issuecomment-1299563686__;Iw!!BhdT!l9bePSor7H0Ew8I37l_3Lg_Bcoq1JKppfQvit8kmwE0yXoSP0oCVsggtTEm6bDFIrPqrMR5qhfNntBaaciFlDA$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACILYGEOGXSBLTQNDEJT7MLWGHXBVANCNFSM6AAAAAARTV5CXY__;!!BhdT!l9bePSor7H0Ew8I37l_3Lg_Bcoq1JKppfQvit8kmwE0yXoSP0oCVsggtTEm6bDFIrPqrMR5qhfNntBbqPhkw6w$>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
|
Here is a packet capture of sch_cake set to 6Mbits with your "B" form of test, doing ecn marking: http://www.taht.net/~d/udptestecn.cap It would be really cool if wireshark could plot the behavior of this protocol. And even cooler if it could detect the use of ECN, and even the underlying AQM (fq_codel/cake are deterministic, pie and fq_pie are random) I'm still amazed (having not looked at the code) that it accurately finds the real bandwidth as well as it does, and as fast as it does. That said, it's painfully true (as discussed on the list) that bandwidth is fiddled with over time, and comes and goes rapidly over wireless transports. Here's some plots of tests of starlink from last year: https://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4PQKblM/edit And for a few laughs as to what happened next, see: https://www.youtube.com/watch?v=c9gLo6Xrwgw |
this is 802.11n wifi on the laptop, running fq_codel, so it is bound by that on the download
davet@milliways:~/git/obudpst$ ./udpst -4 -d fremont.starlink.taht.net
UDP Speed Test
Software Ver: 7.5.0, Protocol Ver: 9, Built: Oct 31 2022 20:39:49
Mode: Client, Payload Default[Max]: 1222[8972], Authentication: Available, SendMMsg(): Available
Downstream Test Int(sec): 10, DelayVar Thresh(ms): 30-90 [RTT], Trial Int(ms): 50, Ignore OoO/Dup: Disabled, Payload: zeroes,
SendRate Index: , Cong. Thresh: 3, High-Speed Delta: 10, SeqError Thresh: 10, Algo: B, IPv4 ToS: 0
Sub-Interval1: 1, Delivered(%): 99.84, Loss/OoO/Dup: 4/0/0, OWDVar(ms): 0/74/110, RTTVar(ms): 0-138, Mbps(L3/IP): 23.53
Sub-Interval2: 2, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/4/13, RTTVar(ms): 0-24, Mbps(L3/IP): 11.77
Sub-Interval3: 3, Delivered(%): 99.63, Loss/OoO/Dup: 10/0/0, OWDVar(ms): 1/22/77, RTTVar(ms): 2-86, Mbps(L3/IP): 23.60
Sub-Interval4: 4, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 1/14/76, RTTVar(ms): 8-100, Mbps(L3/IP): 32.09
Sub-Interval5: 5, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 1/29/88, RTTVar(ms): 8-95, Mbps(L3/IP): 43.26
Sub-Interval6: 6, Delivered(%): 81.91, Loss/OoO/Dup: 709/0/0, OWDVar(ms): 32/183/213, RTTVar(ms): 61-220, Mbps(L3/IP): 29.32
Sub-Interval7: 7, Delivered(%): 95.97, Loss/OoO/Dup: 155/0/0, OWDVar(ms): 1/81/201, RTTVar(ms): 5-215, Mbps(L3/IP): 31.88
Sub-Interval8: 8, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/4/13, RTTVar(ms): 7-39, Mbps(L3/IP): 33.36
Sub-Interval9: 9, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/4/11, RTTVar(ms): 5-41, Mbps(L3/IP): 47.37
Sub-Interval10: 10, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 1/6/28, RTTVar(ms): 8-57, Mbps(L3/IP): 58.15
Downstream Summary Delivered(%): 97.70, Loss/OoO/Dup: 878/0/0, OWDVar(ms): 0/42/213, RTTVar(ms): 0-220, Mbps(L3/IP): 33.43
Downstream Minimum One-Way Delay(ms): 47 [w/clock difference], Round-Trip Time(ms): 39
Downstream Maximum Mbps(L3/IP): 58.15, Mbps(L2/Eth): 58.85, Mbps(L1/Eth): 60.03, Mbps(L1/Eth+VLAN): 60.23
The text was updated successfully, but these errors were encountered: