Hi Jonathan,
Great work. @Dave is there a cerowrt or openwrt build around that includes cake?
On March 17, 2015 9:08:39 PM GMT+01:00, Jonathan Morton
wrote:
>After far too long, it looks like I’ll have the opportunity to work on
>sch_cake a bit more. So here’s a little bit of a “state of the
Hi Dave,
On March 17, 2015 11:38:10 PM GMT+01:00, Dave Taht wrote:
>now in mainline openwrt chaos calmer is a version of sqm-scripts that
>will
>allow for the use of cake or cake2, if you have iproute2 support for it
>(which is not mainlined). It simplifies the sqm-scripts code
>dramatically.
Hi David,
On March 18, 2015 5:34:30 AM GMT+01:00, "David P. Reed" wrote:
>It is not the cable modem itself that is bufferbloated. It is the head
>end working with the cable modem. Docsis 3 has mechanisms to avoid
>queue buildup but they are turned on by the head end.
I seem to recall tha
> I wonder, are the low priority classes configured with a guaranteed minimum
> bandwidth to avoid starvation? And will they opportunistically grab all left
> over bandwidth to fill the pipe? Then speed test should just work as long as
> there is no competing traffic…
The problem is that, in th
Hi Jonathan,
On Mar 18, 2015, at 09:41 , Jonathan Morton wrote:
>> I wonder, are the low priority classes configured with a guaranteed minimum
>> bandwidth to avoid starvation? And will they opportunistically grab all left
>> over bandwidth to fill the pipe? Then speed test should just work as
> On Mar 18, 2015, at 2:26 AM, Jonathan Morton wrote:
>
> DOCSIS 3.1 mandates support for AQM (at minimum the PIE algorithm) in both
> CPE and head end. If you can get hold of a D3.1 modem […].
>
That last part might involve robbing the house of a Comcast employee... ;)
http://www.lightread
Right, so until 3.1 modems actually become available, it's probably best to
stick with a modem that already supports your subscribed speed, and manage
the bloat separately with shaping and AQM.
- Jonathan Morton
___
Cerowrt-devel mailing list
Cerowrt-dev
http://www.engineering.columbia.edu/new-technology-may-double-radio-frequency-data-capacity-0
(also being discussed on slashdot)
I think there was some other full duplex technology developed at stanford
discussed about 6 months back?
--
Dave Täht
Let's make wifi fast, less jittery and reliable
http://www.gizmag.com/full-duplex-wireless-radio-integrated-circuit/36580/
yes, stanford. things are looking up
On Wed, Mar 18, 2015 at 12:50 PM, Dave Taht wrote:
>
>
> http://www.engineering.columbia.edu/new-technology-may-double-radio-frequency-data-capacity-0
>
> (also being discussed on
was pretty bemused by this thread.
https://lists.openwrt.org/pipermail/openwrt-users/2015-March/003554.html
--
Dave Täht
Let's make wifi fast, less jittery and reliable again!
https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
___
Cer
Hi Seb
I tested shaping on eth1 vs pppoe-wan, as it applies to ADSL. (On
Barrier Breaker + sqm-scripts). Maybe this is going back a bit & no
longer interesting to read. But it seemed suspicious & interesting
enough that I wanted to test it.
My conclusion was 1) I should stick with pppoe-w
Yes, I recognise that behaviour from when I didn't have the timer
resolution workaround in cake. The PowerBook was fine (modern hardware,
good timers) but the Pentium-MMX only has the basic PC-AT timer hardware,
operating at 1kHz.
Because ack packets end up spaced the same way, it affects download
On Wed, 18 Mar 2015, Alan Jenkins wrote:
Once SQM on ge00 actually dives into the PPPoE packets and
applies/tests u32 filters the LUL increases to be almost identical to
pppoe-ge00’s if both ingress and egress classification are active and
do work. So it looks like the u32 filters I naively set
On Wed, Mar 18, 2015 at 7:43 PM, David Lang wrote:
> On Wed, 18 Mar 2015, Alan Jenkins wrote:
>
>>> Once SQM on ge00 actually dives into the PPPoE packets and
>>> applies/tests u32 filters the LUL increases to be almost identical to
>>> pppoe-ge00’s if both ingress and egress classification are ac
14 matches
Mail list logo
