Dslreports got a new speedtester up, anybody know Justin or some of the other people over there?
http://www.dslreports.com/speedtest Maybe somebody on here could even lend a hand in getting them to implement features like ping under load etc. Pedro On Fri, Mar 20, 2015 at 2:50 PM, Rich Brown <richb.hano...@gmail.com> wrote: > On Mar 19, 2015, at 7:18 PM, Greg White <g.wh...@cablelabs.com> wrote: > > > Netalyzr is great for network geeks, hardly consumer-friendly, and even > so > > the "network buffer measurements" part is buried in 150 other statistics. > > Why couldn't Ookla* add a simultaneous "ping" test to their throughput > > test? When was the last time someone leaned on them? > > > > > > *I realize not everyone likes the Ookla tool, but it is popular and about > > as "sexy" as you are going to get with a network performance tool. > > > > -Greg > > Back in July, I contacted the support groups at Ookla, speedof.me, and > testmy.net, and all three responded, "Hmmm... We'll refer that to our > techies for review." and I never heard back. > > It seems to be hard to attract attention when there's only one voice > crying in the wilderness. It might be worth sending a note to: > > - Speedtest.net <supp...@speedtest.net> or open a ticket at: > https://www.ookla.com/support > - SpeedOfMe <cont...@speedof.me> > - TestMyNet <webmas...@testmy.net> > > I append my (somewhat edited) note from July for your email drafting > pleasure. > > Rich > > --- Sample Letter --- > > Subject: Add latency measurements (min/max) > > I have been using NAME-OF-SERVICE for quite a while to measure my > network's performance. I had a couple thoughts that could make it more > useful to me and others who want to test their network. > > Your page currently displays a single "latency" value of the ping time > before the data transfers begin. It would be really helpful to report > real-time min/max latency measurements made *during the up and downloads*. > > Why is latency interesting? Because when it's not well controlled, it > completely destroys people's internet for voice, gaming, other > time-sensitive traffic, and even everyday web browsing. As you may know, > many routers (home and otherwise) buffer more data than can be sent, and > this can dramatically affect latency for everyone using that router. > > I'm asking you to consider implementing the web-equivalent of the "Quick > Test for Bufferbloat" that's on the Bufferbloat site. (I'm a member of the > Bufferbloat team.) > http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat > > Please get back to me if you have questions. > > Many thanks! > > YOUR NAME > YOUR SIG > > --- end of sample --- > > > On 3/19/15, 2:29 PM, "dpr...@reed.com" <dpr...@reed.com> wrote: > > > >> I do think engineers operating networks get it, and that Comcast's > >> engineers really get it, as I clarified in my followup note. > >> > >> The issue is indeed prioritization of investment, engineering resources > >> and management attention. The teams at Comcast in the engineering side > >> have been the leaders in "bufferbloat minimizing" work, and I think they > >> should get more recognition for that. > >> > >> I disagree a little bit about not having a test that shows the issue, > and > >> the value the test would have in demonstrating the issue to users. > >> Netalyzer has been doing an amazing job on this since before the > >> bufferbloat term was invented. Every time I've talked about this issue > >> I've suggested running Netalyzer, so I have a personal set of comments > >> from people all over the world who run Netalyzer on their home networks, > >> on hotel networks, etc. > >> > >> When I have brought up these measurements from Netalyzr (which are not > >> aimed at showing the problem as users experience) I observe an > >> interesting reaction from many industry insiders: the results are not > >> "sexy enough for stupid users" and also "no one will care". > >> > >> I think the reaction characterizes the problem correctly - but the > second > >> part is the most serious objection. People don't need a measurement > >> tool, they need to know that this is why their home network sucks > >> sometimes. > >> > >> > >> > >> > >> > >> On Thursday, March 19, 2015 3:58pm, "Livingood, Jason" > >> <jason_living...@cable.comcast.com> said: > >> > >>> On 3/19/15, 1:11 PM, "Dave Taht" <dave.t...@gmail.com> wrote: > >>> > >>>> On Thu, Mar 19, 2015 at 6:53 AM, <dpr...@reed.com> wrote: > >>>>> How many years has it been since Comcast said they were going to fix > >>>>> bufferbloat in their network within a year? > >>> > >>> I¹m not sure anyone ever said it¹d take a year. If someone did (even if > >>> it > >>> was me) then it was in the days when the problem appeared less > >>> complicated > >>> than it is and I apologize for that. Let¹s face it - the problem is > >>> complex and the software that has to be fixed is everywhere. As I said > >>> about IPv6: if it were easy, it¹d be done by now. ;-) > >>> > >>>>> It's almost as if the cable companies don't want OTT video or > >>>>> simultaneous FTP and interactive gaming to work. Of course not. > They'd > >>>>> never do that. > >>> > >>> Sorry, but that seems a bit unfair. It flies in the face of what we > have > >>> done and are doing. We¹ve underwritten some of Dave¹s work, we got > >>> CableLabs to underwrite AQM work, and I personally pushed like heck to > >>> get > >>> AQM built into the default D3.1 spec (had CTO-level awareness & > support, > >>> and was due to Greg White¹s work at CableLabs). We are starting to > field > >>> test D3.1 gear now, by the way. We made some bad bets too, such as > >>> trying > >>> to underwrite an OpenWRT-related program with ISC, but not every tactic > >>> will always be a winner. > >>> > >>> As for existing D3.0 gear, it¹s not for lack of trying. Has any DOCSIS > >>> network of any scale in the world solved it? If so, I have something to > >>> use to learn from and apply here at Comcast - and I¹d **love** an > >>> introduction to someone who has so I can get this info. > >>> > >>> But usually there are rational explanations for why something is still > >>> not > >>> done. One of them is that the at-scale operational issues are more > >>> complicated that some people realize. And there is always a case of > >>> prioritization - meaning things like running out of IPv4 addresses and > >>> not > >>> having service trump more subtle things like buffer bloat (and the > >>> effort > >>> to get vendors to support v6 has been tremendous). > >>> > >>>> I do understand there are strong forces against us, especially in the > >>>> USA. > >>> > >>> I¹m not sure there are any forces against this issue. It¹s more a > >>> question > >>> of awareness - it is not apparent it is more urgent than other work in > >>> everyone¹s backlog. For example, the number of ISP customers even aware > >>> of > >>> buffer bloat is probably 0.001%; if customers aren¹t asking for it, the > >>> product managers have a tough time arguing to prioritize buffer bloat > >>> work > >>> over new feature X or Y. > >>> > >>> One suggestion I have made to increase awareness is that there be a > >>> nice, > >>> web-based, consumer-friendly latency under load / bloat test that you > >>> could get people to run as they do speed tests today. (If someone > thinks > >>> they can actually deliver this, I will try to fund it - ping me > >>> off-list.) > >>> I also think a better job can be done explaining buffer bloat - it¹s > >>> hard > >>> to make an Œelevator pitch¹ about it. > >>> > >>> It reminds me a bit of IPv6 several years ago. Rather than saying in > >>> essence Œyou operators are dummies¹ for not already fixing this, maybe > >>> assume the engineers all Œget it¹ and what to do it. Because we really > >>> do > >>> get it and want to do something about it. Then ask those operators what > >>> they need to convince their leadership and their suppliers and product > >>> managers and whomever else that it needs to be resourced more > >>> effectively > >>> (see above for example). > >>> > >>> We¹re at least part of the way there in DOCSIS networks. It is in D3.1 > >>> by > >>> default, and we¹re starting trials now. And probably within 18-24 > months > >>> we won¹t buy any DOCSIS CPE that is not 3.1. > >>> > >>> The question for me is how and when to address it in DOCSIS 3.0. > >>> > >>> - Jason > >>> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Bloat mailing list > >> Bloat@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/bloat > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > -- Best regards / Mvh Jan Pedro Tumusok
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat