[Cerowrt-devel] cerowrt-3.10.44-6 released

[Cerowrt-devel] cerowrt-3.10.44-6 released

[Dave Taht]

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.44-6/

+ tested for all of 20 minutes - I intend to start a major test series overnight
and beat the c**p out of it and the other devices I'm working on. feel
free to wait to install.

+ fixed the basic problems with the -5 build
+ same update from openwrt head as in -5.

+ mdnsd nuked again (ultimately we're going to switch to it but not now)

   I had to completely strip mdnsd out of the build to make it go away
(./scripts/feeds uninstall mdnsd)

+ natpmp was conflicting with the same (new unified) functionality in
miniupnpd, si I nuked natpmp.
   not clear if better firewall rules are needed yet, the ipv6
functionality scares me.

- see some errors like:

Wed Jun 25 03:29:13 2014 daemon.warn miniupnpd[4119]: SSDP packet
sender 172.21.2.5:34062 not from a LAN, ignoring

+ netserver started again from xinetd

- it looks like the ntp monitoring thing toke did is not working
and/or we're running the wrong ntp now
    but dnsmasq does not run with timechecks enabled by default, so we do
dnssec correctly with invalid time until something sends a sighup

...

I'm really looking forward to the barrier breaker freeze.

I am doing no more builds until I replicate bug 442.


-- 
Dave Täht

Re: [Cerowrt-devel] cerowrt-3.10.44-6 released

[Jim Reisert AD1C]

Been running since Wednesday evening, no issues so far.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

Re: [Cerowrt-devel] cerowrt-3.10.44-6 released

[Dave Taht]

I have been blowing it up with continuous traffic, saturating the cpu,
talking to multiple devices, using crypto and ethernet, now for
several days.

I am using sfq on the wifi, rather than fq_codel, at least temporarily.

Occasionally, using the rrul test, I can get it to temporarily either
lose a route or  deassociate from wifi, or something else like netperf
itself blowing up, but it always comes back within a few seconds. So
far, using the rrul_be test I haven't seen that happen. I do see cpu
absolutely maxed at present with rrul and not rrul_be.

I have given up on tuning the wifi aggregate queue length (formerly
12, now 48) as much as I had before - as the previous setting had
adverse effects on download throughput, so I'll put that fix in the
next release and live with the added latency until we can pull
together the make-wifi-fast project.

I see an improvement on the simultaneous upload/download test from
10mbit up/.2 down to 6up,3down, latency (as measured on the main
client) of about 80ms (which still sucks about 10x worse than what
seems possible)

I ran out of space on my packet captures...

I am going to be adding more clients, switching back to fq_codel, and
adding in ipv6 if this continues to take the load I am throwing at it.
Then adding impairments to degrade the wifi to more marginal levels.

Interestingly I have not got any instruction traps, nor the famed dma
overrun bug/recovery in this release so far... I am encouraged, but
until I setup a mac  with bad connectivity and have things run for
days and days I won't sleep well.

And I had done a build from this codebase for the picostation and am
watching that crash under normal load regularly. That box only has
32MB of memory, where the cerowrt box has 128MB memory.


On Thu, Jun 26, 2014 at 12:28 PM, Jim Reisert AD1C
<jjreisert@alum.mit.edu> wrote:
> Been running since Wednesday evening, no issues so far.
>
> --
> Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.44-6 released

[R.]

All of my devices are connected on the 2.4 Ghz AP of a WNDR3800
running 3.10.44-6.

Here's my feedback:

+ WiFi stability has improved in the sense that the AP no longer disappears.

- Latency spikes still exist. Huge latency lag comes in for up to a
minute (can be seen in ping stats). It usually fixes itself within the
minute.
- Net connectivity can go out for up to a minute on all devices. It
usually fixes itself within the minute.
- "Failed to stop TX DMA, queues=0x004!" still occuring. Had 23
instances in the last 9 hours.
- New warning appears multiple time in logs: "daemon.warn
avahi-daemon[2154]: server.c: Packet too short or invalid while
reading known answer record. (Maybe a UTF-8 problem?)"

Overall, fairly satisfied.

On Thu, Jun 26, 2014 at 3:53 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I have been blowing it up with continuous traffic, saturating the cpu,
> talking to multiple devices, using crypto and ethernet, now for
> several days.
>
> I am using sfq on the wifi, rather than fq_codel, at least temporarily.
>
> Occasionally, using the rrul test, I can get it to temporarily either
> lose a route or  deassociate from wifi, or something else like netperf
> itself blowing up, but it always comes back within a few seconds. So
> far, using the rrul_be test I haven't seen that happen. I do see cpu
> absolutely maxed at present with rrul and not rrul_be.
>
> I have given up on tuning the wifi aggregate queue length (formerly
> 12, now 48) as much as I had before - as the previous setting had
> adverse effects on download throughput, so I'll put that fix in the
> next release and live with the added latency until we can pull
> together the make-wifi-fast project.
>
> I see an improvement on the simultaneous upload/download test from
> 10mbit up/.2 down to 6up,3down, latency (as measured on the main
> client) of about 80ms (which still sucks about 10x worse than what
> seems possible)
>
> I ran out of space on my packet captures...
>
> I am going to be adding more clients, switching back to fq_codel, and
> adding in ipv6 if this continues to take the load I am throwing at it.
> Then adding impairments to degrade the wifi to more marginal levels.
>
> Interestingly I have not got any instruction traps, nor the famed dma
> overrun bug/recovery in this release so far... I am encouraged, but
> until I setup a mac  with bad connectivity and have things run for
> days and days I won't sleep well.
>
> And I had done a build from this codebase for the picostation and am
> watching that crash under normal load regularly. That box only has
> 32MB of memory, where the cerowrt box has 128MB memory.
>
>
> On Thu, Jun 26, 2014 at 12:28 PM, Jim Reisert AD1C
> <jjreisert@alum.mit.edu> wrote:
>> Been running since Wednesday evening, no issues so far.
>>
>> --
>> Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us
>
>
>
> --
> Dave Täht
>
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel