* [Bloat] dslreports and inbound rate shaping @ 2015-05-19 19:17 Dave Taht 2015-05-19 22:37 ` [Bloat] Fwd: " Dave Taht ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Dave Taht @ 2015-05-19 19:17 UTC (permalink / raw) To: bloat, Justin Beech, cake 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. 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 I am puzzled as to why the idle portion of the test is so bad. Perhaps it it measuring a new flow syn/synack/data? Or there is a need for the lowat option on the server side so as to end the test more quickly? or have we lost so badly there are still 10 seconds of data in flight?? (will take apart some captures when I have time) 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). http://www.dslreports.com/speedtest/509743 fq_codel: http://www.dslreports.com/speedtest/509763 Pie: http://www.dslreports.com/speedtest/509736 Desperate, I applied the linux policer to the inbound test, and got huge reductions in latency, still with big bursts at a huge cost in bandwidth. http://www.dslreports.com/speedtest/506807 We have done too much testing with the gentler rrul test, and this explains a lot about some bittorrent results I have got elsewhere. 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. 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bloat] Fwd: dslreports and inbound rate shaping 2015-05-19 19:17 [Bloat] dslreports and inbound rate shaping Dave Taht @ 2015-05-19 22:37 ` Dave Taht 2015-05-20 12:47 ` Kevin Darbyshire-Bryant 2015-05-20 13:02 ` Kevin Darbyshire-Bryant 2015-05-21 16:21 ` [Bloat] [Cake] " Jonathan Morton 2015-05-25 11:26 ` [Bloat] " Mikael Abrahamsson 2 siblings, 2 replies; 19+ messages in thread From: Dave Taht @ 2015-05-19 22:37 UTC (permalink / raw) To: bloat resending as the mail server seems to be mis-behaving. ---------- Forwarded message ---------- From: Dave Taht <dave.taht@gmail.com> Date: Tue, May 19, 2015 at 12:17 PM Subject: dslreports and inbound rate shaping To: bloat <bloat@lists.bufferbloat.net>, Justin Beech <justinbeech@gmail.com>, cake@lists.bufferbloat.net 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. 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 I am puzzled as to why the idle portion of the test is so bad. Perhaps it it measuring a new flow syn/synack/data? Or there is a need for the lowat option on the server side so as to end the test more quickly? or have we lost so badly there are still 10 seconds of data in flight?? (will take apart some captures when I have time) 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). http://www.dslreports.com/speedtest/509743 fq_codel: http://www.dslreports.com/speedtest/509763 Pie: http://www.dslreports.com/speedtest/509736 Desperate, I applied the linux policer to the inbound test, and got huge reductions in latency, still with big bursts at a huge cost in bandwidth. http://www.dslreports.com/speedtest/506807 We have done too much testing with the gentler rrul test, and this explains a lot about some bittorrent results I have got elsewhere. 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. 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 -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] Fwd: dslreports and inbound rate shaping 2015-05-19 22:37 ` [Bloat] Fwd: " Dave Taht @ 2015-05-20 12:47 ` Kevin Darbyshire-Bryant 2015-05-22 14:05 ` Alan Jenkins 2015-05-20 13:02 ` Kevin Darbyshire-Bryant 1 sibling, 1 reply; 19+ messages in thread From: Kevin Darbyshire-Bryant @ 2015-05-20 12:47 UTC (permalink / raw) To: bloat [-- Attachment #1: Type: text/plain, Size: 3168 bytes --] 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 > > [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4791 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] Fwd: dslreports and inbound rate shaping 2015-05-20 12:47 ` Kevin Darbyshire-Bryant @ 2015-05-22 14:05 ` Alan Jenkins 2015-05-25 21:39 ` jb 0 siblings, 1 reply; 19+ messages in thread From: Alan Jenkins @ 2015-05-22 14:05 UTC (permalink / raw) To: bloat On 20/05/15 13:47, Kevin Darbyshire-Bryant wrote: > 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 Good fun :). The baseline latency is because the bloat measurement uses a single websocket ping server in America. Justin said in the forums it didn't seem worth the effort to set up more of them. Seems worth an faq item though :(. Alan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] Fwd: dslreports and inbound rate shaping 2015-05-22 14:05 ` Alan Jenkins @ 2015-05-25 21:39 ` jb 2015-05-26 9:13 ` Alan Jenkins 0 siblings, 1 reply; 19+ messages in thread From: jb @ 2015-05-25 21:39 UTC (permalink / raw) To: Alan Jenkins, bloat [-- Attachment #1: Type: text/plain, Size: 4019 bytes --] Regarding this part: > The baseline latency is because the bloat measurement uses a single websocket ping server in America. Justin said in the forums it didn't seem worth the effort to set up more of them. Seems worth an faq item though :(. Below huge speeds, upload testing is done with web socket now, so there is a websocket address on every server now anyway. The baseline pinging to dslreports.com doesn't seem broken but if necessary it can be changed to baseline pinging to the nearest server, wherever that is. On Sat, May 23, 2015 at 12:05 AM, Alan Jenkins < alan.christopher.jenkins@gmail.com> wrote: > On 20/05/15 13:47, Kevin Darbyshire-Bryant wrote: > > 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 > > Good fun :). > > The baseline latency is because the bloat measurement uses a single > websocket ping server in America. Justin said in the forums it didn't seem > worth the effort to set up more of them. Seems worth an faq item though :(. > > Alan > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > [-- Attachment #2: Type: text/html, Size: 5850 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] Fwd: dslreports and inbound rate shaping 2015-05-25 21:39 ` jb @ 2015-05-26 9:13 ` Alan Jenkins 2015-05-26 11:33 ` jb 0 siblings, 1 reply; 19+ messages in thread From: Alan Jenkins @ 2015-05-26 9:13 UTC (permalink / raw) To: jb, bloat [-- Attachment #1: Type: text/plain, Size: 2537 bytes --] On 25/05/15 22:39, jb wrote: > Regarding this part: > > > The baseline latency is because the bloat measurement uses a single > websocket ping server in America. Justin said in the forums it didn't > seem worth the effort to set up more of them. Seems worth an faq item > though :(. > > Below huge speeds, upload testing is done with web socket now, > so there is a websocket address on every server now anyway. > > The baseline pinging to dslreports.com <http://dslreports.com> doesn't > seem broken > but if necessary it can be changed to baseline pinging to the > nearest server, wherever that is. > Personally I might be skewed by using Firefox on Linux, I don't see the awesome live bloat-meter, only the awesome bloat graphs. PS My firefox also doesn't show the new graph-based speedtest history. I disabled the obvious culprits (noscript, ghostery, ublock) & there's nothing on the JS console. Happy to help if needed. "Fixing" the bufferbloat ping graph would make it more directly comparable to the pings on other speedtests. I think that makes the bufferbloat point clearer. Again the issue is outside the US; in the UK I see a 100ms "baseline". If it's simple to start using nearer servers, that would make me very happy :). I agree it's not "broken". (I also use netperf-eu at 59ms). It's just confusing to interpret, if you don't already know what bufferbloat is going to look like. Particularly as the "expected" low ping value shown at the start. The 100ms server isn't even shown on the ping radar part. If it's easier to just call out the destination country on the bufferbloat ping, or fudge the figures convincingly (just graph the increases from a minimum), that would answer my point too. Thanks Alan > > > 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 > > Good fun :). > > The baseline latency is because the bloat measurement uses a > single websocket ping server in America. Justin said in the > forums it didn't seem worth the effort to set up more of them. > Seems worth an faq item though :(. > [-- Attachment #2: Type: text/html, Size: 4563 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] Fwd: dslreports and inbound rate shaping 2015-05-26 9:13 ` Alan Jenkins @ 2015-05-26 11:33 ` jb 0 siblings, 0 replies; 19+ messages in thread From: jb @ 2015-05-26 11:33 UTC (permalink / raw) Cc: bloat [-- Attachment #1: Type: text/plain, Size: 2772 bytes --] The test, and the issue of buffer bloat, got some coverage today in the Houston Chronicle: http://blog.chron.com/techblog/2015/05/new-speed-test-at-dslreports/ On Tue, May 26, 2015 at 7:13 PM, Alan Jenkins < alan.christopher.jenkins@gmail.com> wrote: > On 25/05/15 22:39, jb wrote: > > Regarding this part: > > > The baseline latency is because the bloat measurement uses a single > websocket ping server in America. Justin said in the forums it didn't seem > worth the effort to set up more of them. Seems worth an faq item though :(. > > Below huge speeds, upload testing is done with web socket now, > so there is a websocket address on every server now anyway. > > The baseline pinging to dslreports.com doesn't seem broken > but if necessary it can be changed to baseline pinging to the > nearest server, wherever that is. > > > Personally I might be skewed by using Firefox on Linux, I don't see the > awesome live bloat-meter, only the awesome bloat graphs. > > PS My firefox also doesn't show the new graph-based speedtest history. I > disabled the obvious culprits (noscript, ghostery, ublock) & there's > nothing on the JS console. Happy to help if needed. > > "Fixing" the bufferbloat ping graph would make it more directly comparable > to the pings on other speedtests. I think that makes the bufferbloat point > clearer. Again the issue is outside the US; in the UK I see a 100ms > "baseline". If it's simple to start using nearer servers, that would make > me very happy :). > > I agree it's not "broken". (I also use netperf-eu at 59ms). It's just > confusing to interpret, if you don't already know what bufferbloat is going > to look like. > > Particularly as the "expected" low ping value shown at the start. The > 100ms server isn't even shown on the ping radar part. > > If it's easier to just call out the destination country on the bufferbloat > ping, or fudge the figures convincingly (just graph the increases from a > minimum), that would answer my point too. > > Thanks > Alan > > > > 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 >> >> Good fun :). >> >> The baseline latency is because the bloat measurement uses a single >> websocket ping server in America. Justin said in the forums it didn't seem >> worth the effort to set up more of them. Seems worth an faq item though :(. >> > > [-- Attachment #2: Type: text/html, Size: 5234 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] Fwd: dslreports and inbound rate shaping 2015-05-19 22:37 ` [Bloat] Fwd: " Dave Taht 2015-05-20 12:47 ` Kevin Darbyshire-Bryant @ 2015-05-20 13:02 ` Kevin Darbyshire-Bryant 1 sibling, 0 replies; 19+ messages in thread From: Kevin Darbyshire-Bryant @ 2015-05-20 13:02 UTC (permalink / raw) To: bloat [-- Attachment #1: Type: text/plain, Size: 61 bytes --] Found it! http://www.dslreports.com/speedtest/513499 [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4791 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-19 19:17 [Bloat] dslreports and inbound rate shaping Dave Taht 2015-05-19 22:37 ` [Bloat] Fwd: " Dave Taht @ 2015-05-21 16:21 ` Jonathan Morton 2015-05-21 15:07 ` Kathleen Nichols 2015-05-22 10:57 ` Kevin Darbyshire-Bryant 2015-05-25 11:26 ` [Bloat] " Mikael Abrahamsson 2 siblings, 2 replies; 19+ messages in thread From: Jonathan Morton @ 2015-05-21 16:21 UTC (permalink / raw) To: Dave Taht; +Cc: cake, Justin Beech, bloat > On 19 May, 2015, at 22:17, Dave Taht <dave.taht@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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-21 16:21 ` [Bloat] [Cake] " Jonathan Morton @ 2015-05-21 15:07 ` Kathleen Nichols 2015-05-21 15:26 ` Jonathan Morton 2015-05-22 10:57 ` Kevin Darbyshire-Bryant 1 sibling, 1 reply; 19+ messages in thread From: Kathleen Nichols @ 2015-05-21 15:07 UTC (permalink / raw) To: Jonathan Morton, Dave Taht; +Cc: cake, Justin Beech, bloat On 5/21/15 9:21 AM, Jonathan Morton wrote: > >> On 19 May, 2015, at 22:17, Dave Taht <dave.taht@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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-21 15:07 ` Kathleen Nichols @ 2015-05-21 15:26 ` Jonathan Morton 2015-05-21 16:31 ` Kathleen Nichols 0 siblings, 1 reply; 19+ messages in thread From: Jonathan Morton @ 2015-05-21 15:26 UTC (permalink / raw) To: Kathleen Nichols; +Cc: cake, Justin Beech, bloat [-- Attachment #1: Type: text/plain, Size: 1284 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 1385 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-21 15:26 ` Jonathan Morton @ 2015-05-21 16:31 ` Kathleen Nichols 2015-05-21 16:39 ` Jonathan Morton 0 siblings, 1 reply; 19+ messages in thread From: Kathleen Nichols @ 2015-05-21 16:31 UTC (permalink / raw) To: Jonathan Morton; +Cc: cake, Justin Beech, bloat 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-21 16:31 ` Kathleen Nichols @ 2015-05-21 16:39 ` Jonathan Morton 2015-05-22 3:41 ` Aaron Wood 0 siblings, 1 reply; 19+ messages in thread From: Jonathan Morton @ 2015-05-21 16:39 UTC (permalink / raw) To: Kathleen Nichols; +Cc: cake, Justin Beech, bloat [-- Attachment #1: Type: text/plain, Size: 443 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 531 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-21 16:39 ` Jonathan Morton @ 2015-05-22 3:41 ` Aaron Wood 2015-05-22 6:32 ` Jonathan Morton 0 siblings, 1 reply; 19+ messages in thread From: Aaron Wood @ 2015-05-22 3:41 UTC (permalink / raw) To: Jonathan Morton; +Cc: cake, Justin Beech, bloat [-- Attachment #1: Type: text/plain, Size: 1029 bytes --] 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 <chromatix99@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 > > [-- Attachment #2: Type: text/html, Size: 1646 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-22 3:41 ` Aaron Wood @ 2015-05-22 6:32 ` Jonathan Morton 0 siblings, 0 replies; 19+ messages in thread From: Jonathan Morton @ 2015-05-22 6:32 UTC (permalink / raw) To: Aaron Wood; +Cc: cake, Justin Beech, bloat [-- Attachment #1: Type: text/plain, Size: 87 bytes --] Yes, it will. That's the whole point of combining it with a shaper. - Jonathan Morton [-- Attachment #2: Type: text/html, Size: 130 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-21 16:21 ` [Bloat] [Cake] " Jonathan Morton 2015-05-21 15:07 ` Kathleen Nichols @ 2015-05-22 10:57 ` Kevin Darbyshire-Bryant 2015-05-22 11:07 ` Jonathan Morton 1 sibling, 1 reply; 19+ messages in thread From: Kevin Darbyshire-Bryant @ 2015-05-22 10:57 UTC (permalink / raw) To: bloat [-- Attachment #1.1: Type: text/plain, Size: 2453 bytes --] On 21/05/2015 17:21, Jonathan Morton wrote: >> On 19 May, 2015, at 22:17, Dave Taht <dave.taht@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 Up for a challenge I tried it. Line rate is 40000 down, 10000 up - Sky broadband UK VDSL2 PTM (manual overhead of 8 for VLAN tagging on WAN & VDSL2 flags) note that I also use ECN everywhere. From the dslreports site, with a new layout I note - nice! Numbers at end of each line are reported latency for idle (minimum), up (average), down (average) in ms. Baseline: fq_codel 37500 9700 interval 100ms http://www.dslreports.com/speedtest/526382 - 109 114 112 fq_codel 37500 9700 interval 5ms http://www.dslreports.com/speedtest/526367 - 106 119 111 fq_codel 38500 9700 interval 100ms http://www.dslreports.com/speedtest/526318 - 106 120 110 standing q but managed slightly better than.... fq_codel 38500 9700 interval 5ms http://www.dslreports.com/speedtest/526305 - 116 142 118 standing q fq_codel 39000 9700 interval 100ms http://www.dslreports.com/speedtest/526335 - 110 153 113 spikey spaced fq_codel 39000 9700 interval 5ms http://www.dslreports.com/speedtest/526308 - 109 194 112 spikey closer fq_codel 40000 9700 interval 100ms http://www.dslreports.com/speedtest/526347 - 116 191 118 spikey fq_codel 40000 9700 interval 5ms http://www.dslreports.com/speedtest/526353 - 109 172 112 spikey I don't think tweaking intervals has given the hoped for result in my case. If anything It looks like it increases standing latency though some of graph scaling makes that difficult to see. The final test looks like it's heading in a better direction but it still has 420+ms spikes. -- Thanks, Kevin@Darbyshire-Bryant.me.uk [-- Attachment #1.2: Type: text/html, Size: 4492 bytes --] [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4791 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-22 10:57 ` Kevin Darbyshire-Bryant @ 2015-05-22 11:07 ` Jonathan Morton 2015-05-22 11:16 ` Kevin Darbyshire-Bryant 0 siblings, 1 reply; 19+ messages in thread From: Jonathan Morton @ 2015-05-22 11:07 UTC (permalink / raw) To: Kevin Darbyshire-Bryant; +Cc: bloat > fq_codel 40000 9700 interval 100ms http://www.dslreports.com/speedtest/526347 - 116 191 118 spikey > fq_codel 40000 9700 interval 5ms http://www.dslreports.com/speedtest/526353 - 109 172 112 spikey On a 40Mbit downlink, setting ingress to 40Mbit will exert effectively no control over incoming traffic. So what you’re seeing here is the raw performance of your ISP. I’d really like to see Dave trying this, since he was noting the problem to solve originally. - Jonathan Morton ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] [Cake] dslreports and inbound rate shaping 2015-05-22 11:07 ` Jonathan Morton @ 2015-05-22 11:16 ` Kevin Darbyshire-Bryant 0 siblings, 0 replies; 19+ messages in thread From: Kevin Darbyshire-Bryant @ 2015-05-22 11:16 UTC (permalink / raw) To: Jonathan Morton; +Cc: bloat [-- Attachment #1: Type: text/plain, Size: 1033 bytes --] On 22/05/2015 12:07, Jonathan Morton wrote: >> fq_codel 40000 9700 interval 100ms http://www.dslreports.com/speedtest/526347 - 116 191 118 spikey >> fq_codel 40000 9700 interval 5ms http://www.dslreports.com/speedtest/526353 - 109 172 112 spikey > On a 40Mbit downlink, setting ingress to 40Mbit will exert effectively no control over incoming traffic. So what you’re seeing here is the raw performance of your ISP. > > I’d really like to see Dave trying this, since he was noting the problem to solve originally. > > - Jonathan Morton > I followed it up with an outright lie to the limiter (and in interests of full disclosure I changed the outbound limit to be more conservative) fq_codel 80000! 9500 interval 100ms http://www.dslreports.com/speedtest/526549 109 139 115 fq_codel 80000! 9500 interval 5ms http://www.dslreports.com/speedtest/526556 111 183 115 - more & higher spikes I'll keep quiet now and hopefully watch other's results come in! -- Thanks, Kevin@Darbyshire-Bryant.me.uk [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4791 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bloat] dslreports and inbound rate shaping 2015-05-19 19:17 [Bloat] dslreports and inbound rate shaping Dave Taht 2015-05-19 22:37 ` [Bloat] Fwd: " Dave Taht 2015-05-21 16:21 ` [Bloat] [Cake] " Jonathan Morton @ 2015-05-25 11:26 ` Mikael Abrahamsson 2 siblings, 0 replies; 19+ messages in thread From: Mikael Abrahamsson @ 2015-05-25 11:26 UTC (permalink / raw) To: Dave Taht; +Cc: cake, Justin Beech, bloat On Tue, 19 May 2015, 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. I tried it on my DOCSIS 3 connection 250/50 with my Apple Airport Extreme (via gige cable): http://www.dslreports.com/speedtest/545437 I then cranked up the flows to 32/32 (max that was allowed) http://www.dslreports.com/speedtest/545449 I then changed to use "fiber" instead of "coax" (I have no idea what that changes in the test): http://www.dslreports.com/speedtest/545457 I get occasional delay spikes but at least 95% of the time this is kept very well under control. -- Mikael Abrahamsson email: swmike@swm.pp.se ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-05-26 11:33 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-05-19 19:17 [Bloat] dslreports and inbound rate shaping Dave Taht 2015-05-19 22:37 ` [Bloat] Fwd: " Dave Taht 2015-05-20 12:47 ` Kevin Darbyshire-Bryant 2015-05-22 14:05 ` Alan Jenkins 2015-05-25 21:39 ` jb 2015-05-26 9:13 ` Alan Jenkins 2015-05-26 11:33 ` jb 2015-05-20 13:02 ` Kevin Darbyshire-Bryant 2015-05-21 16:21 ` [Bloat] [Cake] " Jonathan Morton 2015-05-21 15:07 ` Kathleen Nichols 2015-05-21 15:26 ` Jonathan Morton 2015-05-21 16:31 ` Kathleen Nichols 2015-05-21 16:39 ` Jonathan Morton 2015-05-22 3:41 ` Aaron Wood 2015-05-22 6:32 ` Jonathan Morton 2015-05-22 10:57 ` Kevin Darbyshire-Bryant 2015-05-22 11:07 ` Jonathan Morton 2015-05-22 11:16 ` Kevin Darbyshire-Bryant 2015-05-25 11:26 ` [Bloat] " Mikael Abrahamsson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox