[Rpm] latest goresponsiveness test over starlink

[Sebastian Moeller]

Hi Wil,

(Sorry for misspelling your name earlier)

On 24 July 2022 08:31:18 CEST, Will Hawkins <hawkinsw at obs.cr> wrote:
>Great suggestions. I will continue to play with the UI. It looks like
>these conditions for timeout might be changing in future iterations of
>the spec, so I will keep my eye on how it progresses. 

Ah, guess I should re-read the spec then, without knowing the details I thibk getting away from strict run time limits seems a good idea.


Thanks again for
>the suggestions!
>Will
>
>PS: How do you like Starlink overall?

Me? I do not have/own/use starlink (can't afford it and can coose between VDSL2, DOCSIS3.1, and LTE/5G already all both considerably faster, less variable in speed and cheaper then starlink; so hard for me to justify the expense). That said, from the outside I think starlink (or LEO data transmission in general) is quite interesting.



>
>On Sat, Jul 23, 2022 at 11:38 PM Sebastian Moeller <moeller0 at gmx.de> wrote:
>>
>> Hi Will,
>>
>> Regarding my 'fat pipe' link, given that the current draft seems to recommend the 20 seconds, how about simply starting with that value, but on failure to achieve saturation do one of the following:
>> a) give a more detailed error message instructing the user to use the sattimeout option, maybe by printing the used command with '-sattimeout 60' or so added, so that simple copy and paste might allow the user to try again.
>> b) do not stop the code on this failure, but ask the user interactively whether to try again with a larger sattimeout value.
>>
>> Whether that will help in the starlink case I can only guess...
>>
>> Regards
>> Sebastian
>>
>> On 23 July 2022 23:19:28 CEST, Will Hawkins <hawkinsw at obs.cr> wrote:
>>>
>>> I am sorry that I am late to this thread. I would love to work
>>> together to see if there are some things that we could do to make the
>>> client more robust when someone uses it from "constrained" (to put it
>>> nicely) environments!
>>>
>>> Will
>>>
>>> On Fri, Jul 22, 2022 at 4:26 PM Sebastian Moeller via Rpm
>>> <rpm at lists.bufferbloat.net> wrote:
>>>>
>>>>
>>>>  Hi Dave,
>>>>
>>>>  maybe try:
>>>>
>>>>  time ./networkQuality --config mensura.cdn-apple.com --port 443 --path /api/v1/gm/config -extended-stats -sattimeout 60
>>>>
>>>>  to extend the maximal time to achieve saturation to a minute. I notice than of a fat path (1000/1000 Mbps) 20 seconds are not enough to achieve saturation, and maybe things take while on starlink as well?
>>>>
>>>>  Regards
>>>>          Sebastian
>>>>
>>>>
>>>>
>>>>
>>>>>  On Jul 22, 2022, at 21:00, Dave Taht via Rpm <rpm at lists.bufferbloat.net> wrote:
>>>>>
>>>>>  First attempt timed out. Second attempt...
>>>>>
>>>>>  ./networkQuality --config mensura.cdn-apple.com --port 443 --path
>>>>>  /api/v1/gm/config
>>>>>  07-22-2022 18:58:53 UTC Go Responsiveness to mensura.cdn-apple.com:443...
>>>>>  Download:  34.351 Mbps (  4.294 MBps), using 20 parallel connections.
>>>>>  Upload:     3.653 Mbps (  0.457 MBps), using 20 parallel connections.
>>>>>  RPM:   438
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>>  FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
>>>>>  Dave Täht CEO, TekLibre, LLC
>>>>> ________________________________
>>>>>  Rpm mailing list
>>>>>  Rpm at lists.bufferbloat.net
>>>>>  https://lists.bufferbloat.net/listinfo/rpm
>>>>
>>>> ________________________________
>>>>  Rpm mailing list
>>>>  Rpm at lists.bufferbloat.net
>>>>  https://lists.bufferbloat.net/listinfo/rpm
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.