From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3B0322005CC for ; Fri, 25 May 2012 15:38:50 -0700 (PDT) Received: by wgbfa7 with SMTP id fa7so1092800wgb.28 for ; Fri, 25 May 2012 15:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lIrQoSPwfjg7xypzoRWdp6EbOvSME58kmuCxU8bzd5Y=; b=ZUNRQc9h8zRtfhu2nm/wqxBE7fr9hpuHXCCiqc4pcA6q1sNBzq9uMwqrdV3rYqs6GK SHzh15do13h5dbKJkeT027JpL87nCWxDvCPz1BIbw2uNVLJiiHvL/B+W+hNSWhjbiPsu UcyAxo1cwr25UxUJnNPM0Wujk7/3pMjKamAEE6V/WQHrK8u83rCmbtNiagIMCo65X+++ 9O/poEUDyGzGUYnSk/ybriRDy5CGijRPaQCE4SB6tI+tQ+jvwLlbBbvkRC0ZU0K+ufc3 VI5T4nEekWixF4sK6ag1vSYCiUd3QTUyLb4QWYyj0bJyuD76RZmblGrW7UuG1cIzT9fY hSEg== Received: by 10.216.228.88 with SMTP id e66mr216418weq.208.1337985528410; Fri, 25 May 2012 15:38:48 -0700 (PDT) Received: from [192.168.1.5] (cpc3-seac6-0-0-cust991.7-2.cable.virginmedia.com. [81.105.255.224]) by mx.google.com with ESMTPS id n11sm25145216wiv.9.2012.05.25.15.38.47 (version=SSLv3 cipher=OTHER); Fri, 25 May 2012 15:38:47 -0700 (PDT) Message-ID: <4FC009F6.7070707@gmail.com> Date: Fri, 25 May 2012 23:38:46 +0100 From: Robert Bradley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sebastian Moeller References: <00404BC8-3761-409D-A1C8-9213D7D9A3DF@gmx.de> <1E435715-5C95-49AF-99D0-E8AD6EAD5B44@gmx.de> <4FBE5767.6080704@gmail.com> <4D0F5C65-2401-470F-A6D8-BE18E8BA25C7@gmx.de> <4FBE6290.9000701@freedesktop.org> <0E4C11DB-2B8A-411B-A61F-34B2A6BF57B9@gmx.de> <4FBE7AAB.5080307@freedesktop.org> <4FBE84C4.80607@gmail.com> <61BEA217-79A6-47C8-888D-101BC0EAFB45@gmx.de> <844EF766-4E37-4B31-AA5D-B51FB22A05A8@gmx.de> In-Reply-To: <844EF766-4E37-4B31-AA5D-B51FB22A05A8@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] 3.3.6-2 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 22:38:52 -0000 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.)