Discussion:
SQM Question #5: Link Layer Adaptation Overheads
(too old to reply)
Rich Brown
2014-01-04 18:16:37 UTC
Permalink
QUESTION #5: I still don’t have any great answers for the Link Layer Adaptation overhead descriptions and recommendations. In an earlier message, (see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html and following messages), Fred Stratton described the overheads carried by various options, and Sebastian Moeller also gave some useful advice.

After looking at the options, I despair of giving people a clear recommendation that would be optimal for their equipment. Consequently, I believe the best we can do is come up with “good enough” recommendations that are not wrong, and still give decent performance.

In this spirit, I have changed Draft #3 of the “Setting up SQM” page to reflect this understanding. See http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310

ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed): Choose “None (default)”, and set Per Packet Overhead to 0

NB: I have changed the first menu choice to “ADSL/ATM” and the second to “VDSL” in the description. I would ask that we change to GUI to reflect those names as well. This makes it far easier/less confusing to talk about the options.

As always, I welcome help in setting out clear recommendations that work well for the vast majority of people who try CeroWrt. Thanks.

Rich
Fred Stratton
2014-01-04 18:40:49 UTC
Permalink
Link Names:

For consistency, if ADSL is used as a portmanteau term, them VDSL should
be used as the equivalent for VDSL and VDSL2.

CeroWRT has to decide whether it is an experimental build, or something
that will eventually be used in production, so these decisions can be
made consistently.

I concur with your ADSL setup suggestion as default. I have been running
the Sebastian Moeller ping script overnight to calculate ADSL overhead
for the last several days. After several hours of curve fitting using
Octave, an overhead result is displayed. This novel approach works well.

The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.

The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer Adaptation overhead descriptions and recommendations. In an earlier message, (see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html and following messages), Fred Stratton described the overheads carried by various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear recommendation that would be optimal for their equipment. Consequently, I believe the best we can do is come up with “good enough” recommendations that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to reflect this understanding. See http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to “VDSL” in the description. I would ask that we change to GUI to reflect those names as well. This makes it far easier/less confusing to talk about the options.
As always, I welcome help in setting out clear recommendations that work well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Dave Taht
2014-01-06 03:29:47 UTC
Permalink
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.

Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.

As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel

So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.

Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
Fred Stratton
2014-01-06 09:52:03 UTC
Permalink
I have been operating the latest build with 6relayd disabled. The henet
/48 I have been allocated is subnetted correctly, presumably by dnsmasq.

I adopted the suggestions to use nfq_codel and an egress target of 25ms
, with an overhead of 40 on a PPPoE connection. I chose to watch the
first 2 episodes of the 3 part third series of 'Sherlock', live on
iPlayer, and these streamed correctly and uninterrupted for 90 minutes.
This was not previously possible. (Quite whether they were up to the
standard of previous episodes is another matter.)

I can watch iPlayer with little stutter whilst downloading Arch Linux by
torrent, downloading other files at the same time.

So, for a relatively slow ADSL2+ line, the current build works well.
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Sebastian Moeller
2014-01-06 14:12:21 UTC
Permalink
Hi Fred,
I have been operating the latest build with 6relayd disabled. The henet /48 I have been allocated is subnetted correctly, presumably by dnsmasq.
I adopted the suggestions to use nfq_codel and an egress target of 25ms , with an overhead of 40 on a PPPoE connection. I chose to watch the first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer, and these streamed correctly and uninterrupted for 90 minutes. This was not previously possible. (Quite whether they were up to the standard of previous episodes is another matter.)
I can watch iPlayer with little stutter whilst downloading Arch Linux by torrent, downloading other files at the same time.
So, for a relatively slow ADSL2+ line, the current build works well.
Out of curiosity, to what percentage of the "current line rate" (you know the one reported by your modem) you shaped up- and downlink? And in case you have too much time on your hand, how does the same feel with an overhead of 10 (to see how bad an overhead underestimate would feel for a user), since you currently happen to have a quite sensitive subjective latency evaluation system set up :)…

Best Regards
Sebastian
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Fred Stratton
2014-01-06 14:22:09 UTC
Permalink
The line rate is 11744/1022 kb/s, but changes moment to moment. SNR is
12.1 decibel. I am using 11000/950 kb/s as settings. I shall try your
suggestion when there is something worth watching live, to provide a
valid comparison, which may not be before 21:30 CET on Sunday.
Post by Sebastian Moeller
Hi Fred,
I have been operating the latest build with 6relayd disabled. The henet /48 I have been allocated is subnetted correctly, presumably by dnsmasq.
I adopted the suggestions to use nfq_codel and an egress target of 25ms , with an overhead of 40 on a PPPoE connection. I chose to watch the first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer, and these streamed correctly and uninterrupted for 90 minutes. This was not previously possible. (Quite whether they were up to the standard of previous episodes is another matter.)
I can watch iPlayer with little stutter whilst downloading Arch Linux by torrent, downloading other files at the same time.
So, for a relatively slow ADSL2+ line, the current build works well.
Out of curiosity, to what percentage of the "current line rate" (you know the one reported by your modem) you shaped up- and downlink? And in case you have too much time on your hand, how does the same feel with an overhead of 10 (to see how bad an overhead underestimate would feel for a user), since you currently happen to have a quite sensitive subjective latency evaluation system set up :)…
Best Regards
Sebastian
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Sebastian Moeller
2014-01-06 14:27:56 UTC
Permalink
Hi Fred,
The line rate is 11744/1022 kb/s, but changes moment to moment. SNR is 12.1 decibel. I am using 11000/950 kb/s as settings.
So 100 * 11000 / 11744 = 93.66% of downlink line rate and 100* 950 / 1022 = 92.95 % of uplink line rate; quite impressive given the common wisdom of 85% :).
I shall try your suggestion when there is something worth watching live, to provide a valid comparison, which may not be before 21:30 CET on Sunday.
Oh, take your time, this is really not essential, butit would be a nice data point for figuring out how important the correct overhead estimate really is in real life, theory being theory and all…

Best Regards
Sebastian
Post by Sebastian Moeller
Hi Fred,
I have been operating the latest build with 6relayd disabled. The henet /48 I have been allocated is subnetted correctly, presumably by dnsmasq.
I adopted the suggestions to use nfq_codel and an egress target of 25ms , with an overhead of 40 on a PPPoE connection. I chose to watch the first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer, and these streamed correctly and uninterrupted for 90 minutes. This was not previously possible. (Quite whether they were up to the standard of previous episodes is another matter.)
I can watch iPlayer with little stutter whilst downloading Arch Linux by torrent, downloading other files at the same time.
So, for a relatively slow ADSL2+ line, the current build works well.
Out of curiosity, to what percentage of the "current line rate" (you know the one reported by your modem) you shaped up- and downlink? And in case you have too much time on your hand, how does the same feel with an overhead of 10 (to see how bad an overhead underestimate would feel for a user), since you currently happen to have a quite sensitive subjective latency evaluation system set up :)…
Best Regards
Sebastian
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
David Personette
2014-01-07 11:08:27 UTC
Permalink
I'm in the US, but live in a relatively rural area. My only internet
options are DSL and satellite. The local provider is Century Link (it used
to be Sprint, but they sold their copper phone business off). I have the
fastest service that they offer (based on distance from the DSLAM), 4 down
/ .5 up.

I have had SmokePing monitoring my latency to the first hop outside my
network for over a year now (I've been on CeroWRT the whole time). My
baseline (no load) latency is 31ms. I used to have AQM throttling back to
80% of my already pathetic bandwidth. I would still regularly see periods
lasting minutes to hours when latency would be 80 - 120ms.

I only recently grokked what you were talking about with tc_stab since I
got back from the holidays with the family, I set things up as you
suggested for Fred (nfq_codel, "target 25ms" in advanced egress, ATM, per
packet overhead 40, and set my SQM bandwidth limits to 95%). Since the 30th
my "worst case" latency has been 41ms. Plus I get to use more of my actual
bandwidth. I REALLY wish that I'd made the time to read your emails about
setting up the ATM overhead earlier.

Thank you.
--
David P.
Post by Sebastian Moeller
Hi Fred,
Post by Fred Stratton
The line rate is 11744/1022 kb/s, but changes moment to moment. SNR is
12.1 decibel. I am using 11000/950 kb/s as settings.
So 100 * 11000 / 11744 = 93.66% of downlink line rate and 100* 950
/ 1022 = 92.95 % of uplink line rate; quite impressive given the common
wisdom of 85% :).
Post by Fred Stratton
I shall try your suggestion when there is something worth watching
live, to provide a valid comparison, which may not be before 21:30 CET on
Sunday.
Oh, take your time, this is really not essential, butit would be a
nice data point for figuring out how important the correct overhead
estimate really is in real life, theory being theory and all

Best Regards
Sebastian
Post by Fred Stratton
Post by Sebastian Moeller
Hi Fred,
Post by Fred Stratton
I have been operating the latest build with 6relayd disabled. The
henet /48 I have been allocated is subnetted correctly, presumably by
dnsmasq.
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I adopted the suggestions to use nfq_codel and an egress target of
25ms , with an overhead of 40 on a PPPoE connection. I chose to watch the
first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer,
and these streamed correctly and uninterrupted for 90 minutes. This was
not previously possible. (Quite whether they were up to the standard of
previous episodes is another matter.)
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I can watch iPlayer with little stutter whilst downloading Arch Linux
by torrent, downloading other files at the same time.
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
So, for a relatively slow ADSL2+ line, the current build works well.
Out of curiosity, to what percentage of the "current line rate"
(you know the one reported by your modem) you shaped up- and downlink? And
in case you have too much time on your hand, how does the same feel with an
overhead of 10 (to see how bad an overhead underestimate would feel for a
user), since you currently happen to have a quite sensitive subjective
latency evaluation system set up :)

Post by Fred Stratton
Post by Sebastian Moeller
Best Regards
Sebastian
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
For consistency, if ADSL is used as a portmanteau term, them VDSL
should be
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or
something that
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
Post by Fred Stratton
I concur with your ADSL setup suggestion as default. I have been
running the
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
Sebastian Moeller ping script overnight to calculate ADSL overhead
for the
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
last several days. After several hours of curve fitting using
Octave, an
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
Post by Fred Stratton
The overhead for the particular setup I use was 40 for PPPoE, and 10
for
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
PPPoA.
The default you suggest is a suitable starting point, I suggest.
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier
message,
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
and following messages), Fred Stratton described the overheads
carried by
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment.
Consequently, I
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
believe the best we can do is come up with “good enough”
recommendations
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM”
page to
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet
Overhead to
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the
second to
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
“VDSL” in the description. I would ask that we change to GUI to
reflect
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
those names as well. This makes it far easier/less confusing to
talk about
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
the options.
As always, I welcome help in setting out clear recommendations that
work
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Sebastian Moeller
2014-01-07 11:34:52 UTC
Permalink
Hi David,
I'm in the US, but live in a relatively rural area. My only internet options are DSL and satellite. The local provider is Century Link (it used to be Sprint, but they sold their copper phone business off). I have the fastest service that they offer (based on distance from the DSLAM), 4 down / .5 up.
And you are not alone, a considerable percentage of the population wherever you look is hanging on such connections. So cerowrt should really help those folk as well as luckier ones.
I have had SmokePing monitoring my latency to the first hop outside my network for over a year now (I've been on CeroWRT the whole time). My baseline (no load) latency is 31ms. I used to have AQM throttling back to 80% of my already pathetic bandwidth. I would still regularly see periods lasting minutes to hours when latency would be 80 - 120ms.
I only recently grokked what you were talking about with tc_stab since I got back from the holidays with the family, I set things up as you suggested for Fred (nfq_codel, "target 25ms" in advanced egress, ATM, per packet overhead 40,
The exact number depends on the encapsulation your ISP uses, 40 is right for a typical PPPoE over LLC/SNAP connection, if that is correct for your link you are fine, otherwise contact me if you want to empirically find out the proper value for your link.
and set my SQM bandwidth limits to 95%). Since the 30th my "worst case" latency has been 41ms.
the fq_codels really are great if in control of the bottleneck, really good work by bright people!
Plus I get to use more of my actual bandwidth.
Well, that I am not so sure. By enabling link layer ATM the router will automatically take care of the ATM cell overhead for you (basically reducing the effective rate to ~90% of the link, in other words you get the same effect by shaping to 90%). It will also handle the per packet overhead and the nasty potential padding of the last ATM cell (both have a stronger effect on small packets and are hard to actually account for by static rate reduction; link layer ATM comes again to the rescue by taking these two into account individually for each packet based on the packet size). So effectively 95% with link layer adjustments might mean a lower wire rate than 80% without; the important thing is that with the link layer adjustments the link capacity is estimated correctly avoiding the modem's and the DSLAM's buffers to fill and cause buffer bloat.
I REALLY wish that I'd made the time to read your emails about setting up the ATM overhead earlier.
Oh, I can understand, when I learned about this some years ago (by stumbling over Russel Stuart's website and Jesper Brouer's thesis) it immediate changed my internet experience (I was on a 3 down / 0.5 up connection at that time). :)

Best Regards
Sebastian
Thank you.
--
David P.
Hi Fred,
The line rate is 11744/1022 kb/s, but changes moment to moment. SNR is 12.1 decibel. I am using 11000/950 kb/s as settings.
So 100 * 11000 / 11744 = 93.66% of downlink line rate and 100* 950 / 1022 = 92.95 % of uplink line rate; quite impressive given the common wisdom of 85% :).
I shall try your suggestion when there is something worth watching live, to provide a valid comparison, which may not be before 21:30 CET on Sunday.
Oh, take your time, this is really not essential, butit would be a nice data point for figuring out how important the correct overhead estimate really is in real life, theory being theory and all…
Best Regards
Sebastian
Post by Sebastian Moeller
Hi Fred,
I have been operating the latest build with 6relayd disabled. The henet /48 I have been allocated is subnetted correctly, presumably by dnsmasq.
I adopted the suggestions to use nfq_codel and an egress target of 25ms , with an overhead of 40 on a PPPoE connection. I chose to watch the first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer, and these streamed correctly and uninterrupted for 90 minutes. This was not previously possible. (Quite whether they were up to the standard of previous episodes is another matter.)
I can watch iPlayer with little stutter whilst downloading Arch Linux by torrent, downloading other files at the same time.
So, for a relatively slow ADSL2+ line, the current build works well.
Out of curiosity, to what percentage of the "current line rate" (you know the one reported by your modem) you shaped up- and downlink? And in case you have too much time on your hand, how does the same feel with an overhead of 10 (to see how bad an overhead underestimate would feel for a user), since you currently happen to have a quite sensitive subjective latency evaluation system set up :)…
Best Regards
Sebastian
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
David Personette
2014-01-07 12:11:35 UTC
Permalink
I was going to test the recommended bridge settings for overhead (32 IIRC),
because as far as I can tell there is no PPPoE involved. I've never seen it
in the modems config (in the brief period it has an IP before I put it in
bridge mode as well so the routable IP goes to my actual router), or needed
to configure it on my router.

I am seeing my effective bandwidth be higher by about 50/KBs on downloads.
On Netflix, my Roku used to try HD upon starting playback then (after 20-30
seconds thinking about it) fail back to SD, but now the HD streams are
working flawlessly for hours.
--
David P.
Post by Sebastian Moeller
Hi David,
Post by David Personette
I'm in the US, but live in a relatively rural area. My only internet
options are DSL and satellite. The local provider is Century Link (it used
to be Sprint, but they sold their copper phone business off). I have the
fastest service that they offer (based on distance from the DSLAM), 4 down
/ .5 up.
And you are not alone, a considerable percentage of the population
wherever you look is hanging on such connections. So cerowrt should really
help those folk as well as luckier ones.
Post by David Personette
I have had SmokePing monitoring my latency to the first hop outside my
network for over a year now (I've been on CeroWRT the whole time). My
baseline (no load) latency is 31ms. I used to have AQM throttling back to
80% of my already pathetic bandwidth. I would still regularly see periods
lasting minutes to hours when latency would be 80 - 120ms.
Post by David Personette
I only recently grokked what you were talking about with tc_stab since I
got back from the holidays with the family, I set things up as you
suggested for Fred (nfq_codel, "target 25ms" in advanced egress, ATM, per
packet overhead 40,
The exact number depends on the encapsulation your ISP uses, 40 is
right for a typical PPPoE over LLC/SNAP connection, if that is correct for
your link you are fine, otherwise contact me if you want to empirically
find out the proper value for your link.
Post by David Personette
and set my SQM bandwidth limits to 95%). Since the 30th my "worst case"
latency has been 41ms.
the fq_codels really are great if in control of the bottleneck,
really good work by bright people!
Post by David Personette
Plus I get to use more of my actual bandwidth.
Well, that I am not so sure. By enabling link layer ATM the router
will automatically take care of the ATM cell overhead for you (basically
reducing the effective rate to ~90% of the link, in other words you get the
same effect by shaping to 90%). It will also handle the per packet overhead
and the nasty potential padding of the last ATM cell (both have a stronger
effect on small packets and are hard to actually account for by static rate
reduction; link layer ATM comes again to the rescue by taking these two
into account individually for each packet based on the packet size). So
effectively 95% with link layer adjustments might mean a lower wire rate
than 80% without; the important thing is that with the link layer
adjustments the link capacity is estimated correctly avoiding the modem's
and the DSLAM's buffers to fill and cause buffer bloat.
Post by David Personette
I REALLY wish that I'd made the time to read your emails about setting
up the ATM overhead earlier.
Oh, I can understand, when I learned about this some years ago (by
stumbling over Russel Stuart's website and Jesper Brouer's thesis) it
immediate changed my internet experience (I was on a 3 down / 0.5 up
connection at that time). :)
Best Regards
Sebastian
Post by David Personette
Thank you.
--
David P.
Hi Fred,
Post by Fred Stratton
The line rate is 11744/1022 kb/s, but changes moment to moment. SNR is
12.1 decibel. I am using 11000/950 kb/s as settings.
Post by David Personette
So 100 * 11000 / 11744 = 93.66% of downlink line rate and 100*
950 / 1022 = 92.95 % of uplink line rate; quite impressive given the common
wisdom of 85% :).
Post by David Personette
Post by Fred Stratton
I shall try your suggestion when there is something worth watching
live, to provide a valid comparison, which may not be before 21:30 CET on
Sunday.
Post by David Personette
Oh, take your time, this is really not essential, butit would be
a nice data point for figuring out how important the correct overhead
estimate really is in real life, theory being theory and all

