Re: Understanding downloads and bandwidth Parts One and Two

110 views
Skip to first unread message

Nathan Kinkade

unread,
Jan 23, 2024, 12:32:05 PMJan 23
to Lefty, dis...@measurementlab.net

Mike,

Personally, I think you are being overly dismissive of Ookla, as well as fast.com. I'm not aware that any mainstream entity providing a throughput test is claiming to have all the answers, or that their test is the be-all-end-all of throughput tests. All the mainstream testing platforms I know of, including, for example, M-Lab, Ookla, Fast.com, Cloudflare, Comcast, etc., all test using different methodologies and from different network vantage points. They all provide valid and potentially interesting results. They all have potential flaws and/or answer different questions.

Best,

Nathan

On Tue, Jan 23, 2024 at 9:12 AM Lefty <le...@tcw.org> wrote:

Nathan,

It was a bit shocking to me, being that you work with M-Lab, that you would even mention speedtest.net or FAST.

I think that there remains a lot of unanswered questions regarding the viability and accuracy of M-Lab measurements versus SamKnows testing for example. (We will leave out any discussion of speedtest.net as they are not worth talking about).

I think there are a lot of unanswered questions about Internet testing in general as well.

M-Lab

 

SamKnows

 

I would welcome constructive input from any interested party at this point.

Thanks,

Mike

 

 

From: Nathan Kinkade [mailto:kin...@measurementlab.net]
Sent: Monday, January 22, 2024 4:57 PM
To: Lefty <le...@tcw.org>
Cc: sup...@measurementlab.net
Subject: Re: Understanding downloads and bandwidth Parts One and Two

 

Mike,

 

The questions you are asking are outside the scope of what M-Lab is able to help you with. We are a very small group of people working on a fairly large global deployment of measurement points. If you have reason to believe that some particular M-Lab measurement point is faulty or dramatically underperforming relative to other M-Lab measurement points, then we could try to debug whether there is something wrong with the M-Lab hardware or the circuit that might also be impacting measurements from other clients/networks. However, M-Lab isn't able to help you troubleshoot or substantiate your dispute/complaint with the service you are getting from your ISP.  If you think your case is general enough to be of interest to a larger community of people interested in network measurement (and not just bad or misrepresented ISP service), then you might consider posting to the dis...@measurementlab.net Google Group. However, from my initial read of your complaint/issue, I'm not necessarily sure it's relevant to that list.

 

Best,

 

Nathan

 

 

 

On Mon, Jan 22, 2024 at 3:45 PM Lefty <le...@tcw.org> wrote:

Nathan,

Let me try to respond to your response to my seeking (begging) for assistance (expertise) without coming off as condescending or rude.

The first question you ask is to me, irrelevant. You can see in my message that my ftp and http downloads are reasonable while on the Charter/Spectrum Intranet network.

It is when I actually get to the Internet backbone or IXP that the speeds drop dramatically.

You can also see on the trace routes the horrible latencies in my connections. 31-87ms.

The Ookla and Fast speed tests are in my view marketing devices, flawed in so, so, many ways, including excluded data, short test times unless modified, and a 200 mile range limit. The Cloudflare test runs 200 miles west to Minneapolis but again to a speedtest.net Charter/Spectrum server. It gives me a 340Mbps reading with a rating of Average for streaming and Poor for gaming. All for just $104.99 per month. <g>

I would not be asking these particular questions, if I hadn’t already been working with Charter/Spectrum for more than two years, across three gaming routers, eleven computers of six different form factors, four web browsers, and four operating systems on these issues. This includes thirteen visits by eight different Spectrum technicians and managers, and conversations at the Charter Operations VP and Primary Network Engineering levels.

Again if your read my message more carefully, I am looking for a possible explanation(s), and perhaps advice, and not necessarily a cure. It might not be fixable.

To that end, these links include new test data from first a Windows machine and then a Linux Mint one.

https://www.waveform.com/tools/bufferbloat?test-id=675d535e-c7d6-4816-a441-c03b432d2099

 

https://www.waveform.com/tools/bufferbloat?test-id=87bbc848-049a-41b9-aa9f-de1fb4bdfa28

 

And also an ongoing longer term test.

 

 

I would appreciate any assistance your group can provide,

Mike

 

 

 

From: Nathan Kinkade [mailto:kin...@measurementlab.net]
Sent: Monday, January 22, 2024 11:53 AM
To: Lefty <le...@tcw.org>
Cc: sup...@measurementlab.net
Subject: Re: Understanding downloads and bandwidth Part Two

 

Hi Mike,

 

This reply will pertain to both this email, as well as your previous "part one" email.

 

Let me start by replying to your questions with a question: is your concern that you are not getting 100% of the bitrate that Spectrum says your connection should support, or that the speeds you are getting are not sufficient to support the things you need to do on the connection they are providing?

 

