<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Michael, Maiko and all,<br>
<br>
I'm always challenging packet radio and ham digital programs<br>
by using low or very low RAM linux systems so, as for my<br>
experience I can confirm that jnos2, linfbb, obcm, etc<br>
are consuming an average memory around the 5-6 Megabytes.<br>
<br>
The actual jnos2k is running together with other programs<br>
on a 760 Megabytes of RAM machine and is consuming just <br>
over five MB; ... and, before the libcrypt library compile the<br>
consumed memory were under the four MB (3.8 MB circa):<br>
<br>
<br>
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND <br>
<br>
3051 root 20 0 5252 3140 1600 S 0.3 0.4 2:41.41 jnos<br>
<br>
So, something may be leaky on your system... but surely not<br>
depending upon the jnos2k program.<br>
<br>
About the forwarding I'm using in all cases, when and where the<br>
partner systems support it, the standard B1F compression and<br>
the B2F with the CMS obviously... without any problems :)<br>
<br>
In *my* situation ONLY active B1F forward calls from jnos2 to<br>
linbpq will cause the jnos2 crash so, the cure is to disable the<br>
calls and using only the reverse forwarding from linbpq, with<br>
their B and B1 flags unchecked, to jnos2.<br>
<br>
Tests from here are concluded and so hope to test some new<br>
features on the coming jnos2 releases :)<br>
<br>
73, gus<br>
<br>
On 08/13/2016 06:38 AM, Michael Fox - N6MEF wrote:<br>
</div>
<blockquote cite="mid:010501d1f51c$8c79b190$a56d14b0$@mefox.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1498695286;
mso-list-type:hybrid;
mso-list-template-ids:1723252894 -1415538370 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F06E;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Corrected.
100M instead of 100K.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in
0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Michael Fox - N6MEF
[<a class="moz-txt-link-freetext" href="mailto:n6mef@mefox.org">mailto:n6mef@mefox.org</a>] <br>
<b>Sent:</b> Friday, August 12, 2016 9:36 PM<br>
<b>To:</b> TAPR xNOS Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:nos-bbs@tapr.org">nos-bbs@tapr.org</a>)
<a class="moz-txt-link-rfc2396E" href="mailto:nos-bbs@tapr.org"><nos-bbs@tapr.org></a><br>
<b>Subject:</b> JNOS 2.0k memory issue?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ve been trying to nail down what
condition might be causing the hangs with 2.0k. I
discovered what may be a memory problem with JNOS. This may
be why I haven’t noticed the problem on my test machine
(12GB) but I did notice on my production machine (4GB).
Here’s what I found:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I have a machine with 4GB of RAM. I boot
it up (without starting JNOS), and free memory (reported by
“free”) will stay at about 2.3G for as long as you want to
watch it. I used “watch free” with the default 2 second
refresh rate.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I start up JNOS and free memory drops to
about 1.8G or lower.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As forwarding starts to occur, the amount
of free memory drops lower and lower, and will bottom out at
about 100<span style="color:#1F497D">M</span> bytes. So
JNOS is taking about 2.2G of RAM at that point (2.3G – 100<span
style="color:#1F497D">M</span>).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When memory goes this low, the JNOS
console window becomes unresponsive. And the status line
isn’t updated. For example, as I watch “tail -f nos.log”, I
can see new forwarding connections happen, but the BBS call
signs don’t appear on the status display.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">About the time that certain events happen
in nos.log, such as “reintegrating data [F] from eol issue”,
free memory will jump back up – not as high as before, but
up to about 1.4G. This goes on in cycles of lower and
higher memory utilization as different forwarding sessions
happen.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If I wait until all forwarding sessions
have finished and JNOS is quiescent, and then use exit 0, my
linux free memory is at 1.4G and it will stay there for as
long as you watch it. (Remember, it was at 2.3G before
starting JNOS!)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If I start up JNOS again, free memory
will drop to about 1.0G after JNOS completes its startup.
If I exit 0, free memory stays at 1.0G for as long as you
want to watch it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">After reboot, free memory is back to 2.3G
and will stay there (as long as JNOS is not started!). This
cycle is repeatable.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This seems to suggest that:<o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Wingdings"><span
style="mso-list:Ignore">n<span style="font:7.0pt
"Times New Roman""> </span></span></span><!--[endif]-->JNOS
is not returning all memory to the OS. Each invocation of
JNOS leaves less free memory in the system. <o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:Wingdings"><span
style="mso-list:Ignore">n<span style="font:7.0pt
"Times New Roman""> </span></span></span><!--[endif]-->While
JNOS is running, certain conditions during forwarding cause
JNOS to consume a large amount of memory and hold it for an
extended period until some other condition happens. Even
then, not all is returned.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Maiko:<o:p></o:p></p>
<p class="MsoNormal">To help with troubleshooting, I prepare a
little script that will log the output from “free” to a file
with timestamps, so it can be compared alongside the
nos.log. I captured the two scenarios above -- initial run
(ending with 1.4G free) and a second run (ending on 1.0G
Free) – using 2 second time intervals in the free memory
log. Maybe you have development tools that provide better
info. But if you’d like the data, let me know.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Also, this may not be limited to 2.0k. I
found similar behavior in 2.0j. However, the condition
seems to be exacerbated by compression. And because of some
of the B2F forwarding errors that were fixed in 2.0k, I was
not using compression in the 4G machines. Therefore,
perhaps the exact same conditions aren’t present in 2.0j.
So maybe that’s why 2.0j hasn’t completely hung in the
lower-memory units like 2.0k did. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Michael<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
<br>
</body>
</html>