[Cerowrt-devel] just when I thought it was safe to do a release

[Cerowrt-devel] just when I thought it was safe to do a release

[Dave Taht]

ok, so all the bits flying in loose formation have been rebased on top of
openwrt head, and I've submitted the last remaining differences (besides
SQM) up to openwrt-devel. They immediately took one...

I also went poking through current 3.14rc kernels to find bugs fixed there but
not in stable 3.10. Found two more I think. (one elsewhere in the flow
hash that I had
just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf, failed,
gave up on tracking pie further.

So I got a new build going, including dnsmasq with dnssec, tested the
components,
and was ready to release...

... when a whole boatload of other stuff landed. Doing a new build now...

and taking the rest of the day off.


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[David Personette]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

I installed 3.10.28-12, and other than some missing packages (bash and curl
were what I noticed, and pulled from the previous version
comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.

-- 
David P.


On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:

> ok, so all the bits flying in loose formation have been rebased on top of
> openwrt head, and I've submitted the last remaining differences (besides
> SQM) up to openwrt-devel. They immediately took one...
>
> I also went poking through current 3.14rc kernels to find bugs fixed there
> but
> not in stable 3.10. Found two more I think. (one elsewhere in the flow
> hash that I had
> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
> failed,
> gave up on tracking pie further.
>
> So I got a new build going, including dnsmasq with dnssec, tested the
> components,
> and was ready to release...
>
> ... when a whole boatload of other stuff landed. Doing a new build now...
>
> and taking the rest of the day off.
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 2081 bytes --]

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Dave Taht]

On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
> I installed 3.10.28-12, and other than some missing packages (bash and curl

Heh. What do you guys do, have a cron job polling for changes to the build dir?
:)

I was going to sit on that and put out a more polished version sometime in
the next couple days.

> were what I noticed, and pulled from the previous version

I killed some big packages while trying to get a new build done faster.

I'll sort through the missing ones and add them back in. (I also just
added in squid, per request). Got a big build box donated to use
again, post disaster.

Does anyone care about cups? (printing?) It was one of those things that
just barely works in the first place due to memory constraints and a PITA
and I haven't shipped it in a while. Most printers are network capable
these days, and what I tend to use the usb port for is odd devices
and gps and the like. I'd like to have support for a 3g modem or two...

Two concerns of mine are that I killed off udev, which used to manage
hotplugging. I'd like to know what, if anything, people are using the usb
for, so as to be able to make sure losing udev doesn't break that...

> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.

I still think there is some tuning to be done on a rrul load, but we had
to get the last of the instruction traps out of the way first. As of
this morning
so far as I know, the "last" ones are gone, but I don't want to jinx it...

Did you try ipv6? Default routes are not quite working for me in
a couple scenarios.

> --
> David P.
>
>
> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> ok, so all the bits flying in loose formation have been rebased on top of
>> openwrt head, and I've submitted the last remaining differences (besides
>> SQM) up to openwrt-devel. They immediately took one...
>>
>> I also went poking through current 3.14rc kernels to find bugs fixed there
>> but
>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>> hash that I had
>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>> failed,
>> gave up on tracking pie further.
>>
>> So I got a new build going, including dnsmasq with dnssec, tested the
>> components,
>> and was ready to release...
>>
>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>
>> and taking the rest of the day off.
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[David Personette]

[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]

I check for updates to certain projects each morning... I can quit anytime
I want... =)

I hadn't enabled ipv6 again since the hurricane tunnels have been fixed,
I'll do so tonight. Thanks again.

-- 
David P.


On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:

> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com>
> wrote:
> > I installed 3.10.28-12, and other than some missing packages (bash and
> curl
>
> Heh. What do you guys do, have a cron job polling for changes to the build
> dir?
> :)
>
> I was going to sit on that and put out a more polished version sometime in
> the next couple days.
>
> > were what I noticed, and pulled from the previous version
>
> I killed some big packages while trying to get a new build done faster.
>
> I'll sort through the missing ones and add them back in. (I also just
> added in squid, per request). Got a big build box donated to use
> again, post disaster.
>
> Does anyone care about cups? (printing?) It was one of those things that
> just barely works in the first place due to memory constraints and a PITA
> and I haven't shipped it in a while. Most printers are network capable
> these days, and what I tend to use the usb port for is odd devices
> and gps and the like. I'd like to have support for a 3g modem or two...
>
> Two concerns of mine are that I killed off udev, which used to manage
> hotplugging. I'd like to know what, if anything, people are using the usb
> for, so as to be able to make sure losing udev doesn't break that...
>
> > comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
> > laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>
> I still think there is some tuning to be done on a rrul load, but we had
> to get the last of the instruction traps out of the way first. As of
> this morning
> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>
> Did you try ipv6? Default routes are not quite working for me in
> a couple scenarios.
>
> > --
> > David P.
> >
> >
> > On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >>
> >> ok, so all the bits flying in loose formation have been rebased on top
> of
> >> openwrt head, and I've submitted the last remaining differences (besides
> >> SQM) up to openwrt-devel. They immediately took one...
> >>
> >> I also went poking through current 3.14rc kernels to find bugs fixed
> there
> >> but
> >> not in stable 3.10. Found two more I think. (one elsewhere in the flow
> >> hash that I had
> >> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
> >> failed,
> >> gave up on tracking pie further.
> >>
> >> So I got a new build going, including dnsmasq with dnssec, tested the
> >> components,
> >> and was ready to release...
> >>
> >> ... when a whole boatload of other stuff landed. Doing a new build
> now...
> >>
> >> and taking the rest of the day off.
> >>
> >>
> >> --
> >> Dave Täht
> >>
> >> Fixing bufferbloat with cerowrt:
> >> http://www.teklibre.com/cerowrt/subscribe.html
> >> _______________________________________________
> >> Cerowrt-devel mailing list
> >> Cerowrt-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>

[-- Attachment #2: Type: text/html, Size: 4776 bytes --]

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Dave Taht]

The methods of assigning ipv6 addresses have changed somewhat
(possibly obsoleting the relevant scripts)

See

http://wiki.openwrt.org/doc/uci/network

for more details.

All you should have to do is add the he interface, and leverage the
already set ip6assign parameter
for the normal interfaces, and add he to  the firewall rules for ge00.
Not sure if that latter step is
still needed....

AHCP still has to get manually configured, which is a PITA.

( note that I started building the new hnetd, ohybridproxyd, mdnsd
code in this build as downloadable packages. Hopefully these will end
up being the replacements for border discovery and ahcpd, and avahi.
But there is a long way to go, documentation is sparse (aside from the
relevant RFCs), developers few, feel free to explore them)

There are other ipv6 tricks you can play, not all of which appear to be working.

IF you are running native ipv6, you can stop routing dns over ipv4
with the peerdns parameter.

config interface 'ge00'
        option ifname 'ge00'
        option proto 'dhcp'
        option peerdns '0' # disable getting dns servers over ipv6

DON'T do this unless you are running native ipv6.

As for stuff that doesn't work...

For example, I tried to leverage ip6hints to statically assign
different ranges of addresses, didn't work.

I thought this would theoretically let me distribute he's addresses to
an internal gw that didn't get
dhcpv6 stuff. It worked, but I didn't get a default route that worked.
(doesn't mean that it won't work
for you, my network is running so much beta code that I have no idea
what could have broke -
I don't see a default route in radvdump at the moment)

config interface 'wan6'
        option ifname '@ge00'
        option proto 'dhcpv6'
        option broadcast '1'
        option metric '2048'
        option reqprefix '60'
        option ip6prefix '2001:Y:X:f0f0::/60' # A different subset
        option ip6prefix '2001:Y:X:fff0::/60' # another subset
        option reqaddress 'try'
#       option clientid 'davedesk' # don't use this param, goes boom.
don't set it in the gui

We hae a long way to go on ipv6, but basic edge functionality is
working pretty good. Just a bunch
of edge cases left to fix.


On Wed, Feb 19, 2014 at 11:38 AM, David Personette <dperson@gmail.com> wrote:
> I check for updates to certain projects each morning... I can quit anytime I
> want... =)
>
> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed,
> I'll do so tonight. Thanks again.
>
> --
> David P.
>
>
> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com>
>> wrote:
>> > I installed 3.10.28-12, and other than some missing packages (bash and
>> > curl
>>
>> Heh. What do you guys do, have a cron job polling for changes to the build
>> dir?
>> :)
>>
>> I was going to sit on that and put out a more polished version sometime in
>> the next couple days.
>>
>> > were what I noticed, and pulled from the previous version
>>
>> I killed some big packages while trying to get a new build done faster.
>>
>> I'll sort through the missing ones and add them back in. (I also just
>> added in squid, per request). Got a big build box donated to use
>> again, post disaster.
>>
>> Does anyone care about cups? (printing?) It was one of those things that
>> just barely works in the first place due to memory constraints and a PITA
>> and I haven't shipped it in a while. Most printers are network capable
>> these days, and what I tend to use the usb port for is odd devices
>> and gps and the like. I'd like to have support for a 3g modem or two...
>>
>> Two concerns of mine are that I killed off udev, which used to manage
>> hotplugging. I'd like to know what, if anything, people are using the usb
>> for, so as to be able to make sure losing udev doesn't break that...
>>
>> > comcast/3.10.28-4). It's working great for me. Throughput on WiFi from
>> > my
>> > laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>
>> I still think there is some tuning to be done on a rrul load, but we had
>> to get the last of the instruction traps out of the way first. As of
>> this morning
>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>
>> Did you try ipv6? Default routes are not quite working for me in
>> a couple scenarios.
>>
>> > --
>> > David P.
>> >
>> >
>> > On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> >>
>> >> ok, so all the bits flying in loose formation have been rebased on top
>> >> of
>> >> openwrt head, and I've submitted the last remaining differences
>> >> (besides
>> >> SQM) up to openwrt-devel. They immediately took one...
>> >>
>> >> I also went poking through current 3.14rc kernels to find bugs fixed
>> >> there
>> >> but
>> >> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>> >> hash that I had
>> >> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>> >> failed,
>> >> gave up on tracking pie further.
>> >>
>> >> So I got a new build going, including dnsmasq with dnssec, tested the
>> >> components,
>> >> and was ready to release...
>> >>
>> >> ... when a whole boatload of other stuff landed. Doing a new build
>> >> now...
>> >>
>> >> and taking the rest of the day off.
>> >>
>> >>
>> >> --
>> >> Dave Täht
>> >>
>> >> Fixing bufferbloat with cerowrt:
>> >> http://www.teklibre.com/cerowrt/subscribe.html
>> >> _______________________________________________
>> >> Cerowrt-devel mailing list
>> >> Cerowrt-devel@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >
>> >
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[edwin]

On 02/19/2014 06:29 PM, Dave Taht wrote:
> Does anyone care about cups?

Not on the router.

> (printing?)

Yes, but for that I run p910nd on the router and cups itself on my desktop/laptop.
Works well most of the time, I managed to break it occasionally only if I power-cycle the router/printer/laptop in the wrong order, nothing to be concerned about.

> It was one of those things that
> just barely works in the first place due to memory constraints and a PITA
> and I haven't shipped it in a while. Most printers are network capable
> these days, and what I tend to use the usb port for is odd devices
> and gps and the like. I'd like to have support for a 3g modem or two...



> 
> Two concerns of mine are that I killed off udev, which used to manage
> hotplugging. I'd like to know what, if anything, people are using the usb
> for, so as to be able to make sure losing udev doesn't break that...

I have this in /etc/config/p910nd:
config p910nd
        option bidirectional '1'
        option enabled '1'
        option device '/dev/usb/lp0'
        option port '9'

I'm still on 3.7.5-2 though, the 3.10.x builds looked rather experimental and I would not rather run them as my WNDR is my main router.

FWIW these are the packages that I installed on my 3.7.5-2:
kmod-leds-wndr3700-usb
kmod-usb-printer
luci-app-p910nd
p910nd
wifitoggle

Best regards,
--Edwin

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

HI Dave,


On Feb 19, 2014, at 17:29 , Dave Taht <dave.taht@gmail.com> wrote:

> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>> I installed 3.10.28-12, and other than some missing packages (bash and curl
> 
> Heh. What do you guys do, have a cron job polling for changes to the build dir?
> :)
> 
> I was going to sit on that and put out a more polished version sometime in
> the next couple days.
> 
>> were what I noticed, and pulled from the previous version
> 
> I killed some big packages while trying to get a new build done faster.
> 
> I'll sort through the missing ones and add them back in. (I also just
> added in squid, per request). Got a big build box donated to use
> again, post disaster.
> 
> Does anyone care about cups? (printing?) It was one of those things that
> just barely works in the first place due to memory constraints and a PITA
> and I haven't shipped it in a while. Most printers are network capable
> these days, and what I tend to use the usb port for is odd devices
> and gps and the like. I'd like to have support for a 3g modem or two...
> 
> Two concerns of mine are that I killed off udev, which used to manage
> hotplugging. I'd like to know what, if anything, people are using the usb
> for, so as to be able to make sure losing udev doesn't break that…

	On my wnder3700v2m I only use the USB to mount a USB stick, for a large persistent /home directory (for cerowrt images mainly, and persistent vnstat data so I can monitor consumed data volume per month) and a swap partition (under the theory that I rather have things slow to molasses while going though paging-purgatory compared to have the rout go belly-up). I have not tested 3.10.20-12 yet, but will holler if mounting the usb stick does not work without udev (but I assume it does not care too much about udev….)

> 
>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
> 
> I still think there is some tuning to be done on a rrul load, but we had
> to get the last of the instruction traps out of the way first. As of
> this morning
> so far as I know, the "last" ones are gone, but I don't want to jinx it…

	Great, so that will be in the next non-release then ;) ?

Best Regards
	Sebastian

> 
> Did you try ipv6? Default routes are not quite working for me in
> a couple scenarios.
> 
>> --
>> David P.
>> 
>> 
>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>> 
>>> ok, so all the bits flying in loose formation have been rebased on top of
>>> openwrt head, and I've submitted the last remaining differences (besides
>>> SQM) up to openwrt-devel. They immediately took one...
>>> 
>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>> but
>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>> hash that I had
>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>> failed,
>>> gave up on tracking pie further.
>>> 
>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>> components,
>>> and was ready to release...
>>> 
>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>> 
>>> and taking the rest of the day off.
>>> 
>>> 
>>> --
>>> Dave Täht
>>> 
>>> Fixing bufferbloat with cerowrt:
>>> http://www.teklibre.com/cerowrt/subscribe.html
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> 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
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Dave Taht]

don't use 3.10.28-12 with the usb stick. Found a bug with codepoints.
Building 3.10.28-14 now.



On Wed, Feb 19, 2014 at 3:32 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> HI Dave,
>
>
> On Feb 19, 2014, at 17:29 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>
>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>> :)
>>
>> I was going to sit on that and put out a more polished version sometime in
>> the next couple days.
>>
>>> were what I noticed, and pulled from the previous version
>>
>> I killed some big packages while trying to get a new build done faster.
>>
>> I'll sort through the missing ones and add them back in. (I also just
>> added in squid, per request). Got a big build box donated to use
>> again, post disaster.
>>
>> Does anyone care about cups? (printing?) It was one of those things that
>> just barely works in the first place due to memory constraints and a PITA
>> and I haven't shipped it in a while. Most printers are network capable
>> these days, and what I tend to use the usb port for is odd devices
>> and gps and the like. I'd like to have support for a 3g modem or two...
>>
>> Two concerns of mine are that I killed off udev, which used to manage
>> hotplugging. I'd like to know what, if anything, people are using the usb
>> for, so as to be able to make sure losing udev doesn't break that...
>
>         On my wnder3700v2m I only use the USB to mount a USB stick, for a large persistent /home directory (for cerowrt images mainly, and persistent vnstat data so I can monitor consumed data volume per month) and a swap partition (under the theory that I rather have things slow to molasses while going though paging-purgatory compared to have the rout go belly-up). I have not tested 3.10.20-12 yet, but will holler if mounting the usb stick does not work without udev (but I assume it does not care too much about udev....)
>
>>
>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>
>> I still think there is some tuning to be done on a rrul load, but we had
>> to get the last of the instruction traps out of the way first. As of
>> this morning
>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>
>         Great, so that will be in the next non-release then ;) ?
>
> Best Regards
>         Sebastian
>
>>
>> Did you try ipv6? Default routes are not quite working for me in
>> a couple scenarios.
>>
>>> --
>>> David P.
>>>
>>>
>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>
>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>
>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>> but
>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>> hash that I had
>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>> failed,
>>>> gave up on tracking pie further.
>>>>
>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>> components,
>>>> and was ready to release...
>>>>
>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>
>>>> and taking the rest of the day off.
>>>>
>>>>
>>>> --
>>>> Dave Täht
>>>>
>>>> Fixing bufferbloat with cerowrt:
>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> 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
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

Hi Dave,


On Feb 19, 2014, at 21:43 , Dave Taht <dave.taht@gmail.com> wrote:

> don't use 3.10.28-12 with the usb stick. Found a bug with codepoints.
> Building 3.10.28-14 now.

	Ah, okay, will wait for -14..

best regards
	Sebastian

> 
> 
> 
> On Wed, Feb 19, 2014 at 3:32 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> HI Dave,
>> 
>> 
>> On Feb 19, 2014, at 17:29 , Dave Taht <dave.taht@gmail.com> wrote:
>> 
>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>> 
>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>> :)
>>> 
>>> I was going to sit on that and put out a more polished version sometime in
>>> the next couple days.
>>> 
>>>> were what I noticed, and pulled from the previous version
>>> 
>>> I killed some big packages while trying to get a new build done faster.
>>> 
>>> I'll sort through the missing ones and add them back in. (I also just
>>> added in squid, per request). Got a big build box donated to use
>>> again, post disaster.
>>> 
>>> Does anyone care about cups? (printing?) It was one of those things that
>>> just barely works in the first place due to memory constraints and a PITA
>>> and I haven't shipped it in a while. Most printers are network capable
>>> these days, and what I tend to use the usb port for is odd devices
>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>> 
>>> Two concerns of mine are that I killed off udev, which used to manage
>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>> for, so as to be able to make sure losing udev doesn't break that...
>> 
>>        On my wnder3700v2m I only use the USB to mount a USB stick, for a large persistent /home directory (for cerowrt images mainly, and persistent vnstat data so I can monitor consumed data volume per month) and a swap partition (under the theory that I rather have things slow to molasses while going though paging-purgatory compared to have the rout go belly-up). I have not tested 3.10.20-12 yet, but will holler if mounting the usb stick does not work without udev (but I assume it does not care too much about udev....)
>> 
>>> 
>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>> 
>>> I still think there is some tuning to be done on a rrul load, but we had
>>> to get the last of the instruction traps out of the way first. As of
>>> this morning
>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>> 
>>        Great, so that will be in the next non-release then ;) ?
>> 
>> Best Regards
>>        Sebastian
>> 
>>> 
>>> Did you try ipv6? Default routes are not quite working for me in
>>> a couple scenarios.
>>> 
>>>> --
>>>> David P.
>>>> 
>>>> 
>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>> 
>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>> 
>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>> but
>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>> hash that I had
>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>> failed,
>>>>> gave up on tracking pie further.
>>>>> 
>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>> components,
>>>>> and was ready to release...
>>>>> 
>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>> 
>>>>> and taking the rest of the day off.
>>>>> 
>>>>> 
>>>>> --
>>>>> Dave Täht
>>>>> 
>>>>> Fixing bufferbloat with cerowrt:
>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>> _______________________________________________
>>>>> Cerowrt-devel mailing list
>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>> 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
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
> 
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Fred Stratton]

[-- Attachment #1: Type: text/plain, Size: 4431 bytes --]


http://www.vwlowen.co.uk/internet/files.htm#routerstatslite

is software that is useful for monitoring an ADSL connection.  When 
'speed has increased' is mentioned, I wonder what has happened to the 
downstream noise margin.

Runs prettily under Wine, and is maintained, unlike DMT.



On 19/02/14 16:38, David Personette wrote:
> I check for updates to certain projects each morning... I can quit 
> anytime I want... =)
>
> I hadn't enabled ipv6 again since the hurricane tunnels have been 
> fixed, I'll do so tonight. Thanks again.
>
> -- 
> David P.
>
>
> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com 
> <mailto:dave.taht@gmail.com>> wrote:
>
>     On Wed, Feb 19, 2014 at 11:11 AM, David Personette
>     <dperson@gmail.com <mailto:dperson@gmail.com>> wrote:
>     > I installed 3.10.28-12 <tel:3.10.28-12>, and other than some
>     missing packages (bash and curl
>
>     Heh. What do you guys do, have a cron job polling for changes to
>     the build dir?
>     :)
>
>     I was going to sit on that and put out a more polished version
>     sometime in
>     the next couple days.
>
>     > were what I noticed, and pulled from the previous version
>
>     I killed some big packages while trying to get a new build done
>     faster.
>
>     I'll sort through the missing ones and add them back in. (I also just
>     added in squid, per request). Got a big build box donated to use
>     again, post disaster.
>
>     Does anyone care about cups? (printing?) It was one of those
>     things that
>     just barely works in the first place due to memory constraints and
>     a PITA
>     and I haven't shipped it in a while. Most printers are network capable
>     these days, and what I tend to use the usb port for is odd devices
>     and gps and the like. I'd like to have support for a 3g modem or
>     two...
>
>     Two concerns of mine are that I killed off udev, which used to manage
>     hotplugging. I'd like to know what, if anything, people are using
>     the usb
>     for, so as to be able to make sure losing udev doesn't break that...
>
>     > comcast/3.10.28-4). It's working great for me. Throughput on
>     WiFi from my
>     > laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>
>     I still think there is some tuning to be done on a rrul load, but
>     we had
>     to get the last of the instruction traps out of the way first. As of
>     this morning
>     so far as I know, the "last" ones are gone, but I don't want to
>     jinx it...
>
>     Did you try ipv6? Default routes are not quite working for me in
>     a couple scenarios.
>
>     > --
>     > David P.
>     >
>     >
>     > On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com
>     <mailto:dave.taht@gmail.com>> wrote:
>     >>
>     >> ok, so all the bits flying in loose formation have been rebased
>     on top of
>     >> openwrt head, and I've submitted the last remaining differences
>     (besides
>     >> SQM) up to openwrt-devel. They immediately took one...
>     >>
>     >> I also went poking through current 3.14rc kernels to find bugs
>     fixed there
>     >> but
>     >> not in stable 3.10. Found two more I think. (one elsewhere in
>     the flow
>     >> hash that I had
>     >> just submitted upstream, sigh). Tried to backport sch_fq and
>     sch_hhf,
>     >> failed,
>     >> gave up on tracking pie further.
>     >>
>     >> So I got a new build going, including dnsmasq with dnssec,
>     tested the
>     >> components,
>     >> and was ready to release...
>     >>
>     >> ... when a whole boatload of other stuff landed. Doing a new
>     build now...
>     >>
>     >> and taking the rest of the day off.
>     >>
>     >>
>     >> --
>     >> Dave Täht
>     >>
>     >> Fixing bufferbloat with cerowrt:
>     >> http://www.teklibre.com/cerowrt/subscribe.html
>     >> _______________________________________________
>     >> Cerowrt-devel mailing list
>     >> Cerowrt-devel@lists.bufferbloat.net
>     <mailto:Cerowrt-devel@lists.bufferbloat.net>
>     >> 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
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel


[-- Attachment #2: Type: text/html, Size: 8896 bytes --]

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

Hi Fred,


On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:

> 
> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
> 
> is software that is useful for monitoring an ADSL connection.  When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.

	I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...

	Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin. 
Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed). 
	However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently). 
	Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).



> 
> Runs prettily under Wine, and is maintained, unlike DMT.

	A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...


Best Regards
	Sebastian

> 
> 
> 
> On 19/02/14 16:38, David Personette wrote:
>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>> 
>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>> 
>> -- 
>> David P.
>> 
>> 
>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>> > I installed 3.10.28-12, and other than some missing packages (bash and curl
>> 
>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>> :)
>> 
>> I was going to sit on that and put out a more polished version sometime in
>> the next couple days.
>> 
>> > were what I noticed, and pulled from the previous version
>> 
>> I killed some big packages while trying to get a new build done faster.
>> 
>> I'll sort through the missing ones and add them back in. (I also just
>> added in squid, per request). Got a big build box donated to use
>> again, post disaster.
>> 
>> Does anyone care about cups? (printing?) It was one of those things that
>> just barely works in the first place due to memory constraints and a PITA
>> and I haven't shipped it in a while. Most printers are network capable
>> these days, and what I tend to use the usb port for is odd devices
>> and gps and the like. I'd like to have support for a 3g modem or two...
>> 
>> Two concerns of mine are that I killed off udev, which used to manage
>> hotplugging. I'd like to know what, if anything, people are using the usb
>> for, so as to be able to make sure losing udev doesn't break that...
>> 
>> > comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>> > laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>> 
>> I still think there is some tuning to be done on a rrul load, but we had
>> to get the last of the instruction traps out of the way first. As of
>> this morning
>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>> 
>> Did you try ipv6? Default routes are not quite working for me in
>> a couple scenarios.
>> 
>> > --
>> > David P.
>> >
>> >
>> > On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> >>
>> >> ok, so all the bits flying in loose formation have been rebased on top of
>> >> openwrt head, and I've submitted the last remaining differences (besides
>> >> SQM) up to openwrt-devel. They immediately took one...
>> >>
>> >> I also went poking through current 3.14rc kernels to find bugs fixed there
>> >> but
>> >> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>> >> hash that I had
>> >> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>> >> failed,
>> >> gave up on tracking pie further.
>> >>
>> >> So I got a new build going, including dnsmasq with dnssec, tested the
>> >> components,
>> >> and was ready to release...
>> >>
>> >> ... when a whole boatload of other stuff landed. Doing a new build now...
>> >>
>> >> and taking the rest of the day off.
>> >>
>> >>
>> >> --
>> >> Dave Täht
>> >>
>> >> Fixing bufferbloat with cerowrt:
>> >> http://www.teklibre.com/cerowrt/subscribe.html
>> >> _______________________________________________
>> >> Cerowrt-devel mailing list
>> >> Cerowrt-devel@lists.bufferbloat.net
>> >> 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
>> 
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Fred Stratton]

On 20/02/14 11:35, Fred Stratton wrote:
> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>
> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 
> connection monitoring.
>
> I have used an HG 612 with ADSL2plus, but telnet is permanently 
> available, with the password 'admin', a feature I do not like, even on 
> a bridged device.
>
> Routerstats is not reliant on telnet.
>
> I appreciate the analysis, which I am sure is correct. I am interested 
> in external RF interference primarily. I have had two episodes of 
> possible interference  recently, leading to transient disconnections.
>
> Continuously monitoring noise margin not only tells you when your 
> neighbours get up, but also what is happening 40km above.
>
> The  thought was that it would be useful for others, to measure noise 
> margin to track whether the phenomenon I am noticing when this one new 
> build of ceroWRT was released - transient disconnection - is related 
> to that build, or not. I am hoping for longer term benefits also.
>
> When David P says his speed has increased, I listen. Here, I upgraded 
> ceroWRT and had a transient rise in WAN sync speed almost immediately 
> before the first connection loss.
>
> Coincidence or not, the only way to know is by someone, somewhere, 
> monitoring their connection.
>
>
>
>
> On 20/02/14 09:05, Sebastian Moeller wrote:
>> Hi Fred,
>>
>>
>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>
>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>
>>> is software that is useful for monitoring an ADSL connection. When 
>>> 'speed has increased' is mentioned, I wonder what has happened to 
>>> the downstream noise margin.
>>     I think, DP reported speed increase of the wireless (swN0) to 
>> wired (se00) subnets on his home network, not necessarily increases 
>> in wan speed...
>>
>>     Interesting point though; I think with DSL there is a weak 
>> correlation between link stability/speed with noise margin. But other 
>> variables should have stronger correlation with useable bandwidth 
>> than noise margin.
>> Here is why; as far as I know seamless rate adaptation (SRA) is not 
>> in use, so generally speaking the sync speed of a typical DSL link 
>> will over time degrade (and not increase, ignoring G.inp). So once a 
>> DSL connection has "aged" down to stable conditions, noise margin 
>> what ever the numerical values are will not affect the speed. (Note 
>> typically the noise margin is something that is configured in the 
>> DSLAM/modem as minimums; each frequency bin is only maximally loaded 
>> with bits that this minimum signal to noise margin remains. If the 
>> link is throttled below full sync speeds, say by contract, e.g. 
>> having a 6M plan on a short line that would support 16M, then the 
>> noise margin will be large and the system has lots of freedom how 
>> many bits to load on each frequency bin. If the link is running at 
>> full sync, basically close to the physical limits of the link the 
>> noise margin will be close to the minimum values configured by the 
>> ISP. If the physical condition change, say more cross-talk noise due 
>> to more active DSL links in the DSLAM/trunk line the modem in the 
>> second situation will probably loose sync and resync at lower 
>> bandwidth but with noise margin still at the configured minimum. In 
>> other words in that situation noise margin will not correlate with 
>> link speed).
>>     However CRC and HEC error counts should correlate well with 
>> perceived speed changes, as both require packet retransmissions 
>> (visible to the ensures network stack, basically those packets are 
>> just dropped reducing good put, but at least the end nodes have a 
>> good understanding what is pushed over the DSL wires) degrading the 
>> good put of the link. Granted, with a low noise margin CRCs are more 
>> likely, but it is the errors and not the noise margin that actually 
>> affect the speed. (And lo and behold with some interference sources 
>> even very large noise margins do not prevent CRCs sufficiently).
>>     Note the number of FECs (forward error correction) is irrelevant 
>> to the speed, as the link carries the FEC information anyway, so no 
>> slowdown for FEC (well, actually with G.inp that changes a bit, as 
>> now the physical layer tries to retransmit packets/atm cells garbled 
>> beyond recognition by noise; effectively reducing the link throughput 
>> in an opaque way for the endnotes. Which will cause issues with using 
>> a shaper not intimately linked to the actual xDSL modem. But I have 
>> only glanced over 
>> https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items 
>> so I might be too pessimistic).
>>
>>
>>
>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>     A great, just to complete the list for some broadcom models: 
>> http://www.s446074245.websitehome.co.uk under active development...
>>
>>
>> Best Regards
>>     Sebastian
>>
>>>
>>>
>>> On 19/02/14 16:38, David Personette wrote:
>>>> I check for updates to certain projects each morning... I can quit 
>>>> anytime I want... =)
>>>>
>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been 
>>>> fixed, I'll do so tonight. Thanks again.
>>>>
>>>> -- 
>>>> David P.
>>>>
>>>>
>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> 
>>>> wrote:
>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette 
>>>> <dperson@gmail.com> wrote:
>>>>> I installed 3.10.28-12, and other than some missing packages (bash 
>>>>> and curl
>>>> Heh. What do you guys do, have a cron job polling for changes to 
>>>> the build dir?
>>>> :)
>>>>
>>>> I was going to sit on that and put out a more polished version 
>>>> sometime in
>>>> the next couple days.
>>>>
>>>>> were what I noticed, and pulled from the previous version
>>>> I killed some big packages while trying to get a new build done 
>>>> faster.
>>>>
>>>> I'll sort through the missing ones and add them back in. (I also just
>>>> added in squid, per request). Got a big build box donated to use
>>>> again, post disaster.
>>>>
>>>> Does anyone care about cups? (printing?) It was one of those things 
>>>> that
>>>> just barely works in the first place due to memory constraints and 
>>>> a PITA
>>>> and I haven't shipped it in a while. Most printers are network capable
>>>> these days, and what I tend to use the usb port for is odd devices
>>>> and gps and the like. I'd like to have support for a 3g modem or 
>>>> two...
>>>>
>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>> hotplugging. I'd like to know what, if anything, people are using 
>>>> the usb
>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>
>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi 
>>>>> from my
>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>> I still think there is some tuning to be done on a rrul load, but 
>>>> we had
>>>> to get the last of the instruction traps out of the way first. As of
>>>> this morning
>>>> so far as I know, the "last" ones are gone, but I don't want to 
>>>> jinx it...
>>>>
>>>> Did you try ipv6? Default routes are not quite working for me in
>>>> a couple scenarios.
>>>>
>>>>> -- 
>>>>> David P.
>>>>>
>>>>>
>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> 
>>>>> wrote:
>>>>>> ok, so all the bits flying in loose formation have been rebased 
>>>>>> on top of
>>>>>> openwrt head, and I've submitted the last remaining differences 
>>>>>> (besides
>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>
>>>>>> I also went poking through current 3.14rc kernels to find bugs 
>>>>>> fixed there
>>>>>> but
>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the 
>>>>>> flow
>>>>>> hash that I had
>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and 
>>>>>> sch_hhf,
>>>>>> failed,
>>>>>> gave up on tracking pie further.
>>>>>>
>>>>>> So I got a new build going, including dnsmasq with dnssec, tested 
>>>>>> the
>>>>>> components,
>>>>>> and was ready to release...
>>>>>>
>>>>>> ... when a whole boatload of other stuff landed. Doing a new 
>>>>>> build now...
>>>>>>
>>>>>> and taking the rest of the day off.
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Dave Täht
>>>>>>
>>>>>> Fixing bufferbloat with cerowrt:
>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>> _______________________________________________
>>>>>> Cerowrt-devel mailing list
>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>> 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
>>>>
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

Hi Fred,


On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:

> 
> On 20/02/14 11:35, Fred Stratton wrote:
>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>> 
>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>> 
>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.

	Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)

>> 
>> Routerstats is not reliant on telnet.

	Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...


>> 
>> I appreciate the analysis, which I am sure is correct.

	I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...

>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.

	Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.

>> 
>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>> 
>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.

	Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement. 

>> 
>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.

	You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions. 
	Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
	(That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue). 

>> 
>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.

	I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)


Best Regards
	Sebastian


>> 
>> 
>> 
>> 
>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>> Hi Fred,
>>> 
>>> 
>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>> 
>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>> 
>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>    I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>> 
>>>    Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>    However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>    Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>> 
>>> 
>>> 
>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>    A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>> 
>>> 
>>> Best Regards
>>>    Sebastian
>>> 
>>>> 
>>>> 
>>>> On 19/02/14 16:38, David Personette wrote:
>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>> 
>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>> 
>>>>> -- 
>>>>> David P.
>>>>> 
>>>>> 
>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>> :)
>>>>> 
>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>> the next couple days.
>>>>> 
>>>>>> were what I noticed, and pulled from the previous version
>>>>> I killed some big packages while trying to get a new build done faster.
>>>>> 
>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>> added in squid, per request). Got a big build box donated to use
>>>>> again, post disaster.
>>>>> 
>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>> 
>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>> 
>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>> to get the last of the instruction traps out of the way first. As of
>>>>> this morning
>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>> 
>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>> a couple scenarios.
>>>>> 
>>>>>> -- 
>>>>>> David P.
>>>>>> 
>>>>>> 
>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>> 
>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>> but
>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>> hash that I had
>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>> failed,
>>>>>>> gave up on tracking pie further.
>>>>>>> 
>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>> components,
>>>>>>> and was ready to release...
>>>>>>> 
>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>> 
>>>>>>> and taking the rest of the day off.
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Dave Täht
>>>>>>> 
>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>> _______________________________________________
>>>>>>> Cerowrt-devel mailing list
>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>> 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
>>>>> 
>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
>> 
> 

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Fred Stratton]

On 20/02/14 13:56, Fred Stratton wrote:
> The DSLAM at the exchange is an Infineon, Germany's finest.
>
> I am using a 2Wire 2700 as the bridged connection device. The higher 
> frequency bins, as graphed, as not optimally used. The device uses 
> ADSL2+. The user cannot change this mode.
>
> The 2Wire is very effective at suppressing impulse noise.
>
> The line is uncapped, with unlimited downloads.
>
> The RF Interference source is unknown. Possible culprits are
>
> analogue to digital set top TV conversion boxes.
> passing vehicles.
> holes in the ionosphere.
>
> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>
> I can find no PPPoE errors.
>
> The neighbours, based on their SSIDs, are always changing ISPs, and so 
> are not a constant source of RF interference in that sense.
>
>
> On 20/02/14 13:15, Sebastian Moeller wrote:
>> Hi Fred,
>>
>>
>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>
>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>
>>>> This was designed primarily with the Huawei HG 612 in mind, for 
>>>> VDSL2 connection monitoring.
>>>>
>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently 
>>>> available, with the password 'admin', a feature I do not like, even 
>>>> on a bridged device.
>>     Ah, that sounds not very safe (would it hurt the manufacturers to 
>> switch to ssh on those devices and allow users to change the 
>> password, or better ship units with unique and secure passwords, 
>> especially irritating since many modems actually run linux inside...)
>>
>>>> Routerstats is not reliant on telnet.
>>     Ah, I see it only extracts "Downstream Noise Margin and 
>> Connection Speed", I now see why you recommend the use of SNRM as 
>> proxy for line-quality ;)...
>>
>>
>>>> I appreciate the analysis, which I am sure is correct.
>>     I certainly hope it is, but while phrased as statements instead 
>> of questions, I might be completely out for lunch here; then gain I 
>> am always happy to learn from my mistakes...
>>
>>>> I am interested in external RF interference primarily. I have had 
>>>> two episodes of possible interference  recently, leading to 
>>>> transient disconnections.
>>     Well, especially for RF interference a time resolved plot of 
>> CRCs, HECs, and even FECs (which should also increase massively 
>> around noise events) would be even better. Also some modems give ES 
>> (errored seconds) and SES (severely errored seconds) which are also 
>> good to plot along time.
>>
>>>> Continuously monitoring noise margin not only tells you when your 
>>>> neighbours get up, but also what is happening 40km above.
>>>>
>>>> The  thought was that it would be useful for others, to measure 
>>>> noise margin to track whether the phenomenon I am noticing when 
>>>> this one new build of ceroWRT was released - transient 
>>>> disconnection - is related to that build, or not. I am hoping for 
>>>> longer term benefits also.
>>     Mmmh, if the modem concurrently looses sync than cerowrt should 
>> be innocent, if sync stays up and you have PPPoE errors (and run 
>> PPPoE from cerowrt) only with a certain cerowrt build you have a 
>> strong case for cero's involvement.
>>
>>>> When David P says his speed has increased, I listen. Here, I 
>>>> upgraded ceroWRT and had a transient rise in WAN sync speed almost 
>>>> immediately before the first connection loss.
>>     You have an open profile (I mean you are limited by line physics 
>> and not throttled below that by your ISP), right? If all your 
>> neighbors switch of their modems and your intermittent RF noise 
>> source also sleeps, you will get a high sync value where all 
>> frequency bins are maximally used (so only little room for 
>> bitswitching). Now either cross-talk increases due to mode xDSL 
>> activity at your DSLAM or the RF noise comes back. Now your sync is 
>> exceeding the new line capacity caused by the changed line conditions 
>> and there goes your sync. Then on resync with the new conditions the 
>> system syncs at lower bandwidth to honor the specified SNRM under the 
>> new conditions, and you have again only a little leeway for bit 
>> switching, but yuo start at a level better matched to your average 
>> line condition, so this works better than basically the same amount 
>> of spare bits after a sync with perfect conditions.
>>     Now this only applied if there was a resync of the modem after 
>> re-installation of cerowrt… If you did not re-sync (either you or the 
>> modem by its own) then it gets puzzling, as all cerowrt does, if I 
>> remember your setup correctly, is to do the PPPoE encapsulation, and 
>> that should not affect your speed one iota.
>>     (That said, there seems to be a buggy BRAS version by cisco 
>> around, that in germany causes people on old ADSL DSLAMs that hook up 
>> to the ATM concentration net to get throttled by the BRAS by reducing 
>> the PPPoE en- and decapsulation speed. But that is so obscure that I 
>> do not think it affects you, heck it might be a pure duetsche telekom 
>> issue).
>>
>>>> Coincidence or not, the only way to know is by someone, somewhere, 
>>>> monitoring their connection.
>>     I fully endorse that! Monitoring the DSL statistics is a good 
>> practice (I would love doing it again, but my current modem-router 
>> has no meaning flu way of doing that…)
>>
>>
>> Best Regards
>>     Sebastian
>>
>>
>>>>
>>>>
>>>>
>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>> Hi Fred,
>>>>>
>>>>>
>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> 
>>>>> wrote:
>>>>>
>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>
>>>>>> is software that is useful for monitoring an ADSL connection. 
>>>>>> When 'speed has increased' is mentioned, I wonder what has 
>>>>>> happened to the downstream noise margin.
>>>>>     I think, DP reported speed increase of the wireless (swN0) to 
>>>>> wired (se00) subnets on his home network, not necessarily 
>>>>> increases in wan speed...
>>>>>
>>>>>     Interesting point though; I think with DSL there is a weak 
>>>>> correlation between link stability/speed with noise margin. But 
>>>>> other variables should have stronger correlation with useable 
>>>>> bandwidth than noise margin.
>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is 
>>>>> not in use, so generally speaking the sync speed of a typical DSL 
>>>>> link will over time degrade (and not increase, ignoring G.inp). So 
>>>>> once a DSL connection has "aged" down to stable conditions, noise 
>>>>> margin what ever the numerical values are will not affect the 
>>>>> speed. (Note typically the noise margin is something that is 
>>>>> configured in the DSLAM/modem as minimums; each frequency bin is 
>>>>> only maximally loaded with bits that this minimum signal to noise 
>>>>> margin remains. If the link is throttled below full sync speeds, 
>>>>> say by contract, e.g. having a 6M plan on a short line that would 
>>>>> support 16M, then the noise margin will be large and the system 
>>>>> has lots of freedom how many bits to load on each frequency bin. 
>>>>> If the link is running at full sync, basically close to the 
>>>>> physical limits of the link the noise margin will be close to the 
>>>>> minimum values configured by the ISP. If the physical condition 
>>>>> change, say more cross-talk noise due to more active DSL links in 
>>>>> the DSLAM/trunk line the modem in the second situation will 
>>>>> probably loose sync and resync at lower bandwidth but with noise 
>>>>> margin still at the configured minimum. In other words in that 
>>>>> situation noise margin will not correlate with link speed).
>>>>>     However CRC and HEC error counts should correlate well with 
>>>>> perceived speed changes, as both require packet retransmissions 
>>>>> (visible to the ensures network stack, basically those packets are 
>>>>> just dropped reducing good put, but at least the end nodes have a 
>>>>> good understanding what is pushed over the DSL wires) degrading 
>>>>> the good put of the link. Granted, with a low noise margin CRCs 
>>>>> are more likely, but it is the errors and not the noise margin 
>>>>> that actually affect the speed. (And lo and behold with some 
>>>>> interference sources even very large noise margins do not prevent 
>>>>> CRCs sufficiently).
>>>>>     Note the number of FECs (forward error correction) is 
>>>>> irrelevant to the speed, as the link carries the FEC information 
>>>>> anyway, so no slowdown for FEC (well, actually with G.inp that 
>>>>> changes a bit, as now the physical layer tries to retransmit 
>>>>> packets/atm cells garbled beyond recognition by noise; effectively 
>>>>> reducing the link throughput in an opaque way for the endnotes. 
>>>>> Which will cause issues with using a shaper not intimately linked 
>>>>> to the actual xDSL modem. But I have only glanced over 
>>>>> https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items 
>>>>> so I might be too pessimistic).
>>>>>
>>>>>
>>>>>
>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>     A great, just to complete the list for some broadcom models: 
>>>>> http://www.s446074245.websitehome.co.uk under active development...
>>>>>
>>>>>
>>>>> Best Regards
>>>>>     Sebastian
>>>>>
>>>>>>
>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>> I check for updates to certain projects each morning... I can 
>>>>>>> quit anytime I want... =)
>>>>>>>
>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have 
>>>>>>> been fixed, I'll do so tonight. Thanks again.
>>>>>>>
>>>>>>> -- 
>>>>>>> David P.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht 
>>>>>>> <dave.taht@gmail.com> wrote:
>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette 
>>>>>>> <dperson@gmail.com> wrote:
>>>>>>>> I installed 3.10.28-12, and other than some missing packages 
>>>>>>>> (bash and curl
>>>>>>> Heh. What do you guys do, have a cron job polling for changes to 
>>>>>>> the build dir?
>>>>>>> :)
>>>>>>>
>>>>>>> I was going to sit on that and put out a more polished version 
>>>>>>> sometime in
>>>>>>> the next couple days.
>>>>>>>
>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>> I killed some big packages while trying to get a new build done 
>>>>>>> faster.
>>>>>>>
>>>>>>> I'll sort through the missing ones and add them back in. (I also 
>>>>>>> just
>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>> again, post disaster.
>>>>>>>
>>>>>>> Does anyone care about cups? (printing?) It was one of those 
>>>>>>> things that
>>>>>>> just barely works in the first place due to memory constraints 
>>>>>>> and a PITA
>>>>>>> and I haven't shipped it in a while. Most printers are network 
>>>>>>> capable
>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>> and gps and the like. I'd like to have support for a 3g modem or 
>>>>>>> two...
>>>>>>>
>>>>>>> Two concerns of mine are that I killed off udev, which used to 
>>>>>>> manage
>>>>>>> hotplugging. I'd like to know what, if anything, people are 
>>>>>>> using the usb
>>>>>>> for, so as to be able to make sure losing udev doesn't break 
>>>>>>> that...
>>>>>>>
>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on 
>>>>>>>> WiFi from my
>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>> I still think there is some tuning to be done on a rrul load, 
>>>>>>> but we had
>>>>>>> to get the last of the instruction traps out of the way first. 
>>>>>>> As of
>>>>>>> this morning
>>>>>>> so far as I know, the "last" ones are gone, but I don't want to 
>>>>>>> jinx it...
>>>>>>>
>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>> a couple scenarios.
>>>>>>>
>>>>>>>> -- 
>>>>>>>> David P.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht 
>>>>>>>> <dave.taht@gmail.com> wrote:
>>>>>>>>> ok, so all the bits flying in loose formation have been 
>>>>>>>>> rebased on top of
>>>>>>>>> openwrt head, and I've submitted the last remaining 
>>>>>>>>> differences (besides
>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>
>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs 
>>>>>>>>> fixed there
>>>>>>>>> but
>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in 
>>>>>>>>> the flow
>>>>>>>>> hash that I had
>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and 
>>>>>>>>> sch_hhf,
>>>>>>>>> failed,
>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>
>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, 
>>>>>>>>> tested the
>>>>>>>>> components,
>>>>>>>>> and was ready to release...
>>>>>>>>>
>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new 
>>>>>>>>> build now...
>>>>>>>>>
>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Dave Täht
>>>>>>>>>
>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>> _______________________________________________
>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>> 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
>>>>>>>
>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>> _______________________________________________
>>>>>> Cerowrt-devel mailing list
>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>
>
>

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

Hi Fred,

On Feb 20, 2014, at 14:57 , Fred Stratton <fredstratton@imap.cc> wrote:

> 
> On 20/02/14 13:56, Fred Stratton wrote:
>> The DSLAM at the exchange is an Infineon, Germany's finest.

	The issue I mentioned did not happen at the DSLAM so sync was not affected, but at the PPPoE termination point, the BRAS, which accidentally throttles a number of users below their rated bandwidths, rather obscure and since restricted to ADSL1 hopefully a legacy issue that will go away at latest once all ADSL1 line cards are retired...

>> 
>> I am using a 2Wire 2700 as the bridged connection device. The higher frequency bins, as graphed, as not optimally used. The device uses ADSL2+. The user cannot change this mode.
>> 
>> The 2Wire is very effective at suppressing impulse noise.
>> 
>> The line is uncapped, with unlimited downloads.

	Just as I remembered, that means that syncing at good line moments just does not leave enough slack-bits for worse-case scenarios, hence your approach to increase the line tolerance by increasing SNRM to be better equipped for your sync to survive the interference episodes… It is a pity that one can not really request the modem to only sync at a specific bandwidth directly.  

>> 
>> The RF Interference source is unknown. Possible culprits are
>> 
>> analogue to digital set top TV conversion boxes.
>> passing vehicles.
>> holes in the ionosphere.
>> 
>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>> 
>> I can find no PPPoE errors.

	Then I think that cerowrt should have no effect on the wan speed.

>> 
>> The neighbours, based on their SSIDs, are always changing ISPs, and so are not a constant source of RF interference in that sense.

	Well, evenif everybody uses BT's infrastructure there still can be some shared cable segments which can cause cross-talk. So even a local loop unbundled ISP that runs its own DSLAM-lincards at the central office will have some of its wire share a bundle with other ISP's wire along the lines to the Serving area interface, and that is sufficient for degradation of your line capacity. Only if your neighbors and you directly connect to two different outdoor slams/msans you would be not affected by their del usage. And if you suspect that they cause true RF interference, that can come easily in via the power lines… Since we humans have no good sense for electrical fields locating the source of RF interferes is a black art…

Best Regards
	Sebastian

>> 
>> 
>> On 20/02/14 13:15, Sebastian Moeller wrote:
>>> Hi Fred,
>>> 
>>> 
>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>> 
>>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>> 
>>>>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>>>>> 
>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.
>>>    Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)
>>> 
>>>>> Routerstats is not reliant on telnet.
>>>    Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...
>>> 
>>> 
>>>>> I appreciate the analysis, which I am sure is correct.
>>>    I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...
>>> 
>>>>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.
>>>    Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.
>>> 
>>>>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>>>>> 
>>>>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.
>>>    Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement.
>>> 
>>>>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.
>>>    You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions.
>>>    Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
>>>    (That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue).
>>> 
>>>>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.
>>>    I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)
>>> 
>>> 
>>> Best Regards
>>>    Sebastian
>>> 
>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>>> Hi Fred,
>>>>>> 
>>>>>> 
>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>> 
>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>> 
>>>>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>>>>    I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>>>>> 
>>>>>>    Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>>>>    However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>>>>    Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>>    A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>>>>> 
>>>>>> 
>>>>>> Best Regards
>>>>>>    Sebastian
>>>>>> 
>>>>>>> 
>>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>>>>> 
>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> David P.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>>>>> :)
>>>>>>>> 
>>>>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>>>>> the next couple days.
>>>>>>>> 
>>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>>> I killed some big packages while trying to get a new build done faster.
>>>>>>>> 
>>>>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>>> again, post disaster.
>>>>>>>> 
>>>>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>>>>> 
>>>>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>>>>> 
>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>>>>> to get the last of the instruction traps out of the way first. As of
>>>>>>>> this morning
>>>>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>>>>> 
>>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>>> a couple scenarios.
>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> David P.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>> 
>>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>>>>> but
>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>>>>> hash that I had
>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>>>>> failed,
>>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>> 
>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>>>>> components,
>>>>>>>>>> and was ready to release...
>>>>>>>>>> 
>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>>>>> 
>>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> Dave Täht
>>>>>>>>>> 
>>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>> 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
>>>>>>>> 
>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>> _______________________________________________
>>>>>>> Cerowrt-devel mailing list
>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>> 
>> 
>> 
> 

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Fred Stratton]

Aha.. beyond the DSLAM...

I was unaware of that BRAS PPPoE issue.

Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. 
The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or 
ADSL, specifically.

As you would expect ADSL had the least problems, and gave a full 8 
megabits/s.

The 2Wire has far fewer problems with the frequent lease renewals the 
ISP imposes. The TD-W8970 has odd problems.

You are correct. Most of the telephone cable is shared to the exchange. 
Most properties have a 10-pair cable, where only one pair is used. 
Bit-swapping is supposed to mitigate against crosstalk.

Even when FTTC appears, all cables will be adjacent up to the local 
MSAN. I doubt I shall go that route. I have cable outside the front door 
already, which nobody uses, as they are still trying to recoup their 
infrastructure costs - approx 1.5 milliard euro. All the pit covers say 
'NYNEX' on them.

To get back on-topic, I accept that it is unlikely that cero has 
affected the situation.



On 20/02/14 14:38, Sebastian Moeller wrote:
> Hi Fred,
>
> On Feb 20, 2014, at 14:57 , Fred Stratton <fredstratton@imap.cc> wrote:
>
>> On 20/02/14 13:56, Fred Stratton wrote:
>>> The DSLAM at the exchange is an Infineon, Germany's finest.
> 	The issue I mentioned did not happen at the DSLAM so sync was not affected, but at the PPPoE termination point, the BRAS, which accidentally throttles a number of users below their rated bandwidths, rather obscure and since restricted to ADSL1 hopefully a legacy issue that will go away at latest once all ADSL1 line cards are retired...
>
>>> I am using a 2Wire 2700 as the bridged connection device. The higher frequency bins, as graphed, as not optimally used. The device uses ADSL2+. The user cannot change this mode.
>>>
>>> The 2Wire is very effective at suppressing impulse noise.
>>>
>>> The line is uncapped, with unlimited downloads.
> 	Just as I remembered, that means that syncing at good line moments just does not leave enough slack-bits for worse-case scenarios, hence your approach to increase the line tolerance by increasing SNRM to be better equipped for your sync to survive the interference episodes… It is a pity that one can not really request the modem to only sync at a specific bandwidth directly.
>
>>> The RF Interference source is unknown. Possible culprits are
>>>
>>> analogue to digital set top TV conversion boxes.
>>> passing vehicles.
>>> holes in the ionosphere.
>>>
>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>>>
>>> I can find no PPPoE errors.
> 	Then I think that cerowrt should have no effect on the wan speed.
>
>>> The neighbours, based on their SSIDs, are always changing ISPs, and so are not a constant source of RF interference in that sense.
> 	Well, evenif everybody uses BT's infrastructure there still can be some shared cable segments which can cause cross-talk. So even a local loop unbundled ISP that runs its own DSLAM-lincards at the central office will have some of its wire share a bundle with other ISP's wire along the lines to the Serving area interface, and that is sufficient for degradation of your line capacity. Only if your neighbors and you directly connect to two different outdoor slams/msans you would be not affected by their del usage. And if you suspect that they cause true RF interference, that can come easily in via the power lines… Since we humans have no good sense for electrical fields locating the source of RF interferes is a black art…
>
> Best Regards
> 	Sebastian
>
>>>
>>> On 20/02/14 13:15, Sebastian Moeller wrote:
>>>> Hi Fred,
>>>>
>>>>
>>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>
>>>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>>>
>>>>>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>>>>>>
>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.
>>>>     Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)
>>>>
>>>>>> Routerstats is not reliant on telnet.
>>>>     Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...
>>>>
>>>>
>>>>>> I appreciate the analysis, which I am sure is correct.
>>>>     I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...
>>>>
>>>>>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.
>>>>     Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.
>>>>
>>>>>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>>>>>>
>>>>>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.
>>>>     Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement.
>>>>
>>>>>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.
>>>>     You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions.
>>>>     Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
>>>>     (That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue).
>>>>
>>>>>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.
>>>>     I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)
>>>>
>>>>
>>>> Best Regards
>>>>     Sebastian
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>>>> Hi Fred,
>>>>>>>
>>>>>>>
>>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>
>>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>>>
>>>>>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>>>>>     I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>>>>>>
>>>>>>>     Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>>>>>     However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>>>>>     Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>>>     A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>>     Sebastian
>>>>>>>
>>>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>>>>>>
>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> David P.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>>>>>> :)
>>>>>>>>>
>>>>>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>>>>>> the next couple days.
>>>>>>>>>
>>>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>>>> I killed some big packages while trying to get a new build done faster.
>>>>>>>>>
>>>>>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>>>> again, post disaster.
>>>>>>>>>
>>>>>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>>>>>>
>>>>>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>>>>>>
>>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>>>>>> to get the last of the instruction traps out of the way first. As of
>>>>>>>>> this morning
>>>>>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>>>>>>
>>>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>>>> a couple scenarios.
>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> David P.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>>>
>>>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>>>>>> but
>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>>>>>> hash that I had
>>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>>>>>> failed,
>>>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>>>
>>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>>>>>> components,
>>>>>>>>>>> and was ready to release...
>>>>>>>>>>>
>>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>>>>>>
>>>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Dave Täht
>>>>>>>>>>>
>>>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>> _______________________________________________
>>>>>>>> Cerowrt-devel mailing list
>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Dave Taht]

My take on any speedup seen with 3.10.28-14 is due to killing nearly
all the instruction traps.


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Fred Stratton]

On 20/02/14 17:49, Dave Taht wrote:
> My take on any speedup seen with 3.10.28-14 is due to killing nearly
> all the instruction traps.
>
>

You appear to have created a software construct of great beauty. It 
works very well.

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

Hi Fred,

On Feb 20, 2014, at 18:24 , Fred Stratton <fredstratton@imap.cc> wrote:

> Aha.. beyond the DSLAM...
> 
> I was unaware of that BRAS PPPoE issue.

	And there is no good reason to be aware of that particular screw-up :)

> 
> Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or ADSL, specifically.

	My observation in the past was that the DSLAM has to play along; if you try ADSL2 on a ADSL1 line card it will just not sync. Now the ISPs are free to expose several modes on the same line card if they want to. At least in Germany the trend seems to be combined VDSL2/ADSL2+ line cards (with ADSL2+ as fall back for long distances and customers with old modems)

> 
> As you would expect ADSL had the least problems, and gave a full 8 megabits/s.

	I could easily be off, but from looking at the standards I would have guessed that ADSL2+ would be more resilient against interference (at the same bandwidth as ADSL1 it should be more robust, but I assume most modems will trade this additional robustness for higher sync)

> 
> The 2Wire has far fewer problems with the frequent lease renewals the ISP imposes. The TD-W8970 has odd problems.

	Did you use openwrt on the TD-W8970 rot stock firmware?

> 
> You are correct. Most of the telephone cable is shared to the exchange. Most properties have a 10-pair cable, where only one pair is used. Bit-swapping is supposed to mitigate against crosstalk.

	Yes, but I can only do so much, vectoring will help a lot in that regard (by measuring the cross-talk and shaping all signals so that the look great after experiencing cross-talk; pretty cool technology, but also a computational expensive way to push the inevitable fiber-to-the-home further into the future).

> 
> Even when FTTC appears, all cables will be adjacent up to the local MSAN.

	This is why vectoring, with its promise to eradicate DSLAM NEXT and line FEXT almost completely, is going to help a lot. Since fiber is not an option, I am looking forward to switching to that, 100Mbit in 40 Mbit out also is a much saner asymmetry than my current 16in 2.5 out (which is actually quite reasonable for ADSL2+ ;) )

> I doubt I shall go that route. I have cable outside the front door already, which nobody uses, as they are still trying to recoup their infrastructure costs - approx 1.5 milliard euro. All the pit covers say 'NYNEX' on them.

	Well, in germany cable download looks quite nice but the upload with 5M max (2-4 typical) is not quite as good as current VDSL offers (10up) and definitely way off the promised 40up; also a cable node in germany shares ~400MBit among its users while VDSL typical shares 1Gbit.

best regards
	Sebastian

> 
> To get back on-topic, I accept that it is unlikely that cero has affected the situation.
> 
> 
> 
> On 20/02/14 14:38, Sebastian Moeller wrote:
>> Hi Fred,
>> 
>> On Feb 20, 2014, at 14:57 , Fred Stratton <fredstratton@imap.cc> wrote:
>> 
>>> On 20/02/14 13:56, Fred Stratton wrote:
>>>> The DSLAM at the exchange is an Infineon, Germany's finest.
>> 	The issue I mentioned did not happen at the DSLAM so sync was not affected, but at the PPPoE termination point, the BRAS, which accidentally throttles a number of users below their rated bandwidths, rather obscure and since restricted to ADSL1 hopefully a legacy issue that will go away at latest once all ADSL1 line cards are retired...
>> 
>>>> I am using a 2Wire 2700 as the bridged connection device. The higher frequency bins, as graphed, as not optimally used. The device uses ADSL2+. The user cannot change this mode.
>>>> 
>>>> The 2Wire is very effective at suppressing impulse noise.
>>>> 
>>>> The line is uncapped, with unlimited downloads.
>> 	Just as I remembered, that means that syncing at good line moments just does not leave enough slack-bits for worse-case scenarios, hence your approach to increase the line tolerance by increasing SNRM to be better equipped for your sync to survive the interference episodes… It is a pity that one can not really request the modem to only sync at a specific bandwidth directly.
>> 
>>>> The RF Interference source is unknown. Possible culprits are
>>>> 
>>>> analogue to digital set top TV conversion boxes.
>>>> passing vehicles.
>>>> holes in the ionosphere.
>>>> 
>>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>>>> 
>>>> I can find no PPPoE errors.
>> 	Then I think that cerowrt should have no effect on the wan speed.
>> 
>>>> The neighbours, based on their SSIDs, are always changing ISPs, and so are not a constant source of RF interference in that sense.
>> 	Well, evenif everybody uses BT's infrastructure there still can be some shared cable segments which can cause cross-talk. So even a local loop unbundled ISP that runs its own DSLAM-lincards at the central office will have some of its wire share a bundle with other ISP's wire along the lines to the Serving area interface, and that is sufficient for degradation of your line capacity. Only if your neighbors and you directly connect to two different outdoor slams/msans you would be not affected by their del usage. And if you suspect that they cause true RF interference, that can come easily in via the power lines… Since we humans have no good sense for electrical fields locating the source of RF interferes is a black art…
>> 
>> Best Regards
>> 	Sebastian
>> 
>>>> 
>>>> On 20/02/14 13:15, Sebastian Moeller wrote:
>>>>> Hi Fred,
>>>>> 
>>>>> 
>>>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>> 
>>>>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>>>> 
>>>>>>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>>>>>>> 
>>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.
>>>>>    Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)
>>>>> 
>>>>>>> Routerstats is not reliant on telnet.
>>>>>    Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...
>>>>> 
>>>>> 
>>>>>>> I appreciate the analysis, which I am sure is correct.
>>>>>    I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...
>>>>> 
>>>>>>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.
>>>>>    Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.
>>>>> 
>>>>>>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>>>>>>> 
>>>>>>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.
>>>>>    Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement.
>>>>> 
>>>>>>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.
>>>>>    You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions.
>>>>>    Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
>>>>>    (That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue).
>>>>> 
>>>>>>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.
>>>>>    I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)
>>>>> 
>>>>> 
>>>>> Best Regards
>>>>>    Sebastian
>>>>> 
>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>>>>> Hi Fred,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>> 
>>>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>>>> 
>>>>>>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>>>>>>    I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>>>>>>> 
>>>>>>>>    Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>>>>>>    However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>>>>>>    Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>>>>    A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Best Regards
>>>>>>>>    Sebastian
>>>>>>>> 
>>>>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>>>>>>> 
>>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> David P.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>>>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>>>>>>> :)
>>>>>>>>>> 
>>>>>>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>>>>>>> the next couple days.
>>>>>>>>>> 
>>>>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>>>>> I killed some big packages while trying to get a new build done faster.
>>>>>>>>>> 
>>>>>>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>>>>> again, post disaster.
>>>>>>>>>> 
>>>>>>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>>>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>>>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>>>>>>> 
>>>>>>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>>>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>>>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>>>>>>> 
>>>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>>>>>>> to get the last of the instruction traps out of the way first. As of
>>>>>>>>>> this morning
>>>>>>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>>>>>>> 
>>>>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>>>>> a couple scenarios.
>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> David P.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>>>> 
>>>>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>>>>>>> but
>>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>>>>>>> hash that I had
>>>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>>>>>>> failed,
>>>>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>>>> 
>>>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>>>>>>> components,
>>>>>>>>>>>> and was ready to release...
>>>>>>>>>>>> 
>>>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>>>>>>> 
>>>>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>> 
>>>>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>>> _______________________________________________
>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>> 
> 
> 

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

Hi Dave,


On Feb 20, 2014, at 18:49 , Dave Taht <dave.taht@gmail.com> wrote:

> My take on any speedup seen with 3.10.28-14 is due to killing nearly
> all the instruction traps.

root@nacktmulle:~# uptime
 21:08:53 up 20:28,  load average: 0.08, 0.04, 0.05
root@nacktmulle:~# cat /sys/kernel/debug/mips/unaligned_instructions
0
root@nacktmulle:~# cat /sys/kernel/debug/mips/unaligned_action 
2
root@nacktmulle:~# 

So far none!

many thanks & best regards
	Sebastian


> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Fred Stratton]

ADSL2+ is better than ADSL in this context, as you point out. I thought 
it was worth trying for a week or two, rather than relying solely on the 
literature.

The combined VDSL2/ADSL2+ approach is interesting. It is unlikely to 
happen here,as BT  has an effective monopoly of fibre since its 
publicly-owned competitor went bankrupt.

You must be using Annex M, which here is now mainly for business use, at 
extra cost.

OpenWRT test builds require an older version of uboot than the one 
TP-Link uses. There is no easy regression path,and the builds are 
immature. They will never allow a choice between ADSL,ADSL2, AND ADSL2+.

Although blogic is principal developer in Berlin, the majority of work 
has been done in Polen.

Ich kann Deutsch verstehen, (the British Royal Family is more German 
than a BMW) but I find Polish far more difficult.


On 20/02/14 20:08, Sebastian Moeller wrote:
> Hi Fred,
>
> On Feb 20, 2014, at 18:24 , Fred Stratton <fredstratton@imap.cc> wrote:
>
>> Aha.. beyond the DSLAM...
>>
>> I was unaware of that BRAS PPPoE issue.
> 	And there is no good reason to be aware of that particular screw-up :)
>
>> Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or ADSL, specifically.
> 	My observation in the past was that the DSLAM has to play along; if you try ADSL2 on a ADSL1 line card it will just not sync. Now the ISPs are free to expose several modes on the same line card if they want to. At least in Germany the trend seems to be combined VDSL2/ADSL2+ line cards (with ADSL2+ as fall back for long distances and customers with old modems)
>
>> As you would expect ADSL had the least problems, and gave a full 8 megabits/s.
> 	I could easily be off, but from looking at the standards I would have guessed that ADSL2+ would be more resilient against interference (at the same bandwidth as ADSL1 it should be more robust, but I assume most modems will trade this additional robustness for higher sync)
>
>> The 2Wire has far fewer problems with the frequent lease renewals the ISP imposes. The TD-W8970 has odd problems.
> 	Did you use openwrt on the TD-W8970 rot stock firmware?
>
>> You are correct. Most of the telephone cable is shared to the exchange. Most properties have a 10-pair cable, where only one pair is used. Bit-swapping is supposed to mitigate against crosstalk.
> 	Yes, but I can only do so much, vectoring will help a lot in that regard (by measuring the cross-talk and shaping all signals so that the look great after experiencing cross-talk; pretty cool technology, but also a computational expensive way to push the inevitable fiber-to-the-home further into the future).
>
>> Even when FTTC appears, all cables will be adjacent up to the local MSAN.
> 	This is why vectoring, with its promise to eradicate DSLAM NEXT and line FEXT almost completely, is going to help a lot. Since fiber is not an option, I am looking forward to switching to that, 100Mbit in 40 Mbit out also is a much saner asymmetry than my current 16in 2.5 out (which is actually quite reasonable for ADSL2+ ;) )
>
>> I doubt I shall go that route. I have cable outside the front door already, which nobody uses, as they are still trying to recoup their infrastructure costs - approx 1.5 milliard euro. All the pit covers say 'NYNEX' on them.
> 	Well, in germany cable download looks quite nice but the upload with 5M max (2-4 typical) is not quite as good as current VDSL offers (10up) and definitely way off the promised 40up; also a cable node in germany shares ~400MBit among its users while VDSL typical shares 1Gbit.
>
> best regards
> 	Sebastian
>
>> To get back on-topic, I accept that it is unlikely that cero has affected the situation.
>>
>>
>>
>> On 20/02/14 14:38, Sebastian Moeller wrote:
>>> Hi Fred,
>>>
>>> On Feb 20, 2014, at 14:57 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>
>>>> On 20/02/14 13:56, Fred Stratton wrote:
>>>>> The DSLAM at the exchange is an Infineon, Germany's finest.
>>> 	The issue I mentioned did not happen at the DSLAM so sync was not affected, but at the PPPoE termination point, the BRAS, which accidentally throttles a number of users below their rated bandwidths, rather obscure and since restricted to ADSL1 hopefully a legacy issue that will go away at latest once all ADSL1 line cards are retired...
>>>
>>>>> I am using a 2Wire 2700 as the bridged connection device. The higher frequency bins, as graphed, as not optimally used. The device uses ADSL2+. The user cannot change this mode.
>>>>>
>>>>> The 2Wire is very effective at suppressing impulse noise.
>>>>>
>>>>> The line is uncapped, with unlimited downloads.
>>> 	Just as I remembered, that means that syncing at good line moments just does not leave enough slack-bits for worse-case scenarios, hence your approach to increase the line tolerance by increasing SNRM to be better equipped for your sync to survive the interference episodes… It is a pity that one can not really request the modem to only sync at a specific bandwidth directly.
>>>
>>>>> The RF Interference source is unknown. Possible culprits are
>>>>>
>>>>> analogue to digital set top TV conversion boxes.
>>>>> passing vehicles.
>>>>> holes in the ionosphere.
>>>>>
>>>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>>>>>
>>>>> I can find no PPPoE errors.
>>> 	Then I think that cerowrt should have no effect on the wan speed.
>>>
>>>>> The neighbours, based on their SSIDs, are always changing ISPs, and so are not a constant source of RF interference in that sense.
>>> 	Well, evenif everybody uses BT's infrastructure there still can be some shared cable segments which can cause cross-talk. So even a local loop unbundled ISP that runs its own DSLAM-lincards at the central office will have some of its wire share a bundle with other ISP's wire along the lines to the Serving area interface, and that is sufficient for degradation of your line capacity. Only if your neighbors and you directly connect to two different outdoor slams/msans you would be not affected by their del usage. And if you suspect that they cause true RF interference, that can come easily in via the power lines… Since we humans have no good sense for electrical fields locating the source of RF interferes is a black art…
>>>
>>> Best Regards
>>> 	Sebastian
>>>
>>>>> On 20/02/14 13:15, Sebastian Moeller wrote:
>>>>>> Hi Fred,
>>>>>>
>>>>>>
>>>>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>
>>>>>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>>>>>
>>>>>>>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>>>>>>>>
>>>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.
>>>>>>     Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)
>>>>>>
>>>>>>>> Routerstats is not reliant on telnet.
>>>>>>     Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...
>>>>>>
>>>>>>
>>>>>>>> I appreciate the analysis, which I am sure is correct.
>>>>>>     I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...
>>>>>>
>>>>>>>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.
>>>>>>     Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.
>>>>>>
>>>>>>>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>>>>>>>>
>>>>>>>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.
>>>>>>     Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement.
>>>>>>
>>>>>>>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.
>>>>>>     You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions.
>>>>>>     Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
>>>>>>     (That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue).
>>>>>>
>>>>>>>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.
>>>>>>     I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>     Sebastian
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>>>>>> Hi Fred,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>>>
>>>>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>>>>>
>>>>>>>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>>>>>>>     I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>>>>>>>>
>>>>>>>>>     Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>>>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>>>>>>>     However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>>>>>>>     Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>>>>>     A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>     Sebastian
>>>>>>>>>
>>>>>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>>>>>>>>
>>>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> David P.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>>>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>>>>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>>>>>>>> :)
>>>>>>>>>>>
>>>>>>>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>>>>>>>> the next couple days.
>>>>>>>>>>>
>>>>>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>>>>>> I killed some big packages while trying to get a new build done faster.
>>>>>>>>>>>
>>>>>>>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>>>>>> again, post disaster.
>>>>>>>>>>>
>>>>>>>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>>>>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>>>>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>>>>>>>>
>>>>>>>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>>>>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>>>>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>>>>>>>>
>>>>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>>>>>>>> to get the last of the instruction traps out of the way first. As of
>>>>>>>>>>> this morning
>>>>>>>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>>>>>>>>
>>>>>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>>>>>> a couple scenarios.
>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> David P.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>>>>>>>> but
>>>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>>>>>>>> hash that I had
>>>>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>>>>>>>> failed,
>>>>>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>>>>>>>> components,
>>>>>>>>>>>>> and was ready to release...
>>>>>>>>>>>>>
>>>>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>>>>>>>>
>>>>>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>>>
>>>>>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Sebastian Moeller]

Hi Fred,


On Feb 20, 2014, at 21:42 , Fred Stratton <fredstratton@imap.cc> wrote:

> ADSL2+ is better than ADSL in this context, as you point out. I thought it was worth trying for a week or two, rather than relying solely on the literature.

	So in your tests ADSL came up as the most stable solution, interesting, real data always beats theory. Could well be the actual modem hardware, ADSL only uses half the frequencies or the modem driver. Or maybe your RF interferer affects the higher frequencies more. Would be interesting to see a time resolved series of SNRM per bin plots during on of your REINs...

> 
> The combined VDSL2/ADSL2+ approach is interesting. It is unlikely to happen here,

	I think this is the future; ATM equipment is dying and telcos try to get away from it consolidating on an ethernet based concentration network. I am not sure whether there are any more new ADSL1 line cards for non-ATM DSLAMs. But I could be off here as always.


> as BT  has an effective monopoly of fibre since its publicly-owned competitor went bankrupt.

	Yeah, but even BT probably wants to retire its ATM gear and that means replacing all DSLAMs (well the guts of the zDSLAMs). Their backbone most likely is already pure IP and if they can get rid of the ATM gear it will dave money, so thee is something in it for them ;)

> 
> You must be using Annex M, which here is now mainly for business use, at extra cost.

	Well its Annex J (see: http://en.wikipedia.org/wiki/G.992.3_Annex_J) which deutsche telekom pushes as it allows coexistence with its old Annex B band plan that allowed DSL to coexist with ISDN. Both POTS and ISDN will be retired in Germany and replaced with carrier voice over IP. So everybody using ISDN (and everyone using DSL and POTS) will need to be switched to all-ip; to sweeten the change people are also getting annex J which gives a much better upload than typical for ADSL variants. That is sort of the publics dividend of the switch to all-ip ;)

> 
> OpenWRT test builds require an older version of uboot than the one TP-Link uses. There is no easy regression path,and the builds are immature. They will never allow a choice between ADSL,ADSL2, AND ADSL2+.

	For most users the DSLAMs are fixed to the type sold in the plan, so switching will most likely not work anyways.

> 
> Although blogic is principal developer in Berlin, the majority of work has been done in Polen.
> 
> Ich kann Deutsch verstehen, (the British Royal Family is more German than a BMW) but I find Polish far more difficult.

	Oh, gut, ich kann Deutsch ganz passabel schreiben ;)

Best Regards
	Sebastian

> 
> 
> On 20/02/14 20:08, Sebastian Moeller wrote:
>> Hi Fred,
>> 
>> On Feb 20, 2014, at 18:24 , Fred Stratton <fredstratton@imap.cc> wrote:
>> 
>>> Aha.. beyond the DSLAM...
>>> 
>>> I was unaware of that BRAS PPPoE issue.
>> 	And there is no good reason to be aware of that particular screw-up :)
>> 
>>> Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or ADSL, specifically.
>> 	My observation in the past was that the DSLAM has to play along; if you try ADSL2 on a ADSL1 line card it will just not sync. Now the ISPs are free to expose several modes on the same line card if they want to. At least in Germany the trend seems to be combined VDSL2/ADSL2+ line cards (with ADSL2+ as fall back for long distances and customers with old modems)
>> 
>>> As you would expect ADSL had the least problems, and gave a full 8 megabits/s.
>> 	I could easily be off, but from looking at the standards I would have guessed that ADSL2+ would be more resilient against interference (at the same bandwidth as ADSL1 it should be more robust, but I assume most modems will trade this additional robustness for higher sync)
>> 
>>> The 2Wire has far fewer problems with the frequent lease renewals the ISP imposes. The TD-W8970 has odd problems.
>> 	Did you use openwrt on the TD-W8970 rot stock firmware?
>> 
>>> You are correct. Most of the telephone cable is shared to the exchange. Most properties have a 10-pair cable, where only one pair is used. Bit-swapping is supposed to mitigate against crosstalk.
>> 	Yes, but I can only do so much, vectoring will help a lot in that regard (by measuring the cross-talk and shaping all signals so that the look great after experiencing cross-talk; pretty cool technology, but also a computational expensive way to push the inevitable fiber-to-the-home further into the future).
>> 
>>> Even when FTTC appears, all cables will be adjacent up to the local MSAN.
>> 	This is why vectoring, with its promise to eradicate DSLAM NEXT and line FEXT almost completely, is going to help a lot. Since fiber is not an option, I am looking forward to switching to that, 100Mbit in 40 Mbit out also is a much saner asymmetry than my current 16in 2.5 out (which is actually quite reasonable for ADSL2+ ;) )
>> 
>>> I doubt I shall go that route. I have cable outside the front door already, which nobody uses, as they are still trying to recoup their infrastructure costs - approx 1.5 milliard euro. All the pit covers say 'NYNEX' on them.
>> 	Well, in germany cable download looks quite nice but the upload with 5M max (2-4 typical) is not quite as good as current VDSL offers (10up) and definitely way off the promised 40up; also a cable node in germany shares ~400MBit among its users while VDSL typical shares 1Gbit.
>> 
>> best regards
>> 	Sebastian
>> 
>>> To get back on-topic, I accept that it is unlikely that cero has affected the situation.
>>> 
>>> 
>>> 
>>> On 20/02/14 14:38, Sebastian Moeller wrote:
>>>> Hi Fred,
>>>> 
>>>> On Feb 20, 2014, at 14:57 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>> 
>>>>> On 20/02/14 13:56, Fred Stratton wrote:
>>>>>> The DSLAM at the exchange is an Infineon, Germany's finest.
>>>> 	The issue I mentioned did not happen at the DSLAM so sync was not affected, but at the PPPoE termination point, the BRAS, which accidentally throttles a number of users below their rated bandwidths, rather obscure and since restricted to ADSL1 hopefully a legacy issue that will go away at latest once all ADSL1 line cards are retired...
>>>> 
>>>>>> I am using a 2Wire 2700 as the bridged connection device. The higher frequency bins, as graphed, as not optimally used. The device uses ADSL2+. The user cannot change this mode.
>>>>>> 
>>>>>> The 2Wire is very effective at suppressing impulse noise.
>>>>>> 
>>>>>> The line is uncapped, with unlimited downloads.
>>>> 	Just as I remembered, that means that syncing at good line moments just does not leave enough slack-bits for worse-case scenarios, hence your approach to increase the line tolerance by increasing SNRM to be better equipped for your sync to survive the interference episodes… It is a pity that one can not really request the modem to only sync at a specific bandwidth directly.
>>>> 
>>>>>> The RF Interference source is unknown. Possible culprits are
>>>>>> 
>>>>>> analogue to digital set top TV conversion boxes.
>>>>>> passing vehicles.
>>>>>> holes in the ionosphere.
>>>>>> 
>>>>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>>>>>> 
>>>>>> I can find no PPPoE errors.
>>>> 	Then I think that cerowrt should have no effect on the wan speed.
>>>> 
>>>>>> The neighbours, based on their SSIDs, are always changing ISPs, and so are not a constant source of RF interference in that sense.
>>>> 	Well, evenif everybody uses BT's infrastructure there still can be some shared cable segments which can cause cross-talk. So even a local loop unbundled ISP that runs its own DSLAM-lincards at the central office will have some of its wire share a bundle with other ISP's wire along the lines to the Serving area interface, and that is sufficient for degradation of your line capacity. Only if your neighbors and you directly connect to two different outdoor slams/msans you would be not affected by their del usage. And if you suspect that they cause true RF interference, that can come easily in via the power lines… Since we humans have no good sense for electrical fields locating the source of RF interferes is a black art…
>>>> 
>>>> Best Regards
>>>> 	Sebastian
>>>> 
>>>>>> On 20/02/14 13:15, Sebastian Moeller wrote:
>>>>>>> Hi Fred,
>>>>>>> 
>>>>>>> 
>>>>>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>> 
>>>>>>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>>>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>>>>>> 
>>>>>>>>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>>>>>>>>> 
>>>>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.
>>>>>>>    Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)
>>>>>>> 
>>>>>>>>> Routerstats is not reliant on telnet.
>>>>>>>    Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...
>>>>>>> 
>>>>>>> 
>>>>>>>>> I appreciate the analysis, which I am sure is correct.
>>>>>>>    I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...
>>>>>>> 
>>>>>>>>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.
>>>>>>>    Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.
>>>>>>> 
>>>>>>>>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>>>>>>>>> 
>>>>>>>>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.
>>>>>>>    Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement.
>>>>>>> 
>>>>>>>>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.
>>>>>>>    You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions.
>>>>>>>    Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
>>>>>>>    (That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue).
>>>>>>> 
>>>>>>>>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.
>>>>>>>    I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)
>>>>>>> 
>>>>>>> 
>>>>>>> Best Regards
>>>>>>>    Sebastian
>>>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>>>>>>> Hi Fred,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>>>> 
>>>>>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>>>>>> 
>>>>>>>>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>>>>>>>>    I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>>>>>>>>> 
>>>>>>>>>>    Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>>>>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>>>>>>>>    However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>>>>>>>>    Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>>>>>>    A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Best Regards
>>>>>>>>>>    Sebastian
>>>>>>>>>> 
>>>>>>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>>>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>>>>>>>>> 
>>>>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>>>>>>>>> 
>>>>>>>>>>>> -- 
>>>>>>>>>>>> David P.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>>>>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>>>>>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>>>>>>>>> :)
>>>>>>>>>>>> 
>>>>>>>>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>>>>>>>>> the next couple days.
>>>>>>>>>>>> 
>>>>>>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>>>>>>> I killed some big packages while trying to get a new build done faster.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>>>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>>>>>>> again, post disaster.
>>>>>>>>>>>> 
>>>>>>>>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>>>>>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>>>>>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>>>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>>>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>>>>>>>>> 
>>>>>>>>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>>>>>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>>>>>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>>>>>>>>> 
>>>>>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>>>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>>>>>>>>> to get the last of the instruction traps out of the way first. As of
>>>>>>>>>>>> this morning
>>>>>>>>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>>>>>>>>> 
>>>>>>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>>>>>>> a couple scenarios.
>>>>>>>>>>>> 
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> David P.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>>>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>>>>>>>>> hash that I had
>>>>>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>>>>>>>>> failed,
>>>>>>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>>>>>>>>> components,
>>>>>>>>>>>>>> and was ready to release...
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>>>> 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
>>>>>>>>>>>> 
>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>> 
> 
> 

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Rich Brown]

Hi Fred and Sebastian,

I just want to say that I have enjoyed reading this thread. Even though I'm an electrical engineer by training, I sorta thought DSL "just worked" - plug the phone line in one side of the modem, plug the router into the other, and Presto! You're on the air. I had no idea there were all these considerations. (Fortunately, for customers, my mental model is pretty close to what you need to know.)

Best,

Rich

On Feb 20, 2014, at 5:18 PM, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Fred,
> 
> 
> On Feb 20, 2014, at 21:42 , Fred Stratton <fredstratton@imap.cc> wrote:
> 
>> ADSL2+ is better than ADSL in this context, as you point out. I thought it was worth trying for a week or two, rather than relying solely on the literature.
> 
> 	So in your tests ADSL came up as the most stable solution, interesting, real data always beats theory. Could well be the actual modem hardware, ADSL only uses half the frequencies or the modem driver. Or maybe your RF interferer affects the higher frequencies more. Would be interesting to see a time resolved series of SNRM per bin plots during on of your REINs...
> 
>> 
>> The combined VDSL2/ADSL2+ approach is interesting. It is unlikely to happen here,
> 
> 	I think this is the future; ATM equipment is dying and telcos try to get away from it consolidating on an ethernet based concentration network. I am not sure whether there are any more new ADSL1 line cards for non-ATM DSLAMs. But I could be off here as always.
> 
> 
>> as BT  has an effective monopoly of fibre since its publicly-owned competitor went bankrupt.
> 
> 	Yeah, but even BT probably wants to retire its ATM gear and that means replacing all DSLAMs (well the guts of the zDSLAMs). Their backbone most likely is already pure IP and if they can get rid of the ATM gear it will dave money, so thee is something in it for them ;)
> 
>> 
>> You must be using Annex M, which here is now mainly for business use, at extra cost.
> 
> 	Well its Annex J (see: http://en.wikipedia.org/wiki/G.992.3_Annex_J) which deutsche telekom pushes as it allows coexistence with its old Annex B band plan that allowed DSL to coexist with ISDN. Both POTS and ISDN will be retired in Germany and replaced with carrier voice over IP. So everybody using ISDN (and everyone using DSL and POTS) will need to be switched to all-ip; to sweeten the change people are also getting annex J which gives a much better upload than typical for ADSL variants. That is sort of the publics dividend of the switch to all-ip ;)
> 
>> 
>> OpenWRT test builds require an older version of uboot than the one TP-Link uses. There is no easy regression path,and the builds are immature. They will never allow a choice between ADSL,ADSL2, AND ADSL2+.
> 
> 	For most users the DSLAMs are fixed to the type sold in the plan, so switching will most likely not work anyways.
> 
>> 
>> Although blogic is principal developer in Berlin, the majority of work has been done in Polen.
>> 
>> Ich kann Deutsch verstehen, (the British Royal Family is more German than a BMW) but I find Polish far more difficult.
> 
> 	Oh, gut, ich kann Deutsch ganz passabel schreiben ;)
> 
> Best Regards
> 	Sebastian
> 
>> 
>> 
>> On 20/02/14 20:08, Sebastian Moeller wrote:
>>> Hi Fred,
>>> 
>>> On Feb 20, 2014, at 18:24 , Fred Stratton <fredstratton@imap.cc> wrote:
>>> 
>>>> Aha.. beyond the DSLAM...
>>>> 
>>>> I was unaware of that BRAS PPPoE issue.
>>> 	And there is no good reason to be aware of that particular screw-up :)
>>> 
>>>> Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or ADSL, specifically.
>>> 	My observation in the past was that the DSLAM has to play along; if you try ADSL2 on a ADSL1 line card it will just not sync. Now the ISPs are free to expose several modes on the same line card if they want to. At least in Germany the trend seems to be combined VDSL2/ADSL2+ line cards (with ADSL2+ as fall back for long distances and customers with old modems)
>>> 
>>>> As you would expect ADSL had the least problems, and gave a full 8 megabits/s.
>>> 	I could easily be off, but from looking at the standards I would have guessed that ADSL2+ would be more resilient against interference (at the same bandwidth as ADSL1 it should be more robust, but I assume most modems will trade this additional robustness for higher sync)
>>> 
>>>> The 2Wire has far fewer problems with the frequent lease renewals the ISP imposes. The TD-W8970 has odd problems.
>>> 	Did you use openwrt on the TD-W8970 rot stock firmware?
>>> 
>>>> You are correct. Most of the telephone cable is shared to the exchange. Most properties have a 10-pair cable, where only one pair is used. Bit-swapping is supposed to mitigate against crosstalk.
>>> 	Yes, but I can only do so much, vectoring will help a lot in that regard (by measuring the cross-talk and shaping all signals so that the look great after experiencing cross-talk; pretty cool technology, but also a computational expensive way to push the inevitable fiber-to-the-home further into the future).
>>> 
>>>> Even when FTTC appears, all cables will be adjacent up to the local MSAN.
>>> 	This is why vectoring, with its promise to eradicate DSLAM NEXT and line FEXT almost completely, is going to help a lot. Since fiber is not an option, I am looking forward to switching to that, 100Mbit in 40 Mbit out also is a much saner asymmetry than my current 16in 2.5 out (which is actually quite reasonable for ADSL2+ ;) )
>>> 
>>>> I doubt I shall go that route. I have cable outside the front door already, which nobody uses, as they are still trying to recoup their infrastructure costs - approx 1.5 milliard euro. All the pit covers say 'NYNEX' on them.
>>> 	Well, in germany cable download looks quite nice but the upload with 5M max (2-4 typical) is not quite as good as current VDSL offers (10up) and definitely way off the promised 40up; also a cable node in germany shares ~400MBit among its users while VDSL typical shares 1Gbit.
>>> 
>>> best regards
>>> 	Sebastian
>>> 
>>>> To get back on-topic, I accept that it is unlikely that cero has affected the situation.
>>>> 
>>>> 
>>>> 
>>>> On 20/02/14 14:38, Sebastian Moeller wrote:
>>>>> Hi Fred,
>>>>> 
>>>>> On Feb 20, 2014, at 14:57 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>> 
>>>>>> On 20/02/14 13:56, Fred Stratton wrote:
>>>>>>> The DSLAM at the exchange is an Infineon, Germany's finest.
>>>>> 	The issue I mentioned did not happen at the DSLAM so sync was not affected, but at the PPPoE termination point, the BRAS, which accidentally throttles a number of users below their rated bandwidths, rather obscure and since restricted to ADSL1 hopefully a legacy issue that will go away at latest once all ADSL1 line cards are retired...
>>>>> 
>>>>>>> I am using a 2Wire 2700 as the bridged connection device. The higher frequency bins, as graphed, as not optimally used. The device uses ADSL2+. The user cannot change this mode.
>>>>>>> 
>>>>>>> The 2Wire is very effective at suppressing impulse noise.
>>>>>>> 
>>>>>>> The line is uncapped, with unlimited downloads.
>>>>> 	Just as I remembered, that means that syncing at good line moments just does not leave enough slack-bits for worse-case scenarios, hence your approach to increase the line tolerance by increasing SNRM to be better equipped for your sync to survive the interference episodes… It is a pity that one can not really request the modem to only sync at a specific bandwidth directly.
>>>>> 
>>>>>>> The RF Interference source is unknown. Possible culprits are
>>>>>>> 
>>>>>>> analogue to digital set top TV conversion boxes.
>>>>>>> passing vehicles.
>>>>>>> holes in the ionosphere.
>>>>>>> 
>>>>>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>>>>>>> 
>>>>>>> I can find no PPPoE errors.
>>>>> 	Then I think that cerowrt should have no effect on the wan speed.
>>>>> 
>>>>>>> The neighbours, based on their SSIDs, are always changing ISPs, and so are not a constant source of RF interference in that sense.
>>>>> 	Well, evenif everybody uses BT's infrastructure there still can be some shared cable segments which can cause cross-talk. So even a local loop unbundled ISP that runs its own DSLAM-lincards at the central office will have some of its wire share a bundle with other ISP's wire along the lines to the Serving area interface, and that is sufficient for degradation of your line capacity. Only if your neighbors and you directly connect to two different outdoor slams/msans you would be not affected by their del usage. And if you suspect that they cause true RF interference, that can come easily in via the power lines… Since we humans have no good sense for electrical fields locating the source of RF interferes is a black art…
>>>>> 
>>>>> Best Regards
>>>>> 	Sebastian
>>>>> 
>>>>>>> On 20/02/14 13:15, Sebastian Moeller wrote:
>>>>>>>> Hi Fred,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>> 
>>>>>>>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>>>>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>>>>>>> 
>>>>>>>>>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>>>>>>>>>> 
>>>>>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.
>>>>>>>>   Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)
>>>>>>>> 
>>>>>>>>>> Routerstats is not reliant on telnet.
>>>>>>>>   Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> I appreciate the analysis, which I am sure is correct.
>>>>>>>>   I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...
>>>>>>>> 
>>>>>>>>>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.
>>>>>>>>   Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.
>>>>>>>> 
>>>>>>>>>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>>>>>>>>>> 
>>>>>>>>>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.
>>>>>>>>   Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement.
>>>>>>>> 
>>>>>>>>>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.
>>>>>>>>   You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions.
>>>>>>>>   Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
>>>>>>>>   (That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue).
>>>>>>>> 
>>>>>>>>>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.
>>>>>>>>   I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Best Regards
>>>>>>>>   Sebastian
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>>>>>>>> Hi Fred,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>>>>>>> 
>>>>>>>>>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>>>>>>>>>   I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>>>>>>>>>> 
>>>>>>>>>>>   Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>>>>>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>>>>>>>>>   However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>>>>>>>>>   Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>>>>>>>   A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Best Regards
>>>>>>>>>>>   Sebastian
>>>>>>>>>>> 
>>>>>>>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>>>>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> David P.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>>>>>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>>>>>>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>>>>>>>>>> :)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>>>>>>>>>> the next couple days.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>>>>>>>> I killed some big packages while trying to get a new build done faster.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>>>>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>>>>>>>> again, post disaster.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>>>>>>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>>>>>>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>>>>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>>>>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>>>>>>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>>>>>>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>>>>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>>>>>>>>>> to get the last of the instruction traps out of the way first. As of
>>>>>>>>>>>>> this morning
>>>>>>>>>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>>>>>>>> a couple scenarios.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> David P.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>>>>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>>>>>>>>>> hash that I had
>>>>>>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>>>>>>>>>> failed,
>>>>>>>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>>>>>>>>>> components,
>>>>>>>>>>>>>>> and was ready to release...
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>> 
>> 
>> 
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] just when I thought it was safe to do a release

[Fred Stratton]

I would encourage ADSL users in America to monitor line statistics. 
There are also a lot of tricks the consumer can use to improve 
connection stability, widely discussed and implemented in the UK. I also 
continue to be amazed by the practice of using the CPE supplied by the 
ISP, when experimentation can produce a better solution.


On 21/02/14 13:12, Rich Brown wrote:
> Hi Fred and Sebastian,
>
> I just want to say that I have enjoyed reading this thread. Even though I'm an electrical engineer by training, I sorta thought DSL "just worked" - plug the phone line in one side of the modem, plug the router into the other, and Presto! You're on the air. I had no idea there were all these considerations. (Fortunately, for customers, my mental model is pretty close to what you need to know.)
>
> Best,
>
> Rich
>
> On Feb 20, 2014, at 5:18 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Fred,
>>
>>
>> On Feb 20, 2014, at 21:42 , Fred Stratton <fredstratton@imap.cc> wrote:
>>
>>> ADSL2+ is better than ADSL in this context, as you point out. I thought it was worth trying for a week or two, rather than relying solely on the literature.
>> 	So in your tests ADSL came up as the most stable solution, interesting, real data always beats theory. Could well be the actual modem hardware, ADSL only uses half the frequencies or the modem driver. Or maybe your RF interferer affects the higher frequencies more. Would be interesting to see a time resolved series of SNRM per bin plots during on of your REINs...
>>
>>> The combined VDSL2/ADSL2+ approach is interesting. It is unlikely to happen here,
>> 	I think this is the future; ATM equipment is dying and telcos try to get away from it consolidating on an ethernet based concentration network. I am not sure whether there are any more new ADSL1 line cards for non-ATM DSLAMs. But I could be off here as always.
>>
>>
>>> as BT  has an effective monopoly of fibre since its publicly-owned competitor went bankrupt.
>> 	Yeah, but even BT probably wants to retire its ATM gear and that means replacing all DSLAMs (well the guts of the zDSLAMs). Their backbone most likely is already pure IP and if they can get rid of the ATM gear it will dave money, so thee is something in it for them ;)
>>
>>> You must be using Annex M, which here is now mainly for business use, at extra cost.
>> 	Well its Annex J (see: http://en.wikipedia.org/wiki/G.992.3_Annex_J) which deutsche telekom pushes as it allows coexistence with its old Annex B band plan that allowed DSL to coexist with ISDN. Both POTS and ISDN will be retired in Germany and replaced with carrier voice over IP. So everybody using ISDN (and everyone using DSL and POTS) will need to be switched to all-ip; to sweeten the change people are also getting annex J which gives a much better upload than typical for ADSL variants. That is sort of the publics dividend of the switch to all-ip ;)
>>
>>> OpenWRT test builds require an older version of uboot than the one TP-Link uses. There is no easy regression path,and the builds are immature. They will never allow a choice between ADSL,ADSL2, AND ADSL2+.
>> 	For most users the DSLAMs are fixed to the type sold in the plan, so switching will most likely not work anyways.
>>
>>> Although blogic is principal developer in Berlin, the majority of work has been done in Polen.
>>>
>>> Ich kann Deutsch verstehen, (the British Royal Family is more German than a BMW) but I find Polish far more difficult.
>> 	Oh, gut, ich kann Deutsch ganz passabel schreiben ;)
>>
>> Best Regards
>> 	Sebastian
>>
>>>
>>> On 20/02/14 20:08, Sebastian Moeller wrote:
>>>> Hi Fred,
>>>>
>>>> On Feb 20, 2014, at 18:24 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>
>>>>> Aha.. beyond the DSLAM...
>>>>>
>>>>> I was unaware of that BRAS PPPoE issue.
>>>> 	And there is no good reason to be aware of that particular screw-up :)
>>>>
>>>>> Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or ADSL, specifically.
>>>> 	My observation in the past was that the DSLAM has to play along; if you try ADSL2 on a ADSL1 line card it will just not sync. Now the ISPs are free to expose several modes on the same line card if they want to. At least in Germany the trend seems to be combined VDSL2/ADSL2+ line cards (with ADSL2+ as fall back for long distances and customers with old modems)
>>>>
>>>>> As you would expect ADSL had the least problems, and gave a full 8 megabits/s.
>>>> 	I could easily be off, but from looking at the standards I would have guessed that ADSL2+ would be more resilient against interference (at the same bandwidth as ADSL1 it should be more robust, but I assume most modems will trade this additional robustness for higher sync)
>>>>
>>>>> The 2Wire has far fewer problems with the frequent lease renewals the ISP imposes. The TD-W8970 has odd problems.
>>>> 	Did you use openwrt on the TD-W8970 rot stock firmware?
>>>>
>>>>> You are correct. Most of the telephone cable is shared to the exchange. Most properties have a 10-pair cable, where only one pair is used. Bit-swapping is supposed to mitigate against crosstalk.
>>>> 	Yes, but I can only do so much, vectoring will help a lot in that regard (by measuring the cross-talk and shaping all signals so that the look great after experiencing cross-talk; pretty cool technology, but also a computational expensive way to push the inevitable fiber-to-the-home further into the future).
>>>>
>>>>> Even when FTTC appears, all cables will be adjacent up to the local MSAN.
>>>> 	This is why vectoring, with its promise to eradicate DSLAM NEXT and line FEXT almost completely, is going to help a lot. Since fiber is not an option, I am looking forward to switching to that, 100Mbit in 40 Mbit out also is a much saner asymmetry than my current 16in 2.5 out (which is actually quite reasonable for ADSL2+ ;) )
>>>>
>>>>> I doubt I shall go that route. I have cable outside the front door already, which nobody uses, as they are still trying to recoup their infrastructure costs - approx 1.5 milliard euro. All the pit covers say 'NYNEX' on them.
>>>> 	Well, in germany cable download looks quite nice but the upload with 5M max (2-4 typical) is not quite as good as current VDSL offers (10up) and definitely way off the promised 40up; also a cable node in germany shares ~400MBit among its users while VDSL typical shares 1Gbit.
>>>>
>>>> best regards
>>>> 	Sebastian
>>>>
>>>>> To get back on-topic, I accept that it is unlikely that cero has affected the situation.
>>>>>
>>>>>
>>>>>
>>>>> On 20/02/14 14:38, Sebastian Moeller wrote:
>>>>>> Hi Fred,
>>>>>>
>>>>>> On Feb 20, 2014, at 14:57 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>
>>>>>>> On 20/02/14 13:56, Fred Stratton wrote:
>>>>>>>> The DSLAM at the exchange is an Infineon, Germany's finest.
>>>>>> 	The issue I mentioned did not happen at the DSLAM so sync was not affected, but at the PPPoE termination point, the BRAS, which accidentally throttles a number of users below their rated bandwidths, rather obscure and since restricted to ADSL1 hopefully a legacy issue that will go away at latest once all ADSL1 line cards are retired...
>>>>>>
>>>>>>>> I am using a 2Wire 2700 as the bridged connection device. The higher frequency bins, as graphed, as not optimally used. The device uses ADSL2+. The user cannot change this mode.
>>>>>>>>
>>>>>>>> The 2Wire is very effective at suppressing impulse noise.
>>>>>>>>
>>>>>>>> The line is uncapped, with unlimited downloads.
>>>>>> 	Just as I remembered, that means that syncing at good line moments just does not leave enough slack-bits for worse-case scenarios, hence your approach to increase the line tolerance by increasing SNRM to be better equipped for your sync to survive the interference episodes… It is a pity that one can not really request the modem to only sync at a specific bandwidth directly.
>>>>>>
>>>>>>>> The RF Interference source is unknown. Possible culprits are
>>>>>>>>
>>>>>>>> analogue to digital set top TV conversion boxes.
>>>>>>>> passing vehicles.
>>>>>>>> holes in the ionosphere.
>>>>>>>>
>>>>>>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html
>>>>>>>>
>>>>>>>> I can find no PPPoE errors.
>>>>>> 	Then I think that cerowrt should have no effect on the wan speed.
>>>>>>
>>>>>>>> The neighbours, based on their SSIDs, are always changing ISPs, and so are not a constant source of RF interference in that sense.
>>>>>> 	Well, evenif everybody uses BT's infrastructure there still can be some shared cable segments which can cause cross-talk. So even a local loop unbundled ISP that runs its own DSLAM-lincards at the central office will have some of its wire share a bundle with other ISP's wire along the lines to the Serving area interface, and that is sufficient for degradation of your line capacity. Only if your neighbors and you directly connect to two different outdoor slams/msans you would be not affected by their del usage. And if you suspect that they cause true RF interference, that can come easily in via the power lines… Since we humans have no good sense for electrical fields locating the source of RF interferes is a black art…
>>>>>>
>>>>>> Best Regards
>>>>>> 	Sebastian
>>>>>>
>>>>>>>> On 20/02/14 13:15, Sebastian Moeller wrote:
>>>>>>>>> Hi Fred,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>>>
>>>>>>>>>> On 20/02/14 11:35, Fred Stratton wrote:
>>>>>>>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz.
>>>>>>>>>>>
>>>>>>>>>>> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 connection monitoring.
>>>>>>>>>>>
>>>>>>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently available, with the password 'admin', a feature I do not like, even on a bridged device.
>>>>>>>>>    Ah, that sounds not very safe (would it hurt the manufacturers to switch to ssh on those devices and allow users to change the password, or better ship units with unique and secure passwords, especially irritating since many modems actually run linux inside...)
>>>>>>>>>
>>>>>>>>>>> Routerstats is not reliant on telnet.
>>>>>>>>>    Ah, I see it only extracts "Downstream Noise Margin and Connection Speed", I now see why you recommend the use of SNRM as proxy for line-quality ;)...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> I appreciate the analysis, which I am sure is correct.
>>>>>>>>>    I certainly hope it is, but while phrased as statements instead of questions, I might be completely out for lunch here; then gain I am always happy to learn from my mistakes...
>>>>>>>>>
>>>>>>>>>>> I am interested in external RF interference primarily. I have had two episodes of possible interference  recently, leading to transient disconnections.
>>>>>>>>>    Well, especially for RF interference a time resolved plot of CRCs, HECs, and even FECs (which should also increase massively around noise events) would be even better. Also some modems give ES (errored seconds) and SES (severely errored seconds) which are also good to plot along time.
>>>>>>>>>
>>>>>>>>>>> Continuously monitoring noise margin not only tells you when your neighbours get up, but also what is happening 40km above.
>>>>>>>>>>>
>>>>>>>>>>> The  thought was that it would be useful for others, to measure noise margin to track whether the phenomenon I am noticing when this one new build of ceroWRT was released - transient disconnection - is related to that build, or not. I am hoping for longer term benefits also.
>>>>>>>>>    Mmmh, if the modem concurrently looses sync than cerowrt should be innocent, if sync stays up and you have PPPoE errors (and run PPPoE from cerowrt) only with a certain cerowrt build you have a strong case for cero's involvement.
>>>>>>>>>
>>>>>>>>>>> When David P says his speed has increased, I listen. Here, I upgraded ceroWRT and had a transient rise in WAN sync speed almost immediately before the first connection loss.
>>>>>>>>>    You have an open profile (I mean you are limited by line physics and not throttled below that by your ISP), right? If all your neighbors switch of their modems and your intermittent RF noise source also sleeps, you will get a high sync value where all frequency bins are maximally used (so only little room for bitswitching). Now either cross-talk increases due to mode xDSL activity at your DSLAM or the RF noise comes back. Now your sync is exceeding the new line capacity caused by the changed line conditions and there goes your sync. Then on resync with the new conditions the system syncs at lower bandwidth to honor the specified SNRM under the new conditions, and you have again only a little leeway for bit switching, but yuo start at a level better matched to your average line condition, so this works better than basically the same amount of spare bits after a sync with perfect conditions.
>>>>>>>>>    Now this only applied if there was a resync of the modem after re-installation of cerowrt… If you did not re-sync (either you or the modem by its own) then it gets puzzling, as all cerowrt does, if I remember your setup correctly, is to do the PPPoE encapsulation, and that should not affect your speed one iota.
>>>>>>>>>    (That said, there seems to be a buggy BRAS version by cisco around, that in germany causes people on old ADSL DSLAMs that hook up to the ATM concentration net to get throttled by the BRAS by reducing the PPPoE en- and decapsulation speed. But that is so obscure that I do not think it affects you, heck it might be a pure duetsche telekom issue).
>>>>>>>>>
>>>>>>>>>>> Coincidence or not, the only way to know is by someone, somewhere, monitoring their connection.
>>>>>>>>>    I fully endorse that! Monitoring the DSL statistics is a good practice (I would love doing it again, but my current modem-router has no meaning flu way of doing that…)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>    Sebastian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> On 20/02/14 09:05, Sebastian Moeller wrote:
>>>>>>>>>>>> Hi Fred,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton@imap.cc> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite
>>>>>>>>>>>>>
>>>>>>>>>>>>> is software that is useful for monitoring an ADSL connection. When 'speed has increased' is mentioned, I wonder what has happened to the downstream noise margin.
>>>>>>>>>>>>    I think, DP reported speed increase of the wireless (swN0) to wired (se00) subnets on his home network, not necessarily increases in wan speed...
>>>>>>>>>>>>
>>>>>>>>>>>>    Interesting point though; I think with DSL there is a weak correlation between link stability/speed with noise margin. But other variables should have stronger correlation with useable bandwidth than noise margin.
>>>>>>>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is not in use, so generally speaking the sync speed of a typical DSL link will over time degrade (and not increase, ignoring G.inp). So once a DSL connection has "aged" down to stable conditions, noise margin what ever the numerical values are will not affect the speed. (Note typically the noise margin is something that is configured in the DSLAM/modem as minimums; each frequency bin is only maximally loaded with bits that this minimum signal to noise margin remains. If the link is throttled below full sync speeds, say by contract, e.g. having a 6M plan on a short line that would support 16M, then the noise margin will be large and the system has lots of freedom how many bits to load on each frequency bin. If the link is running at full sync, basically close to the physical limits of the link the noise margin will be close to the minimum values configured by the ISP. If the physical condition change, say more cross-talk noise due to more active DSL links in the DSLAM/trunk line the modem in the second situation will probably loose sync and resync at lower bandwidth but with noise margin still at the configured minimum. In other words in that situation noise margin will not correlate with link speed).
>>>>>>>>>>>>    However CRC and HEC error counts should correlate well with perceived speed changes, as both require packet retransmissions (visible to the ensures network stack, basically those packets are just dropped reducing good put, but at least the end nodes have a good understanding what is pushed over the DSL wires) degrading the good put of the link. Granted, with a low noise margin CRCs are more likely, but it is the errors and not the noise margin that actually affect the speed. (And lo and behold with some interference sources even very large noise margins do not prevent CRCs sufficiently).
>>>>>>>>>>>>    Note the number of FECs (forward error correction) is irrelevant to the speed, as the link carries the FEC information anyway, so no slowdown for FEC (well, actually with G.inp that changes a bit, as now the physical layer tries to retransmit packets/atm cells garbled beyond recognition by noise; effectively reducing the link throughput in an opaque way for the endnotes. Which will cause issues with using a shaper not intimately linked to the actual xDSL modem. But I have only glanced over https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items so I might be too pessimistic).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT.
>>>>>>>>>>>>    A great, just to complete the list for some broadcom models: http://www.s446074245.websitehome.co.uk under active development...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>    Sebastian
>>>>>>>>>>>>
>>>>>>>>>>>>> On 19/02/14 16:38, David Personette wrote:
>>>>>>>>>>>>>> I check for updates to certain projects each morning... I can quit anytime I want... =)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been fixed, I'll do so tonight. Thanks again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> David P.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson@gmail.com> wrote:
>>>>>>>>>>>>>>> I installed 3.10.28-12, and other than some missing packages (bash and curl
>>>>>>>>>>>>>> Heh. What do you guys do, have a cron job polling for changes to the build dir?
>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was going to sit on that and put out a more polished version sometime in
>>>>>>>>>>>>>> the next couple days.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> were what I noticed, and pulled from the previous version
>>>>>>>>>>>>>> I killed some big packages while trying to get a new build done faster.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll sort through the missing ones and add them back in. (I also just
>>>>>>>>>>>>>> added in squid, per request). Got a big build box donated to use
>>>>>>>>>>>>>> again, post disaster.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does anyone care about cups? (printing?) It was one of those things that
>>>>>>>>>>>>>> just barely works in the first place due to memory constraints and a PITA
>>>>>>>>>>>>>> and I haven't shipped it in a while. Most printers are network capable
>>>>>>>>>>>>>> these days, and what I tend to use the usb port for is odd devices
>>>>>>>>>>>>>> and gps and the like. I'd like to have support for a 3g modem or two...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Two concerns of mine are that I killed off udev, which used to manage
>>>>>>>>>>>>>> hotplugging. I'd like to know what, if anything, people are using the usb
>>>>>>>>>>>>>> for, so as to be able to make sure losing udev doesn't break that...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on WiFi from my
>>>>>>>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you.
>>>>>>>>>>>>>> I still think there is some tuning to be done on a rrul load, but we had
>>>>>>>>>>>>>> to get the last of the instruction traps out of the way first. As of
>>>>>>>>>>>>>> this morning
>>>>>>>>>>>>>> so far as I know, the "last" ones are gone, but I don't want to jinx it...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you try ipv6? Default routes are not quite working for me in
>>>>>>>>>>>>>> a couple scenarios.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> David P.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>>>>>>>>>>>> ok, so all the bits flying in loose formation have been rebased on top of
>>>>>>>>>>>>>>>> openwrt head, and I've submitted the last remaining differences (besides
>>>>>>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I also went poking through current 3.14rc kernels to find bugs fixed there
>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere in the flow
>>>>>>>>>>>>>>>> hash that I had
>>>>>>>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq and sch_hhf,
>>>>>>>>>>>>>>>> failed,
>>>>>>>>>>>>>>>> gave up on tracking pie further.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, tested the
>>>>>>>>>>>>>>>> components,
>>>>>>>>>>>>>>>> and was ready to release...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new build now...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and taking the rest of the day off.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Fixing bufferbloat with cerowrt:
>>>>>>>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Cerowrt-devel mailing list
>>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel