Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Robert Bradley <robert.bradley1@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] 3.3.6-2
Date: Fri, 25 May 2012 23:38:46 +0100	[thread overview]
Message-ID: <4FC009F6.7070707@gmail.com> (raw)
In-Reply-To: <844EF766-4E37-4B31-AA5D-B51FB22A05A8@gmx.de>

On 25/05/12 19:25, Sebastian Moeller wrote:
> Hi Robert,
>
>
> On May 25, 2012, at 4:11 AM, Robert Bradley wrote:
>
>> That said, unless we can
>> find an obvious reason for /tmp overfilling, I'm not sure we should do
>> that, since it will cause problems upgrading.
> 	But if I create a file of 30000 1KB blocks in /tmp (so that around 400 KB stay available), the router goes into OOM, so I do not think that upgrading would work well if it really needs so much memory? I have a hunch that the openwork base under cerowrt does not assume something as big and demanding as the 11MB bind9 named process running :)
The flash memory size is about 16MB for the WNDR3700, so it's probably 
ok for normal use.  It's less certain with BIND and everything else 
running, although it'd be possible to restart the router, stop BIND and 
then update.

> 	Oh I agree the /tmp issue is a tangent, but it does not seem healthy that the router spirals into reboot once /tmp fills up (BTW if I remove my 30000KB file from /tmp while the first OOM is in process the router recovers) My hunch is that the falmost fully instantiated tmpfs takes to o much memory from the system for it to handle its usual business.
> 	On top of that are the wireless issues, say what about a kernel memory leak caused by ath wireless that grows and grows until the problematic /tmp size is in the single digit MBs that starts the spiral to reboot?

No, definitely not healthy!  I'm thinking that maybe setting tmpfs to 
20MB would be a good compromise, at least until the presumed memory leak 
can be tracked down.

>> I'm thinking that maybe flooding wireless->wired with UDP traffic for
>> 5-10 minutes is the right approach, and then vice-versa (restarting
>> the router inbetween?).  If there are problems like infinite retries
>> or packet memory leaks, that might show them up quickly.
> 	That sounds like the right way to process, except I am no expert at setting netsurf up so that might take a while until I get around to actually test that hypothesis. (Do you by any chance know a publicly available net server process running in the internets to which I could point a local netperf, and do you have any recommendations how to create the UDP flood with netperf ?)
>
>

I don't know of any myself.  There's a possible tutorial on setting it 
up at http://www.tonymacx86.com/viewtopic.php?t=5700, but assuming you 
have it installed on two computers already, it should just be a case of 
running:

user@computer1$ netperf -t UDP_STREAM -H computer2

and possibly running "netserver -p 12865" on computer2 if necessary.  
(It should in theory be started via inetd.)

  reply	other threads:[~2012-05-25 22:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <00404BC8-3761-409D-A1C8-9213D7D9A3DF@gmx.de>
2012-05-24  3:48 ` [Cerowrt-devel] Fwd: 3.3.6-2 Sebastian Moeller
2012-05-24 15:44   ` Robert Bradley
2012-05-24 16:18     ` Sebastian Moeller
2012-05-24 16:32       ` Jim Gettys
2012-05-24 18:12         ` Sebastian Moeller
2012-05-24 18:15           ` Jim Gettys
2012-05-24 18:58             ` Robert Bradley
2012-05-25  6:41               ` [Cerowrt-devel] 3.3.6-2 Sebastian Moeller
2012-05-25  7:02                 ` Dave Taht
2012-05-25 11:11                 ` Robert Bradley
2012-05-25 18:25                   ` Sebastian Moeller
2012-05-25 22:38                     ` Robert Bradley [this message]
2012-06-02  7:03                       ` Sebastian Moeller
2012-06-03 22:24                         ` Robert Bradley
2012-06-06 23:03                           ` Sebastian Moeller
2012-05-25  0:04             ` [Cerowrt-devel] Fwd: 3.3.6-2 Sebastian Moeller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FC009F6.7070707@gmail.com \
    --to=robert.bradley1@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox