Re: [Bloat] Fwd: dslreports and inbound rate shaping
Found it! http://www.dslreports.com/speedtest/513499 smime.p7s Description: S/MIME Cryptographic Signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fwd: dslreports and inbound rate shaping
On 19/05/2015 23:37, Dave Taht wrote: 0) dslreports has a hires bufferbloat option now in their settings. It reveals much detail that I like very much. It may not work well on some browsers. Give it a shot, please. Tried it - fun! Here are some of the results of that fun, I've no idea if this will help anyone. 1) I like that the graphic .png reports now a ping range, but I think that is baseline latencies. but I think it would be clearer if it showed the up and the down, under load, 98th percentile, also. an unshaped, unmodified cable modem result in all it's horrible glory: http://www.dslreports.com/speedtest/506793 Ok so this is my HG612 unshaped VDSL2 modem sat behind Archer C7. The VDSL2 link is 40Mbit down, 10Mbit up as reported as its capped 'sync' rate. http://www.dslreports.com/speedtest/513588 Up is horrendous and I think you can see classic TCP sawtoothing in the delay as well. Peak just as 'up test' goes idle is strange though. 2) the cable test (which keeps changing the number of flows - these are all 16/6 flows) thoroughly breaks the sqm system's inbound rate shaper, using cake or fq_codel (cake here), with my rate set 12% below the delivered rate (100mbit vs 112Mbit). Behaviour here is different. In theory same test 16/6 flows, down is capped 38Mbit (5%), up at 9.7Mbit(3%) These are all 'cake' http://www.dslreports.com/speedtest/513627 There's a slight double bump at the beginning of the down latency test, but otherwise my browsing/upload/download experience is vastly improved. Tuning the down to 37Mbit helps that bump a little maybe: http://www.dslreports.com/speedtest/513652 It gets really interesting if I increase the down limit to 39Mbit: http://www.dslreports.com/speedtest/513782 where it starts to look a bit like your test results. Increasing the up limit showed an interesting step change in upload delay, this is the up cap set to 9.8Mbit http://www.dslreports.com/speedtest/513863 (I had a really good example of the delay increasing in a linear fashion as the buffer just couldn't drain fast enough...if I find that test result again I'll post it) Tuning it back down, by even as little as 50kbits would remove that step, I settled on 9.7Mbit for safety. The elephant in my personal room is the high latency baseline measurement. None of the ping response time test sites I've checked give me anywhere near a baseline ping rtt of 100ms. Even dslreports say London UK is ~10ms, Google Europe is ~17ms, Dublin, Ireland, EU is ~20ms, Frankfurt, DE, EU is ~27ms So I clearly don't understand some thing(s) about this test. Anyway, that's been an interesting 2 hours of playing! Kevin 3) I will try to add a few dslreports emulations into the netperf-wrapper suite. Sigh. Still so much work left to perform on bufferbloat on conventional devices. I think fixing wifi will be harder than this. Building spacecraft is easier than this. -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 smime.p7s Description: S/MIME Cryptographic Signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] dslreports mockup
I wanted to be able to have separated charts for up and down on different scales, so I took apart what exists today in gimp and got this: http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png I guess it is partially because I am getting a C on the download at this speed, and no A+ on the upload, and I would at least like to get a gold star from teacher for effort. :/ I dunno how to fix the download short of getting rid of several seconds of inherent buffering in their CMTS. There must be a simple way to do that?? -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] Fwd: [IP] Measuring broadband performance...or not?
Although I liked that this document mentioned latency 10 times, not measuring latency *with load* is like measuring the safety of a car only when it is parked. -- Forwarded message -- From: David Farber far...@gmail.com Date: Wed, May 20, 2015 at 6:55 AM Subject: [IP] Measuring broadband performance...or not? To: ip i...@listbox.com Begin forwarded message: *From: *Suzanne Johnson f...@pobox.com *Subject: **Measuring broadband performance...or not?* *Date: *May 20, 2015 at 9:32:35 AM EDT *To: *DAVID J. FARBER d...@farber.net Why Is It So Dang Difficult To Get Accurate Information About Broadband Speeds? Your cable company sells you a broadband plan advertising download speeds of “up to 25Mbps.” But it feels sluggish to you so you check out an online speed test site and it tells you you’re only getting a fraction of that speed. Then the FCC comes out with its Measuring Broadband America report which — if you can even make heads or tails of it — says your ISP is actually exceeding its advertised download speeds. Why don’t all of these things agree? A new report [PDF https://consumermediallc.files.wordpress.com/2015/05/669739.pdf] from the Government Accountability Office finds that while there are multiple sources for information on broadband performance, there is disagreement about exactly what information should be shared and how to present it. .clip http://consumerist.com/2015/05/15/why-is-it-so-dang-difficult-to-get-accurate-information-about-broadband-speeds/ Archives https://www.listbox.com/member/archive/247/=now https://www.listbox.com/member/archive/rss/247/26973280-5ba6a701 | Modify https://www.listbox.com/member/?member_id=26973280id_secret=26973280-3b04af21 Your Subscription | Unsubscribe Now https://www.listbox.com/unsubscribe/?member_id=26973280id_secret=26973280-063e9b28post_id=20150520095517:D39CCCAE-FEF7-11E4-B297-AEFB9996D0A2 http://www.listbox.com -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] dslreports mockup
Providing separate grades for upload and download does not make sense to me, as interference with acks in the other direction badly hurts that traffic. Uploads and downloads are *not* independent variables. KISS: one grade - Jim On Thu, May 21, 2015 at 9:45 AM, Rich Brown richb.hano...@gmail.com wrote: That is interesting. I'm trying to think how the latency charts could be misconstrued, since a Y-axis on the right isn't the norm - I don't think it's hard to understand, but just different. The display as-is clearly shows that the download is badly bloated, but the upload is fine. That's the important message for most people at home. But as a researcher, you want to understand the details of the upload. So having different scales would help you see better into the problem. * If the download and upload values are substantially similar, the left and right Y-axis scales should be the same, so there wouldn't be confusion * If the values are substantially different (as in this screen shot), the pink and yellow backgrounds (on the left) and the lack of them on the right would provide a solid cue that there is something different going on between the two charts. * On the other hand, the report already shows different Y-axis values for the down/upload speeds, so the latency charts could mimic the speeds... Other thoughts? Rich On May 20, 2015, at 12:46 PM, Dave Taht dave.t...@gmail.com wrote: I wanted to be able to have separated charts for up and down on different scales, so I took apart what exists today in gimp and got this: http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png I guess it is partially because I am getting a C on the download at this speed, and no A+ on the upload, and I would at least like to get a gold star from teacher for effort. :/ I dunno how to fix the download short of getting rid of several seconds of inherent buffering in their CMTS. There must be a simple way to do that?? -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ 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
Re: [Bloat] dslreports mockup
That is interesting. I'm trying to think how the latency charts could be misconstrued, since a Y-axis on the right isn't the norm - I don't think it's hard to understand, but just different. The display as-is clearly shows that the download is badly bloated, but the upload is fine. That's the important message for most people at home. But as a researcher, you want to understand the details of the upload. So having different scales would help you see better into the problem. * If the download and upload values are substantially similar, the left and right Y-axis scales should be the same, so there wouldn't be confusion * If the values are substantially different (as in this screen shot), the pink and yellow backgrounds (on the left) and the lack of them on the right would provide a solid cue that there is something different going on between the two charts. * On the other hand, the report already shows different Y-axis values for the down/upload speeds, so the latency charts could mimic the speeds... Other thoughts? Rich On May 20, 2015, at 12:46 PM, Dave Taht dave.t...@gmail.com wrote: I wanted to be able to have separated charts for up and down on different scales, so I took apart what exists today in gimp and got this: http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png I guess it is partially because I am getting a C on the download at this speed, and no A+ on the upload, and I would at least like to get a gold star from teacher for effort. :/ I dunno how to fix the download short of getting rid of several seconds of inherent buffering in their CMTS. There must be a simple way to do that?? -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ 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
Re: [Bloat] [Cake] dslreports and inbound rate shaping
On 19 May, 2015, at 22:17, Dave Taht dave.t...@gmail.com wrote: So I finished writing up my thoughts on bobbie, http://www.bufferbloat.net/projects/codel/wiki/Bobbie which might work better than anything on the table in the face of huge bursts like these, when the rate differential is so small. I wonder if there’s any profit in making fq_codel and cake behave more like a policer on ingress; that would be halfway to bobbie without writing a lot of new code. A reasonable test would be to try configuring fq_codel with interval = target = 5ms. If that works better, I could add similar functionality to cake. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] dslreports mockup
Ahah! I wasn't clear. I do want One Grade to Rule Them All... But I was only talking about different Y-axis values on the latency charts, so that a bad latency in one direction doesn't hide the details of the transfer in the other. Rich On May 21, 2015, at 10:13 AM, Jim Gettys j...@freedesktop.org wrote: Providing separate grades for upload and download does not make sense to me, as interference with acks in the other direction badly hurts that traffic. Uploads and downloads are *not* independent variables. KISS: one grade - Jim On Thu, May 21, 2015 at 9:45 AM, Rich Brown richb.hano...@gmail.com wrote: That is interesting. I'm trying to think how the latency charts could be misconstrued, since a Y-axis on the right isn't the norm - I don't think it's hard to understand, but just different. The display as-is clearly shows that the download is badly bloated, but the upload is fine. That's the important message for most people at home. But as a researcher, you want to understand the details of the upload. So having different scales would help you see better into the problem. * If the download and upload values are substantially similar, the left and right Y-axis scales should be the same, so there wouldn't be confusion * If the values are substantially different (as in this screen shot), the pink and yellow backgrounds (on the left) and the lack of them on the right would provide a solid cue that there is something different going on between the two charts. * On the other hand, the report already shows different Y-axis values for the down/upload speeds, so the latency charts could mimic the speeds... Other thoughts? Rich On May 20, 2015, at 12:46 PM, Dave Taht dave.t...@gmail.com wrote: I wanted to be able to have separated charts for up and down on different scales, so I took apart what exists today in gimp and got this: http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png I guess it is partially because I am getting a C on the download at this speed, and no A+ on the upload, and I would at least like to get a gold star from teacher for effort. :/ I dunno how to fix the download short of getting rid of several seconds of inherent buffering in their CMTS. There must be a simple way to do that?? -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ 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
Re: [Bloat] [Cake] dslreports and inbound rate shaping
On 5/21/15 9:21 AM, Jonathan Morton wrote: On 19 May, 2015, at 22:17, Dave Taht dave.t...@gmail.com wrote: So I finished writing up my thoughts on bobbie, http://www.bufferbloat.net/projects/codel/wiki/Bobbie which might work better than anything on the table in the face of huge bursts like these, when the rate differential is so small. I wonder if there’s any profit in making fq_codel and cake behave more like a policer on ingress; that would be halfway to bobbie without writing a lot of new code. A reasonable test would be to try configuring fq_codel with interval = target = 5ms. If that works better, I could add similar functionality to cake. I'm curious why you think that would be a reasonable test. Kathie - Jonathan Morton ___ 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
Re: [Bloat] [Cake] dslreports and inbound rate shaping
It sounds like you are defining congestion as packets experiencing 5ms of delay over a period of 5ms. When you evaluate this, what metrics do you use to evaluate the effect on the applications using this buffer? Kathie On 5/21/15 8:26 AM, Jonathan Morton wrote: When Codel is applied on the upstream side of a link, a burst arrives in it almost instantly, and thus it only takes 5ms to detect that 5ms of queue has developed. The interval parameter then delays action on that detection until it is certain that it's a standing queue and not simply a burst. When applied on the downstream side of a link, however, it takes longer for a burst to filter through to where Codel can see it. If the shaper is set to 90% of the link rate, it takes at least 45ms to build a 5ms queue, during which the receiver is acking data without any clue that congestion is in place. At 95%, it requires at least 95ms. The delay in detection might be even longer under some circumstances. This means Codel has to be more aggressive at responding to a detected 5ms queue on ingress in order to provide control of the flow comparable to egress. I'm proposing using a reduced interval parameter to do that. A drawback is that the response will be stronger than designed, and this may have an impact on throughput, but the same is true (and more definitely so) of a policer. On the one hand, this might lead to an interim solution while Bobbie gets fleshed out. On the other, it should provide more information on whether Bobbie is likely to work. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] dslreports mockup
On Thu, May 21, 2015 at 10:24 AM, Rich Brown richb.hano...@gmail.com wrote: Ahah! I wasn't clear. I do want One Grade to Rule Them All... But I was only talking about different Y-axis values on the latency charts, so that a bad latency in one direction doesn't hide the details of the transfer in the other. Ah, yes. That makes sense. - Jim Rich On May 21, 2015, at 10:13 AM, Jim Gettys j...@freedesktop.org wrote: Providing separate grades for upload and download does not make sense to me, as interference with acks in the other direction badly hurts that traffic. Uploads and downloads are *not* independent variables. KISS: one grade - Jim On Thu, May 21, 2015 at 9:45 AM, Rich Brown richb.hano...@gmail.com wrote: That is interesting. I'm trying to think how the latency charts could be misconstrued, since a Y-axis on the right isn't the norm - I don't think it's hard to understand, but just different. The display as-is clearly shows that the download is badly bloated, but the upload is fine. That's the important message for most people at home. But as a researcher, you want to understand the details of the upload. So having different scales would help you see better into the problem. * If the download and upload values are substantially similar, the left and right Y-axis scales should be the same, so there wouldn't be confusion * If the values are substantially different (as in this screen shot), the pink and yellow backgrounds (on the left) and the lack of them on the right would provide a solid cue that there is something different going on between the two charts. * On the other hand, the report already shows different Y-axis values for the down/upload speeds, so the latency charts could mimic the speeds... Other thoughts? Rich On May 20, 2015, at 12:46 PM, Dave Taht dave.t...@gmail.com wrote: I wanted to be able to have separated charts for up and down on different scales, so I took apart what exists today in gimp and got this: http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png I guess it is partially because I am getting a C on the download at this speed, and no A+ on the upload, and I would at least like to get a gold star from teacher for effort. :/ I dunno how to fix the download short of getting rid of several seconds of inherent buffering in their CMTS. There must be a simple way to do that?? -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ 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
Re: [Bloat] [Cake] dslreports and inbound rate shaping
No - at 90% shaping on ingress, 5/5ms will trigger when the visible queue has built up to 5ms over a continuous 50ms. At 95%, it'll trigger at 100ms. Remember, Codel can't see what's in the dumb FIFO on the upstream end of the link. By the time it triggers, there's potentially a lot of queue there that it doesn't know about and can't directly measure. That's why it has to be more aggressive about the queue it can see. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] dslreports mockup
On 22 May, 2015, at 03:17, jb jus...@dslr.net wrote: Or I can just have two Y-Axis with auto-scaling on both. You could also try a square-root scale (as opposed to linear or logarithmic). This should help with comparing data with different orders of magnitude, without flattening things as aggressively as a log scale. But perhaps we should see what it looks like before committing to it. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] [Cake] dslreports and inbound rate shaping
But will it trigger at all? If the inbound rate is say 50Mbps, and the link to the in-home devices are over 100Mbps ethernet, will codel _ever_ see a 5ms buffer on inbound? Or is the shaping buffering incoming packets, and creating a bundle that it can measure? (I don't know the internals of how htb(?) does the limiting) -Aaron On Thu, May 21, 2015 at 9:39 AM, Jonathan Morton chromati...@gmail.com wrote: No - at 90% shaping on ingress, 5/5ms will trigger when the visible queue has built up to 5ms over a continuous 50ms. At 95%, it'll trigger at 100ms. Remember, Codel can't see what's in the dumb FIFO on the upstream end of the link. By the time it triggers, there's potentially a lot of queue there that it doesn't know about and can't directly measure. That's why it has to be more aggressive about the queue it can see. - Jonathan Morton ___ 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
