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.)
next prev parent 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