revolutions per minute - a new metric for measuring responsiveness
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Frantisek Borsik <frantisek.borsik@gmail.com>
Cc: rpm@lists.bufferbloat.net
Subject: Re: [Rpm] My home connection - Prague, Czech Republic
Date: Fri, 27 May 2022 23:12:11 +0200	[thread overview]
Message-ID: <212012C5-158A-4589-ABD9-EE4E9B3AD0B4@gmx.de> (raw)
In-Reply-To: <CAJUtOOjmCr9YA+Zn40irTQG6eLrdwL2ajD5b4TEe-pnkL2pLwQ@mail.gmail.com>

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

Hi Frantisek,

sorry, was away for a day...

Thanks for testing, all of these tests show a pretty atrocious latency-under-load/working-conditions for the upload, indicating that this is unlikely the the peerings of your ISP. My guess is your access link and/or your modem or router. Could you describe your network set-up a bit and whether/what measures you took to counter bufferbloat?

Regards
	Sebastian


> On May 25, 2022, at 23:52, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
> 
> Hello Sebastian,
> 
> Thanks. Let’s do this. Kind of servers I see:
> 
> 
> 
> So picked a few:
> 
> https://www.speedtest.net/my-result/i/5129305856 (t-mobile cz)
> 
> https://www.speedtest.net/my-result/i/5129307905 (O2 telefonica cz)
> 
> https://www.speedtest.net/my-result/i/5129308857 (local ISP)
> 
> https://www.speedtest.net/my-result/i/5129310554 (Germany)
> 
> https://www.speedtest.net/my-result/i/5129311633
> (Poland)
> 
> 
> 
> 
> Sent on the move.
> 
> F.
> 
> https://www.linkedin.com/in/frantisekborsik
> 
> +421919416714
> Skype: casioa5302ca
> On 24 May 2022 at 9:44:25 AM, Sebastian Moeller (moeller0@gmx.de) wrote:
> 
>> Hi Frantisek, 
>> 
>> 
>> in the speedtest app, you can drag up a "drawer" from the bottom, which among others will reveal a "Change Test Server" "link" following that you can manually select from a multitude of servers, just selexct one that is unlikely to be housed by Cogent (like Vodafone.cz). Sure that still does not rule out that Cogent is in the network path*, but if you repeat the test with a few different servers and all show around the same high upload latency this would point to your access link/ISP being the likely responsible part. 
>> 
>> Regards 
>> Sebastian 
>> 
>> 
>> *) The best way to check a path requires both traceroute/mtr to and from the remote endpoint (or at least to/from the network/data center the remote end is housed in). Personally I like to use to following for the forward trace (from local to remote, here goggle's anycasted DNS server 8.8.8.8 as example): 
>> mtr -ezb4 -o LSNBAWVJMXI 8.8.8.8 
>> 
>> For the reverse traceroute/mtr either use a looking glas server (if the network offers these) or try to find a node in https://www.globaltraceroute.com that is housed in the correct network and location; this is a bit approximate, but what can we do, short of adding the traceroute/mtr functionality into the actual speedtest so it is always available. 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On May 24, 2022, at 09:31, Frantisek Borsik <frantisek.borsik@gmail.com> wrote: 
>>> 
>>> Hey, not sure how I can do this kind of testing :-) but if You tell me, I will do it, happily. 
>>> 
>>> F. 
>>> 
>>> https://www.linkedin.com/in/frantisekborsik 
>>> 
>>> +421919416714 
>>> Skype: casioa5302ca 
>>> 
>>> 
>>> 
>>> On Tue, May 24, 2022 at 9:09 AM Sebastian Moeller <moeller0@gmx.de> wrote: 
>>> Hi Frantisek, 
>>> 
>>> 
>>>> On May 24, 2022, at 06:41, Frantisek Borsik via Rpm <rpm@lists.bufferbloat.net> wrote: 
>>>> 
>>>> Good, good - most of the time. 
>>>> 
>>>> https://www.speedtest.net/my-result/i/5127045302 
>>> 
>>> This test is against fdcservers.net which appear to be single-homed in Cogent's network, do you see the same high upload latency under working conditions when measuring against servers in other networks (that are not connected via Cogent)? 
>>> 
>>> Regards 
>>> Sebastian 
>>> 
>>> P.S.: Not intended as dig against Cogent it is just that some ISP networks are known to have issues with connectivity with Cogent, so testing with servers in other networks can be a useful check. 
>>> 
>>> 
>>>> 
>>>> Sent on the move. 
>>>> 
>>>> F. 
>>>> 
>>>> https://www.linkedin.com/in/frantisekborsik 
>>>> 
>>>> +421919416714 
>>>> Skype: casioa5302ca 
>>>> _______________________________________________ 
>>>> Rpm mailing list 
>>>> Rpm@lists.bufferbloat.net 
>>>> https://lists.bufferbloat.net/listinfo/rpm 
>>> 
>> 


[-- Attachment #2.1: Type: text/html, Size: 5953 bytes --]

[-- Attachment #2.2: image.jpg --]
[-- Type: image/jpeg, Size: 184874 bytes --]

      reply	other threads:[~2022-05-27 21:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  4:41 Frantisek Borsik
2022-05-24  7:09 ` Sebastian Moeller
2022-05-24  7:31   ` Frantisek Borsik
2022-05-24  7:44     ` Sebastian Moeller
2022-05-25 21:52       ` Frantisek Borsik
2022-05-27 21:12         ` Sebastian Moeller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/rpm.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=212012C5-158A-4589-ABD9-EE4E9B3AD0B4@gmx.de \
    --to=moeller0@gmx.de \
    --cc=frantisek.borsik@gmail.com \
    --cc=rpm@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox