Re: Loading time of scotty

Juergen Schoenwaelder (schoenw@cs.utwente.nl)
Wed, 19 Mar 1997 18:15:48 +0100

clau@plaintree.com said:

clau> Right now when you launch a scotty or tkined process,
clau> another instance of the Tnm dynamic library is loaded
clau> with all the functionalities and all the MIBs (at least
clau> the core ones if you're using "mib load" to control the
clau> loading) is loaded too. This makes the startup time
clau> rather slow. I think this is apparent in the "Tools" in
clau> tkined. It can take quite a few seconds to load a tool
clau> depending on what type of machine you have. I wonder if
clau> we have any alternatives.

clau> In a scotty script we may only need a few functions in
clau> Tnm at a time. It would be nice if we can specify which
clau> functionalities in Tnm that we need, e.g.
clau>
clau> package require Tnm_snmp
clau> package require Tnm_udp
clau> package require Tnm_rpc

Loading the complete Tnm package is usually not a big deal. The size
of the dynamic loadable library is between 200 and 400 KB (it depends
on the target system) and operating systems usually memory map them
into the address space, which is quite efficient. I think it is not
worth the effort to split the Tnm extension into smaller pieces.

clau> As for the loading of MIBs, why waste memory and startup
clau> time by reloading MIBs for each process. We can do
clau> things like the following:
clau>
clau> - struture the MIB in database files and do lookup in files
clau> instead of memory.
clau> - load one slave process that will answer queries for all
clau> other processes.

Both solution do not convince me. The SNMP code does MIB lookups quite
frequently and it will cost a lot of overhead if you have to go to a
file in order to get e.g. the display hints for the varbinds contained
in a SNMP response. Even hashed files (e.g. dbm) are much more
expensive than the current in memory implementation. (The tcl_nm
package written several years ago used dbm files and I really disliked
the overhead - and it did not deal with things like textual
conventions at that time.)

Using a server to resolve things might be fast enough if the IPC
interactions between the server and the Tnm processes are fast
enough. The only IPC mechanism which I would consider fast enough is
actually shared memory. I never thought about using shared memory
before and how difficult it will be to put the internal MIB tree into
a shared memory segment. Before spending time on it: Does anyone out
there know how portable shared memory is across UNIX systems? And what
about Windows? Has Windows something comparable to shared memory?

Juergen

-- 
Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw
Computer Science Department, University of Twente,   (Fax: +31-53-489-3247)
P.O. Box 217, NL-7500 AE Enschede, The Netherlands.  (Tel. +31-53-489-3678)
--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.