NI/NX Memory, explain it please
vining
Posts: 4,368
Ok, I've finally run into memory issues thanks to a new memory sucking module I wrote and I've realized I really don't know how to interpret what "show mem" is showing me or how memory is allocated on the processors.
The client's code works fine on my office processor but when I deployed this new module with 3 instances it killed my clients processor, a bubble LED NI-3100, probably 64M RAM.
My processor:
1, Volatile max physical means I have a 256M RAM
2, NV is a separate chip and has nothing to do with anything else.
3, Disk Free is the SD card.
4, Duet Memory is stolen from Volatile?
Compiled code:
I assume the system compiled memory usage doesn't include any compiled modules, just the main and includes w/o the TKO's they may pull in?
Now I tried to run just the memory sucking module on an NI-700, 1-3 instances and it would not work at all, even after I change the FW to a non duet FW and if my assumptions are correct it had a 32M RAM.
And finally why are these processors so stupid that if you overload them they're not smart enough to keep core functions operable like coms, telnet, etc. Normally when it locks up I can remotely power cycle and as soon as it come online,before the program starts loading I can send it a blank program and them load the system program with my offending module/code commented out but this last time because I had all 3 instances included I'm F'd and now have to drive 4 hours round trip to flip a freakin' PRD switch cuz these things are too stupid to maintain critical functions.
The client's code works fine on my office processor but when I deployed this new module with 3 instances it killed my clients processor, a bubble LED NI-3100, probably 64M RAM.
My processor:
Volatile Free :126045280/268435456 (largest free block in bytes/max physical) NonVolatile Free: 609782/1047536 (bytes free/max physical) Disk Free :100311040/128299008 (bytes of free space/max physical) Duet Memory Free :29051220/37748736 (bytes free/max physical)What I'm assuming is:
1, Volatile max physical means I have a 256M RAM
2, NV is a separate chip and has nothing to do with anything else.
3, Disk Free is the SD card.
4, Duet Memory is stolen from Volatile?
Compiled code:
Module: Compiled Code takes 4947173 bytes of memory -- Token and Variable Count is 38207 (Maximum is 200000) System: (including the 3 instances of the memory sucking module) Compiled Code takes 3152670 bytes of memory -- Token and Variable Count is 30667 (Maximum is 200000)
I assume the system compiled memory usage doesn't include any compiled modules, just the main and includes w/o the TKO's they may pull in?
Now I tried to run just the memory sucking module on an NI-700, 1-3 instances and it would not work at all, even after I change the FW to a non duet FW and if my assumptions are correct it had a 32M RAM.
And finally why are these processors so stupid that if you overload them they're not smart enough to keep core functions operable like coms, telnet, etc. Normally when it locks up I can remotely power cycle and as soon as it come online,before the program starts loading I can send it a blank program and them load the system program with my offending module/code commented out but this last time because I had all 3 instances included I'm F'd and now have to drive 4 hours round trip to flip a freakin' PRD switch cuz these things are too stupid to maintain critical functions.
0
Comments
Re: Ram on 700:
Serials starting 210503 are the old units... 32 meg and frequently too small for projects. Nearly no room at all if you use DUET firmware.
Serials starting 210570 are the 64 meg units and should be completely compatible with any code you make for standard x100 series. Except if you think you are working in 256meg!
Yes, DUET comes from Volatile, and the DUET allocation reduces the FREE reported memory.
Also the 700 and 900 use a different memory allocation method that makes they unable to load a new large code TKN if there is already a large TKN running. You can either load twice (the first will fail and if you can get the second one going fast enough, it will load, or use the PRD switch to prevent the existing program from running, or you can load a tiny TKN, reboot, and load the new large one.
In your 256 box where it does run,
You are using over half the 256meg available (including 36 meg dedicated to and largely unused by DUET).
This program most certainly will not run in a 64 meg unit.
Volatile Free :126045280/268435456 (largest free block in bytes/max physical)
Now how do I determine pre-load what my memory usage will be? According to the compiled memory line the module uses 4.9M of memory so in theory 3 instances with no other code except that for defines should have run on a 32M 700 running a non duet FW, at least that's what I expected and when NV was tweaked to use more NV and less V (I don't normally use NV) my volatile number showed I still had just under 1M left. At one point I did exceed my NV allocation by a large amount.
With 3 instances of the memory sucking module:
w/o So with the modules I'm using 67M more memory but when compiling the module the compiler tells me it will use 4.9M for each instance so If I base my assumptions on what the compiler tells me I can end up with an unresponsive master like I have now.
Blank system file with 1 NV var declared: Based on this the 4..1.404 FW on my 256M unit uses about 58M of volatile with a blank file, empty source so should I assume that 64M 3100 running 3.60.453 use almost as much which means the net space available is likely 1/3rd the RAM size and on a 32M 700 running duet I'd likely have 10M (1/3rd) available and maybe 20M if running a not duet. It would be nice to actually know this stuff with out guessing.
Edit, forgot to account for the 36M assigned for duet so that means about 22M used by the system w/o running code.
The compile-time usage report numbers are basically guesses, from what we've seen.. Just like the HOW MUCH LONGER reading of a process in Windows, or how much disk space a backup will need.
If you want to know more about how much you really have, hit that PRD and start the unit without code, and see what it reports.
Then load your app and compare the compile notice with reality. If you see what I do, it varies. Just like the variable count - it is clearly related to actual variables, but not in any one-to-one manner you can predict. AMX has been unable to tell us how variables are counted, and it was a real problem for us until they raised the compiler limits to 200,000 in NLS4x. We know we aren't declaring anything near 100,000 variables by anything we understand... but somehow we end up with over 150,000.
A 32 meg 700 is just about enough space to run HELLO WORLD. Even with 2x firmware (no Duet at all)...