May 22, 2019

Grinder - shared memory

The oven software is set up so that only user "pilot" or "pilot2" can create the necessary shared memory. If anyone else tries, they get the infamous "hoven 30" message. And even if pilot tries to do things without having created the shared memory, they will get the "hoven 30" message. I have a whole page devoted to figuring out this message.

So, to create the shared memory segment, do this: 

(as user pilot)
oven readonly=no
Once you do this, the shm segment will stay around forever as near as I can tell. It certainly stays around when I completely logout. Rebooting gets rid of it. The only other way to get rid of it is to explicitly delete it using the ipcrm command (see below).

Command line tools for shm segments

The "ipcs" command now shows a whole bunch of shared memory segments, but the one we want is owned by pilot and has a non-zero key. Also note its size (263748 bytes). 
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 360448     tom        600        524288     2          dest
0x00000000 4587531    tom        600        49152      2          dest
0x00000100 13664268   pilot      644        263748     1
0x00000000 2949133    tom        600        16777216   2          dest
If you want to get rid of this for some reason, use: 
ipcrm shm 13664268

Note that on Solaris, the "ipcs" command is less informative. The following is from our system with the oven software active: 

Sun Microsystems Inc.   SunOS 5.8       Generic Patch   October 2001
Sun Microsystems Inc.   SunOS 5.8       Generic Patch   October 2001
You have new mail.
crater$ ipcs
IPC status from  as of Thu May 23 10:28:45 MST 2019
Shared Memory:
T         ID      KEY        MODE        OWNER    GROUP
m          0   0x500006d9 --rw-r--r--     root     root
m        101   0x100      --rw-r--r--    pilot    other
m        102   0x101      --rw-r--r--    pilot    other
m        103   0x102      --rw-r--r--    pilot    other
The Solaris version of "ipcs" does not display the size of the segment, which is too bad.

Those database files

On the sun, we find a bunch of binary "database" files of size 133548 bytes. This is much less than the size of the entire "database" (as we call it) in memory. What is going on?

I wrote a little program that I can run on my linux system, and by including oven.h and letting the compiler show me the "sizeof" various things, I get the following. 

B database:       172 bytes
P database:    133376 bytes
I database:     50628 bytes
D database:     34952 bytes
E database:     44620 bytes
total database:    263748 bytes
The 263748 number is what we like to see, and it turns out that the sizes of B+P added together give us 133548 -- just the size of the binary database files. So it turns out that only the B and P portions are worth writing to disk. The D and E values come from the V computers as needed or wanted.

As near as I can tell, the I values never escape from the V computers at all. It does no harm to allocate space for them (and it is convenient to just allocate the "database" structure verbatim as per oven.h). So we really only have 4 things to concern ourselves with in the control room software.

The reader may find several other things heartening. If he adds up the individual sizes above, they total to 263748 bytes. This means the compiler is not doing any monkey business padding structures. Also the sum of the B plus P sizes on x86 linux totals to 133548 bytes, which matches the sizes of the database files on the sparc system.

Have any comments? Questions? Drop me a line!

Tom's home page / tom@mmto.org