[Starlink] Hello List

[Starlink] Hello List

[tom]

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

Hi,

 

After a great tutorial on bufferbloat, David Taht invited me to join this
list, where I'm already learning a lot.

 

I'm retired from a long career, mainly in computer communications technology
and have extensive, although dated, experience with VoIP from the time when
I founded and ran VoIP wholesaler ITXC. Can't stop programming after 60
years so have been writing open-source Python (great language) shareware.
What's interested me are tools to measure network quality and especially
tools which Windows users can use since they are unlikely to curl, wget, and
sudo when all else fails. I was an early Starlink beta user - 13 months ago
- and am still running Starlink although now also have fiber.

 

During the late (I hope) pandemic the plight of rural people without
adequate broadband for teleconferencing was acute. I am hopeful Starlink
will be part of an answer and am both intrigued by its ease of deployment
and disappointed by its shortcomings. I am also afraid that the billions the
feds are pouring into "broadband" will not result in building the QoS people
need to prosper in the hybrid digital world. As all of you know, QoS is much
more than up and downlink speed and tough-to-quantify jitter is a huge part
of it. My measurement tool zoomready (at freecheckip.com
<http://freecheckip.com/>  and  https://github.com/tevslin/zoomready) makes
a more or less continuous measurement of jitter but is quite crude; so I'm
hoping to learn how to make that better and also how to calibrate zoomready
ratings with actual teleconferencing performance. Also would love to learn a
way from within the network to determine when obstacles like bufferbloat are
in the router and when they're in the ISP's network.

 

I also play with a Raspberry PI for more nerdy stuff but think I add more
value making tools available to less experienced users than digging deep
into the technologies where many are more knowledgeable than me.

 

I look forward to lurking on the list but will certainly respond to ideas.

 

Nice to meet you.

 

Tom

 

Tom Evslin

twitter: @tevslin <https://twitter.com/tevslin> 

blog: fractalsofchange.com <https://blog.tomevslin.com/> 

github: https://github.com/tevslin <https://github.com/tevslin> 

website: freecheckip.com <http://freecheckip.com/> 

 


[-- Attachment #2: Type: text/html, Size: 4706 bytes --]

Re: [Starlink] Hello List

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]


<tom@evslin.com> wrote:
    > need to prosper in the hybrid digital world. As all of you know, QoS is much
    > more than up and downlink speed and tough-to-quantify jitter is a huge part
    > of it. My measurement tool zoomready (at freecheckip.com
    > <http://freecheckip.com/>  and  https://github.com/tevslin/zoomready) makes
    > a more or less continuous measurement of jitter but is quite crude; so

I think that Apple/Stuart did a good job inverting the jitter metric, and calling it
Rounds/Revolutions per Minute.  I suggest doing the same in your tool.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 398 bytes --]

Re: [Starlink] Hello List

[Dave Täht]

On Wed, Mar 02, 2022 at 02:55:26PM -0500, Michael Richardson wrote:
> 
> <tom@evslin.com> wrote:
>     > need to prosper in the hybrid digital world. As all of you know, QoS is much
>     > more than up and downlink speed and tough-to-quantify jitter is a huge part
>     > of it. My measurement tool zoomready (at freecheckip.com
>     > <http://freecheckip.com/>  and  https://github.com/tevslin/zoomready) makes
>     > a more or less continuous measurement of jitter but is quite crude; so
> 
> I think that Apple/Stuart did a good job inverting the jitter metric, and calling it
> Rounds/Revolutions per Minute.  I suggest doing the same in your tool.

Except it's NOT a jitter metric. It is a latency under load metric primarily aime
at testing in-band (http 2.0 or quic) AQM latency. Most of our other tests
to date have a tendency to favor FQ measurements. 

Certainly jitter can be pulled out of detailed measurements using some
of the proposed methodologies. See the rpm@lists.bufferbloat.net list
an archives for more details.

We have a regular meeting on implementations and new data
at 10AM PDT tuesdays if anyone would like to join. 



> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 



> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Hello List

[Omer Shapira]

[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]



> On Mar 2, 2022, at 12:05 PM, Dave Täht <davet@teklibre.net> wrote:
> 
> 
> On Wed, Mar 02, 2022 at 02:55:26PM -0500, Michael Richardson wrote:
>> 
>> <tom@evslin.com <mailto:tom@evslin.com>> wrote:
>>> need to prosper in the hybrid digital world. As all of you know, QoS is much
>>> more than up and downlink speed and tough-to-quantify jitter is a huge part
>>> of it. My measurement tool zoomready (at freecheckip.com <http://freecheckip.com/>
>>> <http://freecheckip.com/ <http://freecheckip.com/>>  and  https://github.com/tevslin/zoomready <https://github.com/tevslin/zoomready>) makes
>>> a more or less continuous measurement of jitter but is quite crude; so
>> 
>> I think that Apple/Stuart did a good job inverting the jitter metric, and calling it
>> Rounds/Revolutions per Minute.  I suggest doing the same in your tool.
> 
> Except it's NOT a jitter metric. It is a latency under load metric primarily aime
> at testing in-band (http 2.0 or quic) AQM latency. Most of our other tests
> to date have a tendency to favor FQ measurements. 

Thanks Dave,

FWIW, the RPM metric is outlined in https://datatracker.ietf.org/doc/draft-ietf-ippm-responsiveness/ 

> 
> Certainly jitter can be pulled out of detailed measurements using some
> of the proposed methodologies. See the rpm@lists.bufferbloat.net <mailto:rpm@lists.bufferbloat.net> list
> an archives for more details.
> 
> We have a regular meeting on implementations and new data
> at 10AM PDT tuesdays if anyone would like to join. 
> 
> 
> 
>> 
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh networks [
>> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>> 
> 
> 
> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>

[-- Attachment #2: Type: text/html, Size: 18450 bytes --]