I have not looked at the fine print of whatever contract you may have with Spectrum, but you can be nearly sure  that there is some clause in there that specifies that your speeds may or may not match the advertised speeds, depending on a whole slew of factors. Also, do you get 1Gbps when you test against other speed test sites like Ookla, or Spectrum's own speed test server/site, or fast.com or speed.cloudflare.com?

 

Even on a clean, wired, local network in which you are connected at 1Gbps, you will never achieve a 1Gbps throughput due to protocol overhead.

 

If you are not getting the speeds you think you should be getting, then this is really something you'd need to take up with your ISP. There is really nothing that M-Lab can do to help.

 

Best,

 

Nathan 

 

 

 

 

On Mon, Jan 22, 2024 at 9:31 AM Lefty <le...@tcw.org> wrote:

Support,

In my previous email, I showed some test results and traceroute data from my Charter/Spectrum Internet connection. Now I want to show you some more detailed info regarding local competitor routing for compare and contrast. Again I am looking for some assistance on how to understand just why my connection is so slow.

 

 

Charter/Spectrum routing paths

 

Comcast routing

 

AT&T (Ameritech) routing

 

I suspect based on the latencies displayed that Comcast and AT&T have fiber backbones and Charter/Spectrum does not. But does that explain the routing? Does that explain the lack of Mbps?

Is my connection bad because what they are selling me is a modified cable TV network connection?

 

Comments?

Thanks for any help,

Mike

 

Judah Richardson

unread,
Jan 23, 2024, 12:42:43 PMJan 23
to Nathan Kinkade, Lefty, dis...@measurementlab.net
FWIW, IMO DSLReports Speed test is the most comprehensive I know of in terms of producing a holistic view of connection performance: speed, latency, and bufferbloat http://www.dslreports.com/speedtest

More specifically, it's the only speed test I know of that tests for bufferbloat.

HTH,
Judah

--
You received this message because you are subscribed to the Google Groups "discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@measurementlab.net.
To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CANEqZDEHAn_ZL9b25H9ySVq2o5CzyRugT_gQL%2B%2BaEUTxdc0Opw%40mail.gmail.com.

Dave Taht

unread,
Jan 23, 2024, 1:19:00 PMJan 23
to Judah Richardson, Nathan Kinkade, Lefty, dis...@measurementlab.net
On Tue, Jan 23, 2024 at 12:42 PM Judah Richardson <judahri...@gmail.com> wrote:
FWIW, IMO DSLReports Speed test is the most comprehensive I know of in terms of producing a holistic view of connection performance: speed, latency, and bufferbloat http://www.dslreports.com/speedtest

More specifically, it's the only speed test I know of that tests for bufferbloat.


While dslreports does a good job of this (especially graphing the progression of it in their detailed graphs) the site has grown into disrepair over the last few years and rarely gets a correct result. They used to be my favorite tool for this.

Waveform is currently the best bufferbloat related website out there: https://www.waveform.com/tools/bufferbloat

Speedtest.net recently added some bufferbloat related reporting to its tests, but it does not track it over time and does not supply the max, but what looks to me like about the 75th percentile. It is quite amusing however, how some on-board speedtest gear (cough, starlink) elides that entirely. 

The new cloudflare test also tests for bloat and produces a nice whisker chart. At least some of that data is publicly available. speed.cloudflare.net

None of these tests test for the principal bufferbloat bugaboo I have, which is the behavior of a link with simultaneous up + down traffic, as the flent "rrul" test does. Thttps://blog.cerowrt.org/post/flaws_in_flent/he bufferbloat project operates a fleet of about 10 flent servers around the world to drive flent and irtt based tests. Please see: https://blog.cerowrt.org/post/flaws_in_flent/ . (We have been unable to secure sufficient donations to keep it running, however, and might have to decommission it in a month or two.) However flent and irtt are installable from nearly every OS and you can easily setup your own.  

There is a very nice new test called "crusader" that I like a lot: https://github.com/Zoxc/crusader/releases/tag/v0.0.10-testing
(I keep meaning to deploy this across the flent fleet). We are still trying to calibrate it against the flent rrul test suite, and it could use some love to one day do something more like the flent rtt_fair test. Big benefit from crusader is it is written in rust, and very portable. Big downside is we do not know enough about async operations with sockets as yet (so I do not trust the results in the rust vs the per-process implementation in the rrul), and I cannot write a line of rust myself (as yet). Love the plots and the staggered start tool in this!.

There has also been much progress on extending the goresponsiveness test from ippm and apple of late. I am opinionated as to where that test goes wrong (too many flows in slow start for one), but please see https://github.com/network-quality/goresponsiveness

iperf2 has also grown by leaps and bounds, if you pull the latest version.
 
Reply all
Reply to author
Forward
0 new messages