Download sppeds desreprencies when running Speed test
223 views
Skip to first unread message
Paul Zahra
Apr 13, 2022, 12:38:01 PM4/13/22
to discuss
I noticed when I run your speed test at times the dpwnload speeds are much, much lower then when using OOkla, This moing test showed sub 1 MB , but OOKLA showed at least 40MB .Can you explain the possible differences? My connection does seem slow.
Thaks for any insight you can provide,
Regards,
Paul Zahra
Lai Yi Ohlsen
Apr 13, 2022, 6:15:43 PM4/13/22
to Paul Zahra, discuss
Hi Paul,
Additionally, any given test result is impacted by a number of factors, including the network management and topology of the path, the traffic on the network at the time of the test, and other environmental factors. One of the reasons M-Lab finds it so important to publish this data openly, is so we can study these factors in a more statistically rigorous way as part of a sample vs. in the one-off context of individual tests.
Thanks for your question. The simplest way to answer, is that M-Lab’s NDT and Ookla’s SpeedTest measure fundamentally different things. They differ in three key ways: 1. M-Lab measures to servers in off-net locations, Ookla measures to on-net locations. 2. NDT measures bulk transport capacity, SpeedTest attempts to measure link capacity and 3. NDT is a single stream test, SpeedTest is a multi-stream Here is a more in depth explanation of each characteristic:
1. Off-net vs. on-net measurement: All of M-Lab’s measurement services, including NDT, are hosted on our off-net platform. “On-net” refers to measurements performed on the same network as the network it is measuring, such as an Internet Service Provider (ISP) measuring itself. It only captures one segment of any path that data is likely to be traversing. In contrast, “off-net” measurements extend beyond a user’s access provider’s network to measure the complete path across the Internet from user to content including interconnections. By definition, on-net measurement can not even detect the effects of any performance limitations at interconnects between ISPs. All of the measurement services hosted by M-Lab inherit the off-net platform methodology for nearly all users.
2. Link capacity vs. bulk transport: When using NDT tests specifically, Internet users are sometimes confused when their individual results don’t confirm the speeds promised by their Internet service provider. “Speed” is often associated with “link capacity,” which is the maximum bitrate of a link; in other words, the best performance possible. However, NDT measures “bulk transport capacity” — the rate that TCP can deliver data across the end-to-end path; in other words, the reliability of that connection. It is important to note that many link problems (such as low level packet loss and reordering) typically adversely impact both MLab measurements and real application performance. These two ways of measuring performance, link capacity and bulk transport capacity, are different and are often conflated when both concepts are referred to as “Internet speed.” When using NDT data to discuss speed, it is important to clarify these terms to have more effective conversations about Internet speed.
3. Single-stream vs. multi-stream tests: NDT measures the single-stream performance of bulk transport capacity. While modern web browsers will use multiple streams of data, testing for multiple streams can compensate for data delivery problems that are exposed by a single stream. A multi-stream test can return measurements closer to link capacity but it would not represent the adverse performance impact of low-level packet loss. By testing for single-stream performance, NDT is an effective baseline for measuring a user’s Internet performance.
In short, NDT does not answer the question “how big is your pipe” but rather “how well is your pipe transferring data.” We consider both metrics to be important for understanding connectivity. For more reading, you can reference How fast is my Internet? Speed Tests, Accuracy, NDT & M-Lab which digs more into the definition of “speed” and NDT Data in NTIA Indicators of Broadband Need, which though focuses on the US federal mapping resource, helps describe the difference between the aggregated datasets for the purpose of research.
1. Off-net vs. on-net measurement: All of M-Lab’s measurement services, including NDT, are hosted on our off-net platform. “On-net” refers to measurements performed on the same network as the network it is measuring, such as an Internet Service Provider (ISP) measuring itself. It only captures one segment of any path that data is likely to be traversing. In contrast, “off-net” measurements extend beyond a user’s access provider’s network to measure the complete path across the Internet from user to content including interconnections. By definition, on-net measurement can not even detect the effects of any performance limitations at interconnects between ISPs. All of the measurement services hosted by M-Lab inherit the off-net platform methodology for nearly all users.
2. Link capacity vs. bulk transport: When using NDT tests specifically, Internet users are sometimes confused when their individual results don’t confirm the speeds promised by their Internet service provider. “Speed” is often associated with “link capacity,” which is the maximum bitrate of a link; in other words, the best performance possible. However, NDT measures “bulk transport capacity” — the rate that TCP can deliver data across the end-to-end path; in other words, the reliability of that connection. It is important to note that many link problems (such as low level packet loss and reordering) typically adversely impact both MLab measurements and real application performance. These two ways of measuring performance, link capacity and bulk transport capacity, are different and are often conflated when both concepts are referred to as “Internet speed.” When using NDT data to discuss speed, it is important to clarify these terms to have more effective conversations about Internet speed.
3. Single-stream vs. multi-stream tests: NDT measures the single-stream performance of bulk transport capacity. While modern web browsers will use multiple streams of data, testing for multiple streams can compensate for data delivery problems that are exposed by a single stream. A multi-stream test can return measurements closer to link capacity but it would not represent the adverse performance impact of low-level packet loss. By testing for single-stream performance, NDT is an effective baseline for measuring a user’s Internet performance.
In short, NDT does not answer the question “how big is your pipe” but rather “how well is your pipe transferring data.” We consider both metrics to be important for understanding connectivity. For more reading, you can reference How fast is my Internet? Speed Tests, Accuracy, NDT & M-Lab which digs more into the definition of “speed” and NDT Data in NTIA Indicators of Broadband Need, which though focuses on the US federal mapping resource, helps describe the difference between the aggregated datasets for the purpose of research.
Additionally, any given test result is impacted by a number of factors, including the network management and topology of the path, the traffic on the network at the time of the test, and other environmental factors. One of the reasons M-Lab finds it so important to publish this data openly, is so we can study these factors in a more statistically rigorous way as part of a sample vs. in the one-off context of individual tests.
I hope this answer addresses your question, but please let me know if I can explain anything further.
--
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/a609ce0e-7be6-4b4e-a231-227d7cd4106bn%40measurementlab.net.
Paul Zahra
Apr 13, 2022, 8:17:26 PM4/13/22
to Lai Yi Ohlsen, discuss
Thank you for this explanation, Very well explained and makes total sense to me now.
Regards,
Paul
Livingood, Jason
Apr 14, 2022, 1:03:11 PM4/14/22
to Lai Yi Ohlsen, discuss
Great explanation & summary of issues, Lai!
Semi-related: Since at root NDT is not a speed test, I hope one day Google will stop promoting NDT as the default recommended speed test when someone searches for “speed test” on their site. This IMO does a disservice to end users that are searching for an actual speed test that measures their aggregate link capacity. ;-)
Jason
To view this discussion on the web visit
https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAD3WrcMg5JOuFWy4Fd6G4CKnE3CQN0m0nWXCbCGoZg_S1vcuxw%40mail.gmail.com.
Lai Yi Ohlsen
Apr 14, 2022, 1:32:18 PM4/14/22
to Livingood, Jason, discuss
Hey Jason,
Glad you liked the summary and found it useful. Regarding the Google Search integration: the test volume generated by that integration is significant and it would be a great loss to the research community to see a decrease (of any size) in the amount of open Internet performance data that is made publicly available, especially when there are so few alternatives. That said, your point about service to the end user is well taken and as you might have noticed through our community calls, blog posts and public comments, we are interested in working with the M-Lab community to discern what information is most useful to provide to the end user inquiring about their connectivity and as part of that effort, expanding the notion of Internet performance beyond “speed”.
Happy to talk more offline! Take care.
-
Glad you liked the summary and found it useful. Regarding the Google Search integration: the test volume generated by that integration is significant and it would be a great loss to the research community to see a decrease (of any size) in the amount of open Internet performance data that is made publicly available, especially when there are so few alternatives. That said, your point about service to the end user is well taken and as you might have noticed through our community calls, blog posts and public comments, we are interested in working with the M-Lab community to discern what information is most useful to provide to the end user inquiring about their connectivity and as part of that effort, expanding the notion of Internet performance beyond “speed”.
Happy to talk more offline! Take care.
-
jpartr...@gmail.com
Apr 14, 2022, 5:41:23 PM4/14/22
to discuss, la...@measurementlab.net, discuss, jason_l...@comcast.com
To M-Lab's credit, you all have repeatedly acknowledged:
-"access link capacity is not what NDT measures"
-"Ookla's speedtest.net...{is} better suited for researchers looking to only measure the last-mile connection"
-ISP services "would be best measured by a multi-stream test"
-"NDT from M-Lab on the other hand, isn't intended to be a measurement of an Internet connection's maximum capacity"
-and now yesterday, "NDT does not answer the question how big is your pipe"
The problem is that many stakeholders, and the public at large, are misinterpreting and misrepresenting NDT data. Whether they are doing it naively, or willfully and maliciously, they are holding up NDT data as being indicative of performance that M-Lab has repeatedly stated it is not. And that is problematic! M-Lab would actually be assisting the research community by removing this misinformation, rather than simply issuing disclaiming caveats. As Sara Wedeman and David Clark noted in their paper, "In short, NDT was a diagnostic tool, not a measuring stick. The purpose was not to evaluate or compare residential broadband speeds delivered by ISPs, but rather to find and fix network problems." At another point they observed: "Our high-level conclusions {are} that these are not tests that reveal variation in the access technology, and computing a mean or median of these measurements will tell us nothing about the speed of the access link." And finally, Wedeman and Clark also observe: "The data from M-Lab is free and publicly available - and despite M-Lab’s cautionary messages on its Web site, M-Lab data can be, and has been used inappropriately on more than one occasion." As noted earlier, this is problematic!
Glenn Fishbine
Apr 14, 2022, 8:26:25 PM4/14/22
to jpartr...@gmail.com, discuss, la...@measurementlab.net, jason_l...@comcast.com
Just my 2 cents worth.
Before declaring that MLab is not a speed test, first you have to have agreement as to what a speed test is.
A speed test measures something. That something has a context usually related to usability for a purpose.
If the purpose is to determine the size of the pipe maybe MLab isn't the best choice.
If the purpose is to determine if a specific task can be accomplished, maybe Mlab is the best choice.
There is a clear difference on the type of speed test to be used if:
1. you want to know if you can stream Netflix 4k videos without buffering
2. If Johnny can get responses to his homework answers in less than 3 seconds.
3. If you can hold a video conference call on a service that has single port streaming.
I'm sure there are other answers, but it depends on what purpose you have in mind when you declare a speed test adequate, or not, for that purpose.
Let me point out that our dear friends at the FCC built Mlab into their mobil speed test, and further point out that their own research subsequently declared that MLab was a more than adequate test for their purposes in a way that was acceptable, albeit different, from Ookla, which was also acceptable.
To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/fdf7d530-20f0-41b4-b136-59b26ba45de2n%40measurementlab.net.
Ethan Katz-Bassett
Apr 14, 2022, 8:26:28 PM4/14/22
to Lai Yi Ohlsen, Paul Zahra, discuss
I think this is a great summary of key differences!
However, as an additional caveat in interpreting the data, it's not clear to me what off-net vs on-net measurements meaningfully represent in terms of "the complete path across the Internet from user to content." For many (probably most) Internet users, much (probably most) of their traffic comes either from an on-net Content Delivery Network (CDN) node or across a dedicated network interconnection to the content provider. So it's not clear to me that traffic crossing one or a few particular network interconnections between me and the assigned MLab server is a more meaningful measure of the performance I'd get to content than a measurement to an on-net server -- I suspect that neither exercises any interdomain interconnections that my traffic encounters when using YouTube, Netflix, Facebook, services hosted on the major cloud providers, services hosted on a number of widely-used CDNs, etc. If the NDT measurement is constrained by issues at the interconnection, the issues could apply to any services I use that happen to share that interconnection, but that's probably not the case for most services I use, and it requires a good amount of Internet measurement to understand which ones do share it.
Ethan
To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAD3WrcMg5JOuFWy4Fd6G4CKnE3CQN0m0nWXCbCGoZg_S1vcuxw%40mail.gmail.com.
Nick Feamster
Apr 15, 2022, 8:23:52 AM4/15/22
to discuss, etha...@gmail.com, pza...@logitech.com, discuss, la...@measurementlab.net
A few thoughts:
1. All of these tests are subject to severe sampling bias, particular under-representation of samples in communities where connectivity gaps are most dire. This I believe is a fundamental issue that is common across *all* of today’s methodologies. Client-based tests face severe sampling limitations; even the MBA program stratifies its sample by ISP and thereby severely undersamples most geographies, making it not very useful for many types of studies. See our TPRC paper for some initial discussion of these issues: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3786158
2. All of these tests are subject to various issues with client-based measurements, from WiFi bottlenecks to limitations of the radios on (old) client devices. A particular issue we discovered at one point was that many NDT tests on higher speed links were being performed from old iPhones whose radios did not support speeds of greater than 100 Mbps. In short, the NDT test was measuring the radio of the mobile device, not the ISP. See our CACM paper for more discussion on that. https://dl.acm.org/doi/pdf/10.1145/3372135
3. I am not sure it is accurate to say that NDT answers the question of “how well is you pipe transferring data”. A more precise statement would be that it measures the transfer rate across a single transport connection—at one point a fairly outmoded version of TCP, and now a single BBR stream. And so it might represent how well the connection transfers data across that transport, but it’s also worth pointing out that no modern application that seeks to maximize capacity relies on a single transport connection—everything from browsers to streaming clients on smart TVs use multiple parallel connections (some do so in rather extreme fashion, but that’s another topic).
4. Off-net measurements have their own caveats. One notable one—which came to light in none other than an M-Lab report!—was that as a result of an end-to-end path to an off-net server that crossed Cogent, the report mis-diagnosed the location of congestion (and its resolution). Cogent’s CEO also acknowledged this particular issue (read my FCC filing on the issue for more about that: https://www.fcc.gov/ecfs/file/download/DOC-578d040705800000-A.pdf).
5. To the point about the Google search “one box”—characterizing the loss of NDT measurements as a “great loss to the research community” presumes that “more data is better” and “open data is better"—independent of the *quality* of those measurements. But, I’d argue we need to rethink that. As Jim and Jason have both pointed out, the data has been actively misused and mischaracterized over many years—and this continues to happen. Part of the reason I believe this to be the case is the reason Lai Yi mentions: there are “so few alternatives”. It’s time to change that because regardless of the facts, people will take the path of least resistance. Casting it in the most charitable light—while some stakeholders may be willfully misrepresenting the data, I suspect others simply don’t have the time or interest in understanding the nuance that this group is familiar with. Taking shortcuts like that is sloppy and unscientific—something that has bothered me for quite some time—but I think some groups have gotten away with it because there’s little denying that there *are* gaps in infrastructure, connectivity, etc.—nevermind that the data itself doesn’t actually tell you much about the specific nature of any particular problem, people are happy to talk in broad strokes and handwave if the data conveniently speaks to an agenda. But now, as we think about actually *solving* problems, this becomes a more serious problem—the existing tools and methods—measurement techniques, data, sampling approaches—do very little in helping anyone actually work towards fixing these problems. I believe that’s where we should be turning our focus in the next 5-10 years.
1. All of these tests are subject to severe sampling bias, particular under-representation of samples in communities where connectivity gaps are most dire. This I believe is a fundamental issue that is common across *all* of today’s methodologies. Client-based tests face severe sampling limitations; even the MBA program stratifies its sample by ISP and thereby severely undersamples most geographies, making it not very useful for many types of studies. See our TPRC paper for some initial discussion of these issues: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3786158
2. All of these tests are subject to various issues with client-based measurements, from WiFi bottlenecks to limitations of the radios on (old) client devices. A particular issue we discovered at one point was that many NDT tests on higher speed links were being performed from old iPhones whose radios did not support speeds of greater than 100 Mbps. In short, the NDT test was measuring the radio of the mobile device, not the ISP. See our CACM paper for more discussion on that. https://dl.acm.org/doi/pdf/10.1145/3372135
3. I am not sure it is accurate to say that NDT answers the question of “how well is you pipe transferring data”. A more precise statement would be that it measures the transfer rate across a single transport connection—at one point a fairly outmoded version of TCP, and now a single BBR stream. And so it might represent how well the connection transfers data across that transport, but it’s also worth pointing out that no modern application that seeks to maximize capacity relies on a single transport connection—everything from browsers to streaming clients on smart TVs use multiple parallel connections (some do so in rather extreme fashion, but that’s another topic).
4. Off-net measurements have their own caveats. One notable one—which came to light in none other than an M-Lab report!—was that as a result of an end-to-end path to an off-net server that crossed Cogent, the report mis-diagnosed the location of congestion (and its resolution). Cogent’s CEO also acknowledged this particular issue (read my FCC filing on the issue for more about that: https://www.fcc.gov/ecfs/file/download/DOC-578d040705800000-A.pdf).
5. To the point about the Google search “one box”—characterizing the loss of NDT measurements as a “great loss to the research community” presumes that “more data is better” and “open data is better"—independent of the *quality* of those measurements. But, I’d argue we need to rethink that. As Jim and Jason have both pointed out, the data has been actively misused and mischaracterized over many years—and this continues to happen. Part of the reason I believe this to be the case is the reason Lai Yi mentions: there are “so few alternatives”. It’s time to change that because regardless of the facts, people will take the path of least resistance. Casting it in the most charitable light—while some stakeholders may be willfully misrepresenting the data, I suspect others simply don’t have the time or interest in understanding the nuance that this group is familiar with. Taking shortcuts like that is sloppy and unscientific—something that has bothered me for quite some time—but I think some groups have gotten away with it because there’s little denying that there *are* gaps in infrastructure, connectivity, etc.—nevermind that the data itself doesn’t actually tell you much about the specific nature of any particular problem, people are happy to talk in broad strokes and handwave if the data conveniently speaks to an agenda. But now, as we think about actually *solving* problems, this becomes a more serious problem—the existing tools and methods—measurement techniques, data, sampling approaches—do very little in helping anyone actually work towards fixing these problems. I believe that’s where we should be turning our focus in the next 5-10 years.
Lai Yi Ohlsen
Apr 15, 2022, 9:41:23 AM4/15/22
to Nick Feamster, discuss, etha...@gmail.com, pza...@logitech.com
Hi everyone,
Thank you all for your thoughtful notes. It’s evident that there are a number of shared goals, the most prominent being to use data to improve Internet performance for end users. More specifically, I agree with the latter parts of Nick’s last statement about the need for measurements that help end users and their public representatives actually solve problems. M-Lab is also keen to make progress here.
There’s a lot of details here that we could go back and forth on but I’m curious how we can channel the obvious energy on these topics into actionable, consensus-driven plans. Afterall, our shared goals are not small :) and would only benefit from a cooperative approach. Would the folks in this thread (including anyone following along) be interested in participating in a working group focused on these topics (e.g. “speed” tests, network topologies, data collection methodologies etc.) and supporting M-Lab’s efforts to contribute here?
Please let me know if so! A reply to this email works great.
As/If the thread continues, I'll insert a gentle reminder of our community guidelines. Take care all.
Thank you all for your thoughtful notes. It’s evident that there are a number of shared goals, the most prominent being to use data to improve Internet performance for end users. More specifically, I agree with the latter parts of Nick’s last statement about the need for measurements that help end users and their public representatives actually solve problems. M-Lab is also keen to make progress here.
There’s a lot of details here that we could go back and forth on but I’m curious how we can channel the obvious energy on these topics into actionable, consensus-driven plans. Afterall, our shared goals are not small :) and would only benefit from a cooperative approach. Would the folks in this thread (including anyone following along) be interested in participating in a working group focused on these topics (e.g. “speed” tests, network topologies, data collection methodologies etc.) and supporting M-Lab’s efforts to contribute here?
Please let me know if so! A reply to this email works great.
As/If the thread continues, I'll insert a gentle reminder of our community guidelines. Take care all.
Livingood, Jason
Apr 15, 2022, 12:10:49 PM4/15/22
to Lai Yi Ohlsen, discuss
Good idea on channeling energy towards a constructive activity – I’d suggest considering adding a speed test (aggregate capacity) to the M-Labs platform. This could potentially leverage some of the open source tests out there or new standards such as https://datatracker.ietf.org/doc/html/draft-ietf-ippm-capacity-protocol.
It is worth bearing in mind that my concern over (mis)use & (mis)representation of NDT data is not theoretical. There are tens of billions of dollars of public grant money in the United States that will be spent over the next few years to build Internet connectivity to areas that are currently unserved. I have observed instances of grant decision-makers being told in public meetings which areas have no service based on the purported results of NDT “speed tests” and of grant applicants using NDT “speed tests” to show where broadband is not available or suggesting NDT “speed tests” can be used after the fact to confirm that the new address is receiving broadband service.
Jason
From: Lai Yi Ohlsen <la...@measurementlab.net>
Date: Friday, April 15, 2022 at 09:41
To: Nick Feamster <feam...@gmail.com>
Cc: discuss <dis...@measurementlab.net>, "etha...@gmail.com" <etha...@gmail.com>, "pza...@logitech.com" <pza...@logitech.com>
Subject: [EXTERNAL] Re: [M-Lab-Discuss] Download sppeds desreprencies when running Speed test
Hi everyone,
To view this discussion on the web visit
https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAD3WrcMm0_4h4k1s%3D8%3D5smXzC4gCNxP3Za9qND%2BCNgWz9s6_7A%40mail.gmail.com.
Paul Zahra
Apr 15, 2022, 12:10:52 PM4/15/22
to Lai Yi Ohlsen, Nick Feamster, discuss, etha...@gmail.com
Hello Lai and Group,
Just some more info on my exploits here. I continued to see the differences in Speed test results yesterday. I decided to reboot my router and the speed test results changed to where NDT and OOKLA are measuring the same fast speeds . 50MB.
Woke up this morning and ran the tests and again, speed differences showed up sub 1MB and 50MB, rebooted and then the speeds were the same again > 50MB.
Regards,
Paul
rjmcmahon
Apr 15, 2022, 1:28:20 PM4/15/22
to Paul Zahra, Lai Yi Ohlsen, Nick Feamster, discuss, etha...@gmail.com
A few thoughts from somebody testing WiFi chips for over a decade now
and someone maintaining iperf 2.
On Latency: is not the same as RTT or ping. We've added one-way delay in
iperf 2. It does require synchronized clocks. We measure packet times,
write to read times, et.. GPS atomic time is quite accurate.
On actionable engineering: For sure end/end is interesting but defining
key telemetry on the sub-graphs seems required. Interesting nodes are
things like wired to wireless and last-mile *peering points* to end-user
device. It seems like "on-net" should include servers at the peering
points used by the major content providers vs optimizing the last mile
only. A flight to a major hub for an airline matters more than a
southwest flight between Austin and Dallas. These hubs are critical to
flight times (and to flight delays.)
The measurement institution(s) have to be at arms length.
Bob
>> community guidelines [1]. Take care all.
>> In short, NDT does not answer the question “how big is yourA few
>> notes.
On LLatency is not the same as RTT or ping. We've added one way delay in
iperf 2. It does require synchronized clocks.
>> pipe” but rather “how well is your pipe transferring data.” We
>> consider both metrics to be important for understanding
>> connectivity. For more reading, you can reference How fast is my
>> Internet? Speed Tests, Accuracy, NDT & M-Lab [2] which digs more
>> [4].
>>
>> --
>>
>> Lai Yi Ohlsen
>>
>> Director, Measurement Lab [5]
>> Code for Science & Society [6]
On LLatency is not the same as RTT or ping. We've added one way delay in
iperf 2. It does require synchronized clocks.
>>
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAD3WrcMg5JOuFWy4Fd6G4CKnE3CQN0m0nWXCbCGoZg_S1vcuxw%40mail.gmail.com
>> [7].
>
> --
>
> Lai Yi OhlsenA few notes.
On LLatency is not the same as RTT or ping. We've added one way delay in
iperf 2. It does require synchronized clocks.
>
> Director, Measurement Lab [5]
> Code for Science & Society [6]
> [8].
>
>
> Links:
> ------
> [1] https://www.measurementlab.net/community-guidelines/
> [2]
> https://www.measurementlab.net/blog/speed-tests-accuracy/#how-fast-is-my-internet?-speed-tests,-accuracy,-ndt-&-m-lab
> [3]
> https://www.measurementlab.net/blog/ntia/#ndt-data-in-ntia-indicators-of-broadband-need
> [4]
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/a609ce0e-7be6-4b4e-a231-227d7cd4106bn%40measurementlab.net?utm_medium=email&utm_source=footer
> [5] http://www.measurementlab.net
> [6] https://codeforscience.org/
> [7]
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAD3WrcMg5JOuFWy4Fd6G4CKnE3CQN0m0nWXCbCGoZg_S1vcuxw%40mail.gmail.com?utm_medium=email&utm_source=footer
> [8]
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAK0jp%2B-rE_c6oPASz4D5gdBBaac-WP71eXgD_D_k_CuTHeqRpA%40mail.gmail.com?utm_medium=email&utm_source=footer
and someone maintaining iperf 2.
On Latency: is not the same as RTT or ping. We've added one-way delay in
iperf 2. It does require synchronized clocks. We measure packet times,
write to read times, et.. GPS atomic time is quite accurate.
On actionable engineering: For sure end/end is interesting but defining
key telemetry on the sub-graphs seems required. Interesting nodes are
things like wired to wireless and last-mile *peering points* to end-user
device. It seems like "on-net" should include servers at the peering
points used by the major content providers vs optimizing the last mile
only. A flight to a major hub for an airline matters more than a
southwest flight between Austin and Dallas. These hubs are critical to
flight times (and to flight delays.)
The measurement institution(s) have to be at arms length.
Bob
>> notes.
On LLatency is not the same as RTT or ping. We've added one way delay in
iperf 2. It does require synchronized clocks.
>> pipe” but rather “how well is your pipe transferring data.” We
>> consider both metrics to be important for understanding
>> connectivity. For more reading, you can reference How fast is my
>> into the definition of “speed” and NDT Data in NTIA Indicators
>> of Broadband Need [3], which though focuses on the US federal
>>
>> --
>>
>> Lai Yi Ohlsen
>>
>> Director, Measurement Lab [5]
>> Code for Science & Society [6]
>>
>> --
>> 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 visitA few notes.
>> --
>> 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.
>
On LLatency is not the same as RTT or ping. We've added one way delay in
iperf 2. It does require synchronized clocks.
>>
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAD3WrcMg5JOuFWy4Fd6G4CKnE3CQN0m0nWXCbCGoZg_S1vcuxw%40mail.gmail.com
>> [7].
>
> --
>
> Lai Yi OhlsenA few notes.
On LLatency is not the same as RTT or ping. We've added one way delay in
iperf 2. It does require synchronized clocks.
>
> Director, Measurement Lab [5]
> Code for Science & Society [6]
>
> --
> 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/CAK0jp%2B-rE_c6oPASz4D5gdBBaac-WP71eXgD_D_k_CuTHeqRpA%40mail.gmail.com
> --
> 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
> [8].
>
>
> Links:
> ------
> [1] https://www.measurementlab.net/community-guidelines/
> [2]
> https://www.measurementlab.net/blog/speed-tests-accuracy/#how-fast-is-my-internet?-speed-tests,-accuracy,-ndt-&-m-lab
> [3]
> https://www.measurementlab.net/blog/ntia/#ndt-data-in-ntia-indicators-of-broadband-need
> [4]
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/a609ce0e-7be6-4b4e-a231-227d7cd4106bn%40measurementlab.net?utm_medium=email&utm_source=footer
> [5] http://www.measurementlab.net
> [6] https://codeforscience.org/
> [7]
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAD3WrcMg5JOuFWy4Fd6G4CKnE3CQN0m0nWXCbCGoZg_S1vcuxw%40mail.gmail.com?utm_medium=email&utm_source=footer
> [8]
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAK0jp%2B-rE_c6oPASz4D5gdBBaac-WP71eXgD_D_k_CuTHeqRpA%40mail.gmail.com?utm_medium=email&utm_source=footer
Dave Taht
Apr 15, 2022, 1:28:41 PM4/15/22
to Paul Zahra, Lai Yi Ohlsen, Nick Feamster, discuss, etha...@gmail.com
Ironically, one of my big pushes to get into the NTIA $70B broadband
buildout is better, , more secure, constantly upgraded, and more
standards compliant, home routers and CPE, and to find ways to
regulate better reliability into them in the first place.
CeroWrt's routers had uptimes measured in *years*. So my suggestion
would be to get a better router. I'm big on reflashing older ones to
openwrt, and installing "smart queue managemen" (SQM), which will
change the characteristics of your NDT results for the better, but the
kind of the results you get now may well be a reflection of the kind
of bugs in your router than millions share.
Turris and evenroute are also pretty good.
> To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAK0jp%2B-rE_c6oPASz4D5gdBBaac-WP71eXgD_D_k_CuTHeqRpA%40mail.gmail.com.
--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
Dave Täht CEO, TekLibre, LLC
buildout is better, , more secure, constantly upgraded, and more
standards compliant, home routers and CPE, and to find ways to
regulate better reliability into them in the first place.
CeroWrt's routers had uptimes measured in *years*. So my suggestion
would be to get a better router. I'm big on reflashing older ones to
openwrt, and installing "smart queue managemen" (SQM), which will
change the characteristics of your NDT results for the better, but the
kind of the results you get now may well be a reflection of the kind
of bugs in your router than millions share.
Turris and evenroute are also pretty good.
--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
Dave Täht CEO, TekLibre, LLC
Reply all
Reply to author
Forward
0 new messages