Post by David Personette
Best Regards
Sebastian
Post by Fred Stratton
Post by Sebastian Moeller
Hi Fred,
Post by Fred Stratton
I have been operating the latest build with 6relayd disabled. The
henet /48 I have been allocated is subnetted correctly, presumably by
dnsmasq.
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I adopted the suggestions to use nfq_codel and an egress target of
25ms , with an overhead of 40 on a PPPoE connection. I chose to watch the
first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer,
and these streamed correctly and uninterrupted for 90 minutes. This was
not previously possible. (Quite whether they were up to the standard of
previous episodes is another matter.)
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I can watch iPlayer with little stutter whilst downloading Arch
Linux by torrent, downloading other files at the same time.
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
So, for a relatively slow ADSL2+ line, the current build works well.
Out of curiosity, to what percentage of the "current line rate"
(you know the one reported by your modem) you shaped up- and downlink? And
in case you have too much time on your hand, how does the same feel with an
overhead of 10 (to see how bad an overhead underestimate would feel for a
user), since you currently happen to have a quite sensitive subjective
latency evaluation system set up :)

Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Best Regards
Sebastian
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
For consistency, if ADSL is used as a portmanteau term, them VDSL
should be
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or
something that
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
will eventually be used in production, so these decisions can be
made
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
consistently.
Well, what I was aiming for was for us to get the sqm scripts and
gui
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
up to where they were better than the standard openwrt qos scripts
and
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui,
we
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
are there. Except that nfq_codel is currently getting better
results
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those
primarily
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero
in
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting
a
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
test suite going is next on my day job.
Post by Fred Stratton
I concur with your ADSL setup suggestion as default. I have been
running the
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
Sebastian Moeller ping script overnight to calculate ADSL overhead
for the
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
last several days. After several hours of curve fitting using
Octave, an
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router
using
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
tools like these with no human intervention. This includes bandwidth
estimation.
Post by Fred Stratton
The overhead for the particular setup I use was 40 for PPPoE, and
10 for
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
PPPoA.
The default you suggest is a suitable starting point, I suggest.
QUESTION #5: I still don’t have any great answers for the Link
Layer
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
Adaptation overhead descriptions and recommendations. In an
earlier message,
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
and following messages), Fred Stratton described the overheads
carried by
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
various options, and Sebastian Moeller also gave some useful
advice.
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment.
Consequently, I
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
believe the best we can do is come up with “good enough”
recommendations
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM”
page to
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet
Overhead to
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to
8
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
Other kind of link (e.g., Cable, Fiber, Ethernet, other
not
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the
second to
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
“VDSL” in the description. I would ask that we change to GUI to
reflect
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
those names as well. This makes it far easier/less confusing to
talk about
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
the options.
As always, I welcome help in setting out clear recommendations
that work
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Dave Taht
Post by Fred Stratton
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Sebastian Moeller
2014-01-07 13:02:22 UTC
Permalink
Hi David,
I was going to test the recommended bridge settings for overhead (32 IIRC), because as far as I can tell there is no PPPoE involved. I've never seen it in the modems config (in the brief period it has an IP before I put it in bridge mode as well so the routable IP goes to my actual router), or needed to configure it on my router.
Ah, so there are 2 major variations of "bridged":
1) LLC/SNAP: Bridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding)
2) VC-MUX: Bridged - 24 (ATM - 10, ethernet 14, possibly FCS - 4+padding)
(he FCS padding potentially turns this into 4 variations, but it should be really rare, or so I heard).

You could just slowly reduce the overhead and see how the link behaves; honestly I do not know how prominent a slight overhead underestimate would feel, so by all means go ahead and try :). If you have a mac or linux computer on your network, you could try to measure the overhead with the attached ping_sweeper5_dp.sh script (needs editing). Then you could run tc_stab_parameter_guide_04.m in matlab or octave (on the matlab command prompt change into the directory containing the script and the log file run "[ tmp ] = tc_stab_parameter_guide_04( fullfile(pwd, 'ping_sweep_ADSL2_20140104_122844.txt'))" ; make sure to replace ping_sweep_ADSL2_20140104_122844.txt with the name of your log file. The measurement will take around 3 hours (for 10000 samples per size, for your link 1000 would be enough) and wants an undisturbed network (I typically run this over night); the parsing of the log file will also consume 20 minutes or more, the actual analysis will take a few seconds…
If you go that route I would love it if you could share your log file, since I only have one old bridged LLC/SNAP example. (I intend to put all scripts and an instruction on the wiki, with example plots for the different results).


Best Regards
Sebastian
David Personette
2014-01-07 13:43:15 UTC
Permalink
Hi Sebastian,

I have both Linux and Mac (all my systems are Linux, the Mac is my work
laptop). I don't have Matlab, so I'll try to get it working in Octave
(haven't really used it before). If it's something that can help others in
the community, then I'll definitely run it. Assuming that I don't forget,
I'll run it tonight and have it for you tomorrow. Thanks for the clear
explanations.
--
David P.
Post by Sebastian Moeller
Hi David,
Post by David Personette
I was going to test the recommended bridge settings for overhead (32
IIRC), because as far as I can tell there is no PPPoE involved. I've never
seen it in the modems config (in the brief period it has an IP before I put
it in bridge mode as well so the routable IP goes to my actual router), or
needed to configure it on my router.
1) LLC/SNAP: Bridged - 32 (ATM - 18, ethernet 14, possibly FCS
- 4+padding)
2) VC-MUX: Bridged - 24 (ATM - 10, ethernet 14, possibly FCS -
4+padding)
(he FCS padding potentially turns this into 4 variations, but it should be
really rare, or so I heard).
You could just slowly reduce the overhead and see how the link
behaves; honestly I do not know how prominent a slight overhead
underestimate would feel, so by all means go ahead and try :). If you have
a mac or linux computer on your network, you could try to measure the
overhead with the attached ping_sweeper5_dp.sh script (needs editing). Then
you could run tc_stab_parameter_guide_04.m in matlab or octave (on the
matlab command prompt change into the directory containing the script and
the log file run "[ tmp ] = tc_stab_parameter_guide_04( fullfile(pwd,
'ping_sweep_ADSL2_20140104_122844.txt'))" ; make sure to replace
ping_sweep_ADSL2_20140104_122844.txt with the name of your log file. The
measurement will take around 3 hours (for 10000 samples per size, for your
link 1000 would be enough) and wants an undisturbed network (I typically
run this over night); the parsing of the log file will also consume 20
minutes or more, the actual analysis will take a few seconds

If you go that route I would love it if you could share your log
file, since I only have one old bridged LLC/SNAP example. (I intend to put
all scripts and an instruction on the wiki, with example plots for the
different results).
Best Regards
Sebastian
Post by David Personette
I am seeing my effective bandwidth be higher by about 50/KBs on
downloads. On Netflix, my Roku used to try HD upon starting playback then
(after 20-30 seconds thinking about it) fail back to SD, but now the HD
streams are working flawlessly for hours.
Post by David Personette
--
David P.
Hi David,
Post by David Personette
I'm in the US, but live in a relatively rural area. My only internet
options are DSL and satellite. The local provider is Century Link (it used
to be Sprint, but they sold their copper phone business off). I have the
fastest service that they offer (based on distance from the DSLAM), 4 down
/ .5 up.
Post by David Personette
And you are not alone, a considerable percentage of the
population wherever you look is hanging on such connections. So cerowrt
should really help those folk as well as luckier ones.
Post by David Personette
Post by David Personette
I have had SmokePing monitoring my latency to the first hop outside my
network for over a year now (I've been on CeroWRT the whole time). My
baseline (no load) latency is 31ms. I used to have AQM throttling back to
80% of my already pathetic bandwidth. I would still regularly see periods
lasting minutes to hours when latency would be 80 - 120ms.
Post by David Personette
Post by David Personette
I only recently grokked what you were talking about with tc_stab since
I got back from the holidays with the family, I set things up as you
suggested for Fred (nfq_codel, "target 25ms" in advanced egress, ATM, per
packet overhead 40,
Post by David Personette
The exact number depends on the encapsulation your ISP uses, 40
is right for a typical PPPoE over LLC/SNAP connection, if that is correct
for your link you are fine, otherwise contact me if you want to empirically
find out the proper value for your link.
Post by David Personette
Post by David Personette
and set my SQM bandwidth limits to 95%). Since the 30th my "worst
case" latency has been 41ms.
Post by David Personette
the fq_codels really are great if in control of the bottleneck,
really good work by bright people!
Post by David Personette
Post by David Personette
Plus I get to use more of my actual bandwidth.
Well, that I am not so sure. By enabling link layer ATM the
router will automatically take care of the ATM cell overhead for you
(basically reducing the effective rate to ~90% of the link, in other words
you get the same effect by shaping to 90%). It will also handle the per
packet overhead and the nasty potential padding of the last ATM cell (both
have a stronger effect on small packets and are hard to actually account
for by static rate reduction; link layer ATM comes again to the rescue by
taking these two into account individually for each packet based on the
packet size). So effectively 95% with link layer adjustments might mean a
lower wire rate than 80% without; the important thing is that with the link
layer adjustments the link capacity is estimated correctly avoiding the
modem's and the DSLAM's buffers to fill and cause buffer bloat.
Post by David Personette
Post by David Personette
I REALLY wish that I'd made the time to read your emails about setting
up the ATM overhead earlier.
Post by David Personette
Oh, I can understand, when I learned about this some years ago
(by stumbling over Russel Stuart's website and Jesper Brouer's thesis) it
immediate changed my internet experience (I was on a 3 down / 0.5 up
connection at that time). :)
Post by David Personette
Best Regards
Sebastian
Post by David Personette
Thank you.
--
David P.
Hi Fred,
Post by Fred Stratton
The line rate is 11744/1022 kb/s, but changes moment to moment. SNR
is 12.1 decibel. I am using 11000/950 kb/s as settings.
Post by David Personette
Post by David Personette
So 100 * 11000 / 11744 = 93.66% of downlink line rate and 100*
950 / 1022 = 92.95 % of uplink line rate; quite impressive given the common
wisdom of 85% :).
Post by David Personette
Post by David Personette
Post by Fred Stratton
I shall try your suggestion when there is something worth watching
live, to provide a valid comparison, which may not be before 21:30 CET on
Sunday.
Post by David Personette
Post by David Personette
Oh, take your time, this is really not essential, butit would
be a nice data point for figuring out how important the correct overhead
estimate really is in real life, theory being theory and all

Post by David Personette
Post by David Personette
Best Regards
Sebastian
Post by Fred Stratton
Post by Sebastian Moeller
Hi Fred,
Post by Fred Stratton
I have been operating the latest build with 6relayd disabled. The
henet /48 I have been allocated is subnetted correctly, presumably by
dnsmasq.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I adopted the suggestions to use nfq_codel and an egress target of
25ms , with an overhead of 40 on a PPPoE connection. I chose to watch the
first 2 episodes of the 3 part third series of 'Sherlock', live on iPlayer,
and these streamed correctly and uninterrupted for 90 minutes. This was
not previously possible. (Quite whether they were up to the standard of
previous episodes is another matter.)
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I can watch iPlayer with little stutter whilst downloading Arch
Linux by torrent, downloading other files at the same time.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
So, for a relatively slow ADSL2+ line, the current build works
well.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Out of curiosity, to what percentage of the "current line
rate" (you know the one reported by your modem) you shaped up- and
downlink? And in case you have too much time on your hand, how does the
same feel with an overhead of 10 (to see how bad an overhead underestimate
would feel for a user), since you currently happen to have a quite
sensitive subjective latency evaluation system set up :)

Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Best Regards
Sebastian
Post by Fred Stratton
On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton
Post by Fred Stratton
For consistency, if ADSL is used as a portmanteau term, them
VDSL should be
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or
something that
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
will eventually be used in production, so these decisions can be
made
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
consistently.
Well, what I was aiming for was for us to get the sqm scripts and
gui
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
up to where they were better than the standard openwrt qos
scripts and
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the
gui, we
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
are there. Except that nfq_codel is currently getting better
results
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt
to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those
primarily
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6,
cero in
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and
getting a
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
test suite going is next on my day job.
Post by Fred Stratton
I concur with your ADSL setup suggestion as default. I have been
running the
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
Sebastian Moeller ping script overnight to calculate ADSL
overhead for the
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
last several days. After several hours of curve fitting using
Octave, an
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router
using
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
tools like these with no human intervention. This includes
bandwidth
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
estimation.
Post by Fred Stratton
The overhead for the particular setup I use was 40 for PPPoE,
and 10 for
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
PPPoA.
The default you suggest is a suitable starting point, I suggest.
QUESTION #5: I still don’t have any great answers for the Link
Layer
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
Adaptation overhead descriptions and recommendations. In an
earlier message,
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
and following messages), Fred Stratton described the overheads
carried by
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
various options, and Sebastian Moeller also gave some useful
advice.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment.
Consequently, I
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
believe the best we can do is come up with “good enough”
recommendations
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM”
page to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet
Overhead to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead
to 8
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
Other kind of link (e.g., Cable, Fiber, Ethernet, other
not
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
listed): Choose “None (default)”, and set Per Packet Overhead
to 0
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
NB: I have changed the first menu choice to “ADSL/ATM” and the
second to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
“VDSL” in the description. I would ask that we change to GUI to
reflect
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
those names as well. This makes it far easier/less confusing to
talk about
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
the options.
As always, I welcome help in setting out clear recommendations
that work
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Fred Stratton
2014-01-07 14:53:11 UTC
Permalink
Some comments about procedure. I mention the distro I currently use, so
one aspect is distro specific:

Choose a server which actually returns pings. I used 'mtr' on one run to
choose a server, but did not check it with ping. A mistake.

The data collection run took circa 5 hours. The resultant data file is
at ~/ , as you would expect.

Octave has a graphical front end to manipulate it, qtOctave, available
via Ubuntu Software Centre. I ran this combo under Ubuntu 13.10, on a
NUC with a Sandy Bridge Celeron processor. The parsing of the data file
took 5-6 hours, and the actual calculation 20 or 30 seconds at the end.
The initial process produces a *.mat file, so, if required,
recalculation time is short.

You will appreciate that linux systems produce graphs that are not
necessarily easily saved. I used the Print Screen key and trimmed the
*.png file with a graphics program -Pinta.
Post by David Personette
Hi Sebastian,
I have both Linux and Mac (all my systems are Linux, the Mac is my
work laptop). I don't have Matlab, so I'll try to get it working in
Octave (haven't really used it before). If it's something that can
help others in the community, then I'll definitely run it. Assuming
that I don't forget, I'll run it tonight and have it for you tomorrow.
Thanks for the clear explanations.
--
David P.
Hi David,
Post by David Personette
I was going to test the recommended bridge settings for overhead
(32 IIRC), because as far as I can tell there is no PPPoE
involved. I've never seen it in the modems config (in the brief
period it has an IP before I put it in bridge mode as well so the
routable IP goes to my actual router), or needed to configure it
on my router.
1) LLC/SNAP: Bridged - 32 (ATM - 18, ethernet 14,
possibly FCS - 4+padding)
2) VC-MUX: Bridged - 24 (ATM - 10, ethernet 14, possibly FCS
- 4+padding)
(he FCS padding potentially turns this into 4 variations, but it
should be really rare, or so I heard).
You could just slowly reduce the overhead and see how the
link behaves; honestly I do not know how prominent a slight
overhead underestimate would feel, so by all means go ahead and
try :). If you have a mac or linux computer on your network, you
could try to measure the overhead with the attached
ping_sweeper5_dp.sh script (needs editing). Then you could run
tc_stab_parameter_guide_04.m in matlab or octave (on the matlab
command prompt change into the directory containing the script and
the log file run "[ tmp ] = tc_stab_parameter_guide_04(
fullfile(pwd, 'ping_sweep_ADSL2_20140104_122844.txt'))" ; make
sure to replace ping_sweep_ADSL2_20140104_122844.txt with the name
of your log file. The measurement will take around 3 hours (for
10000 samples per size, for your link 1000 would be enough) and
wants an undisturbed network (I typically run this over night);
the parsing of the log file will also consume 20 minutes or more,
the actual analysis will take a few seconds

If you go that route I would love it if you could share
your log file, since I only have one old bridged LLC/SNAP example.
(I intend to put all scripts and an instruction on the wiki, with
example plots for the different results).
Best Regards
Sebastian
Post by David Personette
I am seeing my effective bandwidth be higher by about 50/KBs on
downloads. On Netflix, my Roku used to try HD upon starting
playback then (after 20-30 seconds thinking about it) fail back to
SD, but now the HD streams are working flawlessly for hours.
Post by David Personette
--
David P.
On Tue, Jan 7, 2014 at 6:34 AM, Sebastian Moeller
Hi David,
Post by David Personette
I'm in the US, but live in a relatively rural area. My only
internet options are DSL and satellite. The local provider is
Century Link (it used to be Sprint, but they sold their copper
phone business off). I have the fastest service that they offer
(based on distance from the DSLAM), 4 down / .5 up.
Post by David Personette
And you are not alone, a considerable percentage of the
population wherever you look is hanging on such connections. So
cerowrt should really help those folk as well as luckier ones.
Post by David Personette
Post by David Personette
I have had SmokePing monitoring my latency to the first hop
outside my network for over a year now (I've been on CeroWRT the
whole time). My baseline (no load) latency is 31ms. I used to have
AQM throttling back to 80% of my already pathetic bandwidth. I
would still regularly see periods lasting minutes to hours when
latency would be 80 - 120ms.
Post by David Personette
Post by David Personette
I only recently grokked what you were talking about with
tc_stab since I got back from the holidays with the family, I set
things up as you suggested for Fred (nfq_codel, "target 25ms" in
advanced egress, ATM, per packet overhead 40,
Post by David Personette
The exact number depends on the encapsulation your ISP
uses, 40 is right for a typical PPPoE over LLC/SNAP connection, if
that is correct for your link you are fine, otherwise contact me
if you want to empirically find out the proper value for your link.
Post by David Personette
Post by David Personette
and set my SQM bandwidth limits to 95%). Since the 30th my
"worst case" latency has been 41ms.
Post by David Personette
the fq_codels really are great if in control of the
bottleneck, really good work by bright people!
Post by David Personette
Post by David Personette
Plus I get to use more of my actual bandwidth.
Well, that I am not so sure. By enabling link layer ATM
the router will automatically take care of the ATM cell overhead
for you (basically reducing the effective rate to ~90% of the
link, in other words you get the same effect by shaping to 90%).
It will also handle the per packet overhead and the nasty
potential padding of the last ATM cell (both have a stronger
effect on small packets and are hard to actually account for by
static rate reduction; link layer ATM comes again to the rescue by
taking these two into account individually for each packet based
on the packet size). So effectively 95% with link layer
adjustments might mean a lower wire rate than 80% without; the
important thing is that with the link layer adjustments the link
capacity is estimated correctly avoiding the modem's and the
DSLAM's buffers to fill and cause buffer bloat.
Post by David Personette
Post by David Personette
I REALLY wish that I'd made the time to read your emails about
setting up the ATM overhead earlier.
Post by David Personette
Oh, I can understand, when I learned about this some
years ago (by stumbling over Russel Stuart's website and Jesper
Brouer's thesis) it immediate changed my internet experience (I
was on a 3 down / 0.5 up connection at that time). :)
Post by David Personette
Best Regards
Sebastian
Post by David Personette
Thank you.
--
David P.
On Mon, Jan 6, 2014 at 9:27 AM, Sebastian Moeller
Hi Fred,
On Jan 6, 2014, at 15:22 , Fred Stratton
Post by Fred Stratton
The line rate is 11744/1022 kb/s, but changes moment to
moment. SNR is 12.1 decibel. I am using 11000/950 kb/s as settings.
Post by David Personette
Post by David Personette
So 100 * 11000 / 11744 = 93.66% of downlink line rate
and 100* 950 / 1022 = 92.95 % of uplink line rate; quite
impressive given the common wisdom of 85% :).
Post by David Personette
Post by David Personette
Post by Fred Stratton
I shall try your suggestion when there is something worth
watching live, to provide a valid comparison, which may not be
before 21:30 CET on Sunday.
Post by David Personette
Post by David Personette
Oh, take your time, this is really not essential,
butit would be a nice data point for figuring out how important
the correct overhead estimate really is in real life, theory being
theory and all

Post by David Personette
Post by David Personette
Best Regards
Sebastian
Post by Fred Stratton
Post by Sebastian Moeller
Hi Fred,
On Jan 6, 2014, at 10:52 , Fred Stratton
Post by Fred Stratton
I have been operating the latest build with 6relayd
disabled. The henet /48 I have been allocated is subnetted
correctly, presumably by dnsmasq.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I adopted the suggestions to use nfq_codel and an egress
target of 25ms , with an overhead of 40 on a PPPoE connection. I
chose to watch the first 2 episodes of the 3 part third series of
'Sherlock', live on iPlayer, and these streamed correctly and
uninterrupted for 90 minutes. This was not previously possible.
(Quite whether they were up to the standard of previous episodes
is another matter.)
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I can watch iPlayer with little stutter whilst downloading
Arch Linux by torrent, downloading other files at the same time.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
So, for a relatively slow ADSL2+ line, the current build
works well.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Out of curiosity, to what percentage of the "current
line rate" (you know the one reported by your modem) you shaped
up- and downlink? And in case you have too much time on your hand,
how does the same feel with an overhead of 10 (to see how bad an
overhead underestimate would feel for a user), since you currently
happen to have a quite sensitive subjective latency evaluation
system set up :)

Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Best Regards
Sebastian
Post by Fred Stratton
On Sat, Jan 4, 2014 at 10:40 AM, Fred Stratton
Post by Fred Stratton
For consistency, if ADSL is used as a portmanteau term,
them VDSL should be
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental
build, or something that
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
will eventually be used in production, so these
decisions can be made
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
consistently.
Well, what I was aiming for was for us to get the sqm
scripts and gui
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
up to where they were better than the standard openwrt
qos scripts and
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
then push them up to openwrt to where they could be more
widely
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
deployed.
Aside from being able to dynamically assign priorities in
the gui, we
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
are there. Except that nfq_codel is currently getting
better results
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
than fq_codel at low bandwidths, and I'm tempted to pour
all of
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
simple.qos into C.
As for cero's future - certainly since all the snowden
revelations
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
I've been going around saying that "friends don't let
friends run
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
factory firmware". I would like a stable build of sqm and
cerowrt to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
emerge, and to then go off and work on improving wifi.
Regrettably
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
what seems to be happening is more backwards than
forwards on the
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
former, and ramping up on the ath9k and ath10k is taking
more time
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
than I'd like, and it seems likely I'll be working on
those primarily
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
on another platform and only eventually pushing the
results out to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm,
ipv6, cero in
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero,
and getting a
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
test suite going is next on my day job.
Post by Fred Stratton
I concur with your ADSL setup suggestion as default. I
have been running the
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
Sebastian Moeller ping script overnight to calculate
ADSL overhead for the
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
last several days. After several hours of curve fitting
using Octave, an
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
overhead result is displayed. This novel approach works
well.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
It would be nice to get to where we could autoconfigure a
router using
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
tools like these with no human intervention. This
includes bandwidth
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
estimation.
Post by Fred Stratton
The overhead for the particular setup I use was 40 for
PPPoE, and 10 for
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
PPPoA.
The default you suggest is a suitable starting point, I
suggest.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
QUESTION #5: I still don’t have any great answers for
the Link Layer
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
Adaptation overhead descriptions and recommendations.
In an earlier message,
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
and following messages), Fred Stratton described the
overheads carried by
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
various options, and Sebastian Moeller also gave some
useful advice.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
After looking at the options, I despair of giving
people a clear
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
recommendation that would be optimal for their
equipment. Consequently, I
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
believe the best we can do is come up with “good
enough” recommendations
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting
up SQM” page to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
ADSL/ATM link: Choose “ADSL/ATM", and set Per
Packet Overhead to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
40
VDSL2 link: Choose “VDSL”, and set Per Packet
Overhead to 8
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
Other kind of link (e.g., Cable, Fiber,
Ethernet, other not
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
listed): Choose “None (default)”, and set Per Packet
Overhead to 0
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
NB: I have changed the first menu choice to “ADSL/ATM”
and the second to
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
“VDSL” in the description. I would ask that we change
to GUI to reflect
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
those names as well. This makes it far easier/less
confusing to talk about
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
the options.
As always, I welcome help in setting out clear
recommendations that work
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
well for the vast majority of people who try CeroWrt.
Thanks.
Post by David Personette
Post by David Personette
Post by Fred Stratton
Post by Sebastian Moeller
Post by Fred Stratton
Post by Fred Stratton
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Sebastian Moeller
2014-01-06 10:56:57 UTC
Permalink
Hi Dave, hi List,
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
Since you wore nfq_codel, what is the secret sauce here?
Post by Dave Taht
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
Any further hints on the nature of your day job possible :)
Post by Dave Taht
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
I fully agree that it would be nice. Also it ail e hard unless we take control over the actual bottleneck link… With DSL connections, the DSL modem knows a lot about the link properties, if the modem would be onboard we could programmatically as about bandwidth and encapsulation; for the more typical case with an independent modem or even modem router we have no clear path accessing that information. With cable I have even less hope, as will never get the modem into the router (then again DOCSIS 3.1's typically faster speeds and mandatory pie in the modem might make the situation less dire than on the DSL side).
So for ATM based links, I think we can estimate a number of relevant parameters about encapsulation and an aggregate up- and down-bandwidth measurement (which alas is not too helpful unless we know the degree of asymmetry or one of the bandwidth, in both cases we are likely to know everything a priori anyway). But the current prototype code I have is really slow (3 hours measurement time with otherwise quiet home network; ~20 processing) and memory demanding (the ascii ping traces take up ~260MB) so will not be able to run on the router (also the current implementation in matlab/octave does not lend itself well for an embedded platform…)

Best Regards
Sebastian
Post by Dave Taht
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Dave Taht
2014-01-06 15:03:34 UTC
Permalink
Post by Sebastian Moeller
Hi Dave, hi List,
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
Since you wore nfq_codel, what is the secret sauce here?
1) It uses a 'tighter' version of Codel than what is currently in Linux. It
doesn't work as well on longer rtts but holds down queue lengths at shorter
rtts better and responds quicker than normal codel.

This is a slightly more expensive version of codel too in that it uses two
invsqrt via newtons method to get more accurate results.

2) it rotates the flow list more like how sfq does yielding better mixing
which leads to higher survival rates for sparse flows and more balance
across all flows.

(This is a one line change to fq-codel)

At higher bandwidths (say, 50mbit) being more drr like (fqcodel) actually
tends to do better than sfqlike as bunching up some packet deliveries makes
hosts respond quicker.

3) common to all the codels in this was elimination of the maxpacket check
which mildly increases drop probability.

Compared to the orders of magnitude we already get from fq codel the sum
benefit of these fixes is in the very small percentage points. Without an
extensive testing and simulation campaign I've been reluctant to attempt
pushing them upstream. What I have mostly thought about instead was
bundling up simple.QoS into c (call it cake or broadbandeq),
Using these mods, adding in fixes for things that are hard now, like full
diffserv support and something lighter than htb.

But enotime, funding etc. Until 3 hit seeing benefit from nfqcodel was even
harder to see, and I'd like to drop out 3 and revisit the data to see if
the improvement is a chimera or not.
Post by Sebastian Moeller
Post by Dave Taht
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
Any further hints on the nature of your day job possible :)
Post by Dave Taht
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
I fully agree that it would be nice. Also it ail e hard unless we
take control over the actual bottleneck link… With DSL connections, the DSL
modem knows a lot about the link properties, if the modem would be onboard
we could programmatically as about bandwidth and encapsulation; for the
more typical case with an independent modem or even modem router we have no
clear path accessing that information. With cable I have even less hope, as
will never get the modem into the router (then again DOCSIS 3.1's typically
faster speeds and mandatory pie in the modem might make the situation less
dire than on the DSL side).
Post by Sebastian Moeller
So for ATM based links, I think we can estimate a number of
relevant parameters about encapsulation and an aggregate up- and
down-bandwidth measurement (which alas is not too helpful unless we know
the degree of asymmetry or one of the bandwidth, in both cases we are
likely to know everything a priori anyway). But the current prototype code
I have is really slow (3 hours measurement time with otherwise quiet home
network; ~20 processing) and memory demanding (the ascii ping traces take
up ~260MB) so will not be able to run on the router (also the current
implementation in matlab/octave does not lend itself well for an embedded
platform…)
Post by Sebastian Moeller
Best Regards
Sebastian
Post by Dave Taht
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
Post by Sebastian Moeller
Post by Dave Taht
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment.
Consequently, I
Post by Sebastian Moeller
Post by Dave Taht
believe the best we can do is come up with “good enough”
recommendations
Post by Sebastian Moeller
Post by Dave Taht
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page
to
Post by Sebastian Moeller
Post by Dave Taht
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
Post by Sebastian Moeller
Post by Dave Taht
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead
to
Post by Sebastian Moeller
Post by Dave Taht
40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second
to
Post by Sebastian Moeller
Post by Dave Taht
“VDSL” in the description. I would ask that we change to GUI to
reflect
Post by Sebastian Moeller
Post by Dave Taht
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
http://www.teklibre.com/cerowrt/subscribe.html
Post by Sebastian Moeller
Post by Dave Taht
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Sebastian Moeller
2014-01-06 15:25:33 UTC
Permalink
Hi Dave,

thanks a lot for the explanation.
Post by Sebastian Moeller
Hi Dave, hi List,
Post by Dave Taht
For consistency, if ADSL is used as a portmanteau term, them VDSL should be
used as the equivalent for VDSL and VDSL2.
CeroWRT has to decide whether it is an experimental build, or something that
will eventually be used in production, so these decisions can be made
consistently.
Well, what I was aiming for was for us to get the sqm scripts and gui
up to where they were better than the standard openwrt qos scripts and
then push them up to openwrt to where they could be more widely
deployed.
Aside from being able to dynamically assign priorities in the gui, we
are there. Except that nfq_codel is currently getting better results
than fq_codel at low bandwidths, and I'm tempted to pour all of
simple.qos into C.
Since you wore nfq_codel, what is the secret sauce here?
1) It uses a 'tighter' version of Codel than what is currently in Linux. It doesn't work as well on longer rtts but holds down queue lengths at shorter rtts better and responds quicker than normal codel.
This is a slightly more expensive version of codel too in that it uses two invsqrt via newtons method to get more accurate results.
2) it rotates the flow list more like how sfq does yielding better mixing which leads to higher survival rates for sparse flows and more balance across all flows.
(This is a one line change to fq-codel)
At higher bandwidths (say, 50mbit) being more drr like (fqcodel) actually tends to do better than sfqlike as bunching up some packet deliveries makes hosts respond quicker.
3) common to all the codels in this was elimination of the maxpacket check which mildly increases drop probability.
Compared to the orders of magnitude we already get from fq codel the sum benefit of these fixes is in the very small percentage points. Without an extensive testing and simulation campaign I've been reluctant to attempt pushing them upstream. What I have mostly thought about instead was bundling up simple.QoS into c (call it cake or broadbandeq),
Using these mods, adding in fixes for things that are hard now, like full diffserv support and something lighter than htb.
But enotime, funding etc. Until 3 hit seeing benefit from nfqcodel was even harder to see, and I'd like to drop out 3 and revisit the data to see if the improvement is a chimera or not.
In case 3) and potentially 2 are the critical parts, do you see a chance of getting these included upstream as part of fq_codels that need special tc options to trigger? I assume 1 to be larger and potentially harder to sell upstream (then again since codel is intended to run knob-free, maybe even adding 2 and 3 is controversial...).

Best Regards
Sebastian
Post by Sebastian Moeller
Post by Dave Taht
As for cero's future - certainly since all the snowden revelations
I've been going around saying that "friends don't let friends run
factory firmware". I would like a stable build of sqm and cerowrt to
emerge, and to then go off and work on improving wifi. Regrettably
what seems to be happening is more backwards than forwards on the
former, and ramping up on the ath9k and ath10k is taking more time
than I'd like, and it seems likely I'll be working on those primarily
on another platform and only eventually pushing the results out to
cero, mainline kernel
So it's still at the "keep plugging away" point for sqm, ipv6, cero in
general, with the stable release always just out of sight.
Tackling the ipv6 problem is next on my agenda on cero, and getting a
test suite going is next on my day job.
Any further hints on the nature of your day job possible :)
Post by Dave Taht
I concur with your ADSL setup suggestion as default. I have been running the
Sebastian Moeller ping script overnight to calculate ADSL overhead for the
last several days. After several hours of curve fitting using Octave, an
overhead result is displayed. This novel approach works well.
It would be nice to get to where we could autoconfigure a router using
tools like these with no human intervention. This includes bandwidth
estimation.
I fully agree that it would be nice. Also it ail e hard unless we take control over the actual bottleneck link… With DSL connections, the DSL modem knows a lot about the link properties, if the modem would be onboard we could programmatically as about bandwidth and encapsulation; for the more typical case with an independent modem or even modem router we have no clear path accessing that information. With cable I have even less hope, as will never get the modem into the router (then again DOCSIS 3.1's typically faster speeds and mandatory pie in the modem might make the situation less dire than on the DSL side).
So for ATM based links, I think we can estimate a number of relevant parameters about encapsulation and an aggregate up- and down-bandwidth measurement (which alas is not too helpful unless we know the degree of asymmetry or one of the bandwidth, in both cases we are likely to know everything a priori anyway). But the current prototype code I have is really slow (3 hours measurement time with otherwise quiet home network; ~20 processing) and memory demanding (the ascii ping traces take up ~260MB) so will not be able to run on the router (also the current implementation in matlab/octave does not lend itself well for an embedded platform…)
Best Regards
Sebastian
Post by Dave Taht
The overhead for the particular setup I use was 40 for PPPoE, and 10 for
PPPoA.
The default you suggest is a suitable starting point, I suggest.
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer
Adaptation overhead descriptions and recommendations. In an earlier message,
(see
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html
and following messages), Fred Stratton described the overheads carried by
various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear
recommendation that would be optimal for their equipment. Consequently, I
believe the best we can do is come up with “good enough” recommendations
that are not wrong, and still give decent performance.
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to
reflect this understanding. See
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
Other kind of link (e.g., Cable, Fiber, Ethernet, other not
listed): Choose “None (default)”, and set Per Packet Overhead to 0
NB: I have changed the first menu choice to “ADSL/ATM” and the second to
“VDSL” in the description. I would ask that we change to GUI to reflect
those names as well. This makes it far easier/less confusing to talk about
the options.
As always, I welcome help in setting out clear recommendations that work
well for the vast majority of people who try CeroWrt. Thanks.
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Sebastian Moeller
2014-01-04 20:22:59 UTC
Permalink
Hi Rich,
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer Adaptation overhead descriptions and recommendations. In an earlier message, (see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html and following messages), Fred Stratton described the overheads carried by various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear recommendation that would be optimal for their equipment. Consequently, I believe the best we can do is come up with “good enough” recommendations that are not wrong, and still give decent performance.
Not wanting to be a spoilsport, but IMHO the issue is complicated hence no simple recommendations. I know that my last word was that 40bytes would be a good default overhead, but today I had the opportunity to measure the overhead on fast ADSL connection in Luxembourg and found that in this double-play situation (television and internet via DSL) that an other wise invisible VLAN was further increasing the overhead (from the 40 expected to 44 bytes). At least on faster links these combo packets (internet, phone and potentially telephone) are becoming more and more common, so maybe the recommendation should be 44 (hopping that FCS are truly rare).
Post by Rich Brown
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to reflect this understanding. See http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
While I prefer ATM, I think all deployed ADSL is on ATM so these are synonyms for our purpose. I prefer ATM since the most critical part of the link layer adjustments is caused by the impedance mismatch between what ATM offers and what the data transport layer requires. I have the impression that ADSL might still evolve to a different carrier, while ATM is basically in maintenance mode (not much new deployment if any).
Post by Rich Brown
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
There are several issues with this; VDSL is not the direct predecessor of VDSL2 (rather VDSL2 is the successor of ADSL2+ with some similarities to VDSL). Lumping VDSL with VDSL2 will require us figuring out whether both behave the same. From my cursory reading of the standards of both I think VDSL is not unlikely to be using an ATM link layer, VDSL2 is unlikely to do the same, both seem technically able to use ATM.
Post by Rich Brown
Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed): Choose “None (default)”, and set Per Packet Overhead to 0
This is not going to be worse than today, so sounds fine (it would be good to know whether there is truly no overhead on these links in practical useage).
Quick vote: anyone on this list using ceroWRT on an VDSL/VDSL2 link or cable fiber whatnot that could do some quick testing for us?
Post by Rich Brown
NB: I have changed the first menu choice to “ADSL/ATM” and the second to “VDSL” in the description.
I am fine with changing names, just see what the consensus is for the names.
Post by Rich Brown
I would ask that we change to GUI to reflect those names as well. This makes it far easier/less confusing to talk about the options.
Agreed.
Post by Rich Brown
As always, I welcome help in setting out clear recommendations that work well for the vast majority of people who try CeroWrt. Thanks.
I guess, we need a new wiki page detailing the procedure to figure out the link layer (and overhead if on ATM).

Best
Sebastian
Post by Rich Brown
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Dave Taht
2014-01-06 03:46:36 UTC
Permalink
Post by Sebastian Moeller
Hi Rich,
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer Adaptation overhead descriptions and recommendations. In an earlier message, (see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html and following messages), Fred Stratton described the overheads carried by various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear recommendation that would be optimal for their equipment. Consequently, I believe the best we can do is come up with “good enough” recommendations that are not wrong, and still give decent performance.
Not wanting to be a spoilsport, but IMHO the issue is complicated hence no simple recommendations. I know that my last word was that 40bytes would be a good default overhead, but today I had the opportunity to measure the overhead on fast ADSL connection in Luxembourg and found that in this double-play situation (television and internet via DSL) that an other wise invisible VLAN was further increasing the overhead (from the 40 expected to 44 bytes). At least on faster links these combo packets (internet, phone and potentially telephone) are becoming more and more common, so maybe the recommendation should be 44 (hopping that FCS are truly rare).
Post by Rich Brown
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to reflect this understanding. See http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
While I prefer ATM, I think all deployed ADSL is on ATM so these are synonyms for our purpose. I prefer ATM since the most critical part of the link layer adjustments is caused by the impedance mismatch between what ATM offers and what the data transport layer requires. I have the impression that ADSL might still evolve to a different carrier, while ATM is basically in maintenance mode (not much new deployment if any).
Post by Rich Brown
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
There are several issues with this; VDSL is not the direct predecessor of VDSL2 (rather VDSL2 is the successor of ADSL2+ with some similarities to VDSL). Lumping VDSL with VDSL2 will require us figuring out whether both behave the same.
Sebastian Moeller
2014-01-06 12:28:52 UTC
Permalink
Hi Dave,
Post by Sebastian Moeller
Hi Rich,
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer Adaptation overhead descriptions and recommendations. In an earlier message, (see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html and following messages), Fred Stratton described the overheads carried by various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear recommendation that would be optimal for their equipment. Consequently, I believe the best we can do is come up with “good enough” recommendations that are not wrong, and still give decent performance.
Not wanting to be a spoilsport, but IMHO the issue is complicated hence no simple recommendations. I know that my last word was that 40bytes would be a good default overhead, but today I had the opportunity to measure the overhead on fast ADSL connection in Luxembourg and found that in this double-play situation (television and internet via DSL) that an other wise invisible VLAN was further increasing the overhead (from the 40 expected to 44 bytes). At least on faster links these combo packets (internet, phone and potentially telephone) are becoming more and more common, so maybe the recommendation should be 44 (hopping that FCS are truly rare).
Post by Rich Brown
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to reflect this understanding. See http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
While I prefer ATM, I think all deployed ADSL is on ATM so these are synonyms for our purpose. I prefer ATM since the most critical part of the link layer adjustments is caused by the impedance mismatch between what ATM offers and what the data transport layer requires. I have the impression that ADSL might still evolve to a different carrier, while ATM is basically in maintenance mode (not much new deployment if any).
Post by Rich Brown
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
There are several issues with this; VDSL is not the direct predecessor of VDSL2 (rather VDSL2 is the successor of ADSL2+ with some similarities to VDSL). Lumping VDSL with VDSL2 will require us figuring out whether both behave the same. From my cursory reading of the standards of both I think VDSL is not unlikely to be using an ATM link layer, VDSL2 is unlikely to do the same, both seem technically able to use ATM.
Post by Rich Brown
Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed): Choose “None (default)”, and set Per Packet Overhead to 0
This is not going to be worse than today, so sounds fine (it would be good to know whether there is truly no overhead on these links in practical useage).
Well, I just spent a painful hour trying to find an optimum for the
device on my mom's (cable) network, which I plan to replace with one
that is ipv6 compatible shortly. (I am settled in one place for a
while, so may setup a local dhcpv6-pd server, too - but my primary
mission is to get a test suite going)
Before: http://snapon.lab.bufferbloat.net/~cero2/taht_mahal/taht_house_comcast_long-3.svg
(note it took a long time to fully saturate the buffers as the test
box was 50ms away. I usually test with one 16ms away)
http://snapon.lab.bufferbloat.net/~cero2/taht_mahal/fq_codel_30_8_taht_house_comcast-long.svg
The upload value isn't making that much sense, and I lost a lot of
throughput. Variety of other tests in that dir.
Post by Sebastian Moeller
Quick vote: anyone on this list using ceroWRT on an VDSL/VDSL2 link or cable fiber whatnot that could do some quick testing for us?
There doesn't appear to be any need for "overhead" related settings on
cable. There might be some use on docsis 3 in changing the htb burst
value.
That is what I thought before as well, nowadays I am not so sure. Our problem is that we need to get a reliable estimate of the IP bandwidth between modem and CTMS, so we can reliably avoiding filling the modems buffers. The catch is that the advertised speed typically is given in some "raw" reference frame not close enough to what a user/router typically can handle out of the box. With cable I am confident that there are some packet headers that make sure only one modem picks up the data (and from the euphemistic bandwidth descriptions on the DSL side I am quite confident that this is in-band not out-of-band with an independent bandwidth supply.)
Dave, would you be willing to collect a ping sample on your cable link, so I could use this as control for my ATM detector code?


As an example of this situation where I have a better handle take, drum rolls, a typical DSL connection :)
A) The bandwidth promised by the ISP typically is inside a corridor often quite wide, and say 6 to 16Mbit/s is not too helpful for setting the shaper.

B) The modem itself reports the a number of values "Actual Data Rate" (among others even less useful values like "Attainable Data Rate"); this requires active intervention by the user, these values are typically presented via a http. Alternatively advanced users can telnet/ssh into some modems/routers and get more detailed low-level information from the DSL modem (but I digress).

C) This "Actual Data Rate" is the raw synchronization rate, but since forward error correction (FEC) is handled semi out-of-band an unspecified part (given enough information about the FEC parameters this can b calculated though) of that synch rate might not available to the user (I cynically just assume that these bits are taken from the actual data rate without any real proof). With ADSL it seems that an integer number of sub carrier tones are dedicated to FEC.

D) The next issue is the 48 in 53 ATM cell encapsulation which reduces the useable rate down to ~ 90% (this is handled by link layer ATM quite well). Naively one would expect that just shaping down to 90% should have the same effect, but see E). To properly configure this the user needs to know whether his link is using ATM to the DSLAM or not (this information might or might not be available on the modem/router's web interface or on the ISP's customer web interface).

E) Unfortunately, the method used to wrap data packets into ATM cells requires that each packet fills an integer number of ATM cells, so the left over of the last cell will be padded. This especially dire as this can almost double the wire size of small packets like ACKs, making it really hard for the shaper to work well with small packet traffic like ACKs and to some degree VoIP. Luckily for the user, thanks to Jesper and Russell, the "linklayer ATM" method for tc handles this as well. But note for this to work the kernel needs to know how large the packet including overhead is going to be, which leads to...

F) Per packet overhead, there is a number of possible methods to "encapsulate" IP packets into an ATM carrier, which add different amounts of overhead. This ranges from IP over ATM (IPoA over VC-MUX) which basically wraps IP packets into ATM cell meta packets with minimal overhead of 8 bytes to PPPoE over LLC/SNAP which can add 40bytes per packet (this not only includes 8byte PPPoE overhead, but also a full ethernet header worth 14 bytes). To add insult to injury it seems that the 40+ bytes is the ISP's preferred option (where is the invisible hand of the market if you need it :) ). Again for small packets not taking the overhead into account makes shaping quite impossible; in addition underestimating the overhead will create specific packet sizes for which the shaper underestimates the wire size by one cell.

G) and finally (at least this is the last thing I stumbled over empirically there might be more out there) any additional overhead the carrier adds to the packet. Foe example I stumbled over an combined IPTV Internet access which added a 4 byte ethernet VLAN tag which got removed at the ISP supplied router creating a total of 44 bytes of overhead. At least in Europe these kinds of multi-play services using VLANs seem quite popular. (Now, interestingly both VC-MUX and LLC/SNAP basically are multiplexing headers that would allow to keep different streams logically and bandwidth wise separated, but a) these are ATM specific and b) do not fit into the current ideal of a pure IP "next generation" network of the telcos. But users on ATM are not getting short changed here.)


Overall, there is quite a significant difference between the "advertised" wire sped and the useable IP bandwidth on ATM links the user actually associates with that number, and it seems non-trivial for a typical user to easily collect all the required information to configure SQM correctly. I do not see this changing any time soon, all-fiber networks are not going to come in the (near) future, as much as I want it to.
Post by Sebastian Moeller
Post by Rich Brown
NB: I have changed the first menu choice to “ADSL/ATM” and the second to “VDSL” in the description.
I am fine with changing names, just see what the consensus is for the names.
I can live with whatever is decided here, and sebastian has commit access.
So we have "ADSL/ATM" as one, what about "VDSL/PTM", (PTM: packet transfer mode) to keep things symmetric? (We still have the issue with possible ATM carrier on VDSL1 but we should deal with this independently).
Or "ATM/ADSL" and "PTM/VDSL", "ethernet"

Awaiting your votes...

Best Regards
Sebastian
Post by Sebastian Moeller
Post by Rich Brown
I would ask that we change to GUI to reflect those names as well. This makes it far easier/less confusing to talk about the options.
Agreed.
Go for it!
Post by Sebastian Moeller
Post by Rich Brown
As always, I welcome help in setting out clear recommendations that work well for the vast majority of people who try CeroWrt. Thanks.
I don't mind if cero stays too complex for mom to configure, although
I appreciate
the efforts to simplify things.
Post by Sebastian Moeller
I guess, we need a new wiki page detailing the procedure to figure out the link layer (and overhead if on ATM).
Best
Sebastian
Post by Rich Brown
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
Sebastian Moeller
2014-01-05 09:04:39 UTC
Permalink
Hi Rich,

first attempt to send this was lost somehow…, so a re-send
Post by Rich Brown
QUESTION #5: I still don’t have any great answers for the Link Layer Adaptation overhead descriptions and recommendations. In an earlier message, (see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-December/001914.html and following messages), Fred Stratton described the overheads carried by various options, and Sebastian Moeller also gave some useful advice.
After looking at the options, I despair of giving people a clear recommendation that would be optimal for their equipment. Consequently, I believe the best we can do is come up with “good enough” recommendations that are not wrong, and still give decent performance.
Not wanting to be a spoilsport, but IMHO the issue is complicated hence no simple recommendations. I know that my last word was that 40bytes would be a good default overhead, but today I had the opportunity to measure the overhead on fast ADSL connection in Luxembourg and found that in this double-play situation (television and internet via DSL) that an other wise invisible VLAN was further increasing the overhead (from the 40 expected to 44 bytes). At least on faster links these combo packets (internet, phone and potentially telephone) are becoming more and more common, so maybe the recommendation should be 44 (hopping that FCS are truly rare).
Post by Rich Brown
In this spirit, I have changed Draft #3 of the “Setting up SQM” page to reflect this understanding. See http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
ADSL/ATM link: Choose “ADSL/ATM", and set Per Packet Overhead to 40
While I prefer ATM, I think all deployed ADSL is on ATM so these are synonyms for our purpose. I prefer ATM since the most critical part of the link layer adjustments is caused by the impedance mismatch between what ATM offers and what the data transport layer requires. I have the impression that ADSL might still evolve to a different carrier, while ATM is basically in maintenance mode (not much new deployment if any).
Post by Rich Brown
VDSL2 link: Choose “VDSL”, and set Per Packet Overhead to 8
There are several issues with this; VDSL is not the direct predecessor of VDSL2 (rather VDSL2 is the successor of ADSL2+ with some similarities to VDSL). Lumping VDSL with VDSL2 will require us figuring out whether both behave the same. From my cursory reading of the standards of both I think VDSL is not unlikely to be using an ATM link layer, VDSL2 is unlikely to do the same, both seem technically able to use ATM.
Post by Rich Brown
Other kind of link (e.g., Cable, Fiber, Ethernet, other not listed): Choose “None (default)”, and set Per Packet Overhead to 0
This is not going to be worse than today, so sounds fine (it would be good to know whether there is truly no overhead on these links in practical useage).
Quick vote: anyone on this list using ceroWRT on an VDSL/VDSL2 link or cable fiber whatnot that could do some quick testing for us?
Post by Rich Brown
NB: I have changed the first menu choice to “ADSL/ATM” and the second to “VDSL” in the description.
I am fine with changing names, just see what the consensus is for the names.
Post by Rich Brown
I would ask that we change to GUI to reflect those names as well. This makes it far easier/less confusing to talk about the options.
Agreed.
Post by Rich Brown
As always, I welcome help in setting out clear recommendations that work well for the vast majority of people who try CeroWrt. Thanks.
I guess, we need a new wiki page detailing the procedure to figure out the link layer (and overhead if on ATM).

Best
Sebastian
Post by Rich Brown
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Rich Brown
2014-01-11 16:29:02 UTC
Permalink
Folks,

Thanks for all the good responses to this question. I have incorporated the info into the SQM page on the wiki, so that it now gives broad recommendations for each link type, and refers people to the (new) “Everything you wanted to know about Link Layer Adaptation” page.

This allows someone coming to CeroWrt for the first time to set up their router and get decent results that will be vastly better than any other router/firmware combo that they might encounter.

I think this makes our project more approachable, while still giving an inquiring mind the ability to tune their own installation.

You can read the new pages at:

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310

-and-

http://www.bufferbloat.net/projects/cerowrt/wiki/Everything_you_wanted_to_know_about_Link_Layer_Adaptation

Rich
Sebastian Moeller
2014-01-11 16:51:56 UTC
Permalink
Hi Rich,
Post by Rich Brown
Folks,
Thanks for all the good responses to this question. I have incorporated the info into the SQM page on the wiki, so that it now gives broad recommendations for each link type, and refers people to the (new) “Everything you wanted to know about Link Layer Adaptation” page.
This allows someone coming to CeroWrt for the first time to set up their router and get decent results that will be vastly better than any other router/firmware combo that they might encounter.
I think this makes our project more approachable, while still giving an inquiring mind the ability to tune their own installation.
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroWrt_310
This looks quite good.
Post by Rich Brown
-and-
http://www.bufferbloat.net/projects/cerowrt/wiki/Everything_you_wanted_to_know_about_Link_Layer_Adaptation
This needs some love (probably by me), but I will most likely not find a lot of time for this before March…

Best Regards
Sebastian
Post by Rich Brown
Rich
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Continue reading on narkive:
Loading...