Post by Christer JacobssonPost by WD LoughmanPost by John Small2010 16:17:05 -0800
Post by WD LoughmanAlso, please what are the currently "good" versions of BOINC(5), SETI,
rexxrpc, and JBSWUmonitor *known* to work well together?
'Scuse me for jumping in here, but can somebody explain what the
directives below means/entails?
----------------------------------------------------------------------------
=ON (default) or OFF
New setting in Warp Server for e-business
The dllbasing parameter prevents fragmentation of the shared
environment, allowing more efficient use of virtual memory. The
dllbasing parameter may be set to ON or to OFF. If dllbasing is set to
ON, then the system will attempt to honor the base addresses (preferred
load addresses) for DLLs. Honoring base addresses for DLLs is preferred
because it improves system performance for loading DLLs. However,
sometimes there is an interaction between the DLL basing and an
application's memory usage which will cause the system to run out of
private memory. In this case, you should set dllbasing to OFF so that
the system will ignore base addresses for DLLs. The system performance
for loading DLLs may degread marginally, but there will be more free
private memory.
<<=TIP=>> By Istvan Kovacs: ON: better general performance; OFF: more
private memory (just in case an app needs it)
----------------------------------------------------------------------------
----------------------------------------------------------------------------
=TRUE
Setting used with kernel 14.062e or higher
will allow device drivers, etc.,
access to the memory above 16mb early in boot. Previously, this was only
available after DD and IFS init was completed. This has various
implications when enabled:
a) large VDISKs are possible. I tried DEVICE=\os2\vdisk.sys 16000
b) AHA154X.ADD may do bad things to your system. Don't even ask.
c) There may be some settings of HPFS386 cache that are incompatible.
<<=NOTE=>> This feature is experimental and may not work with later kernels
----------------------------------------------------------------------------
Post by Christer JacobssonWhat does this do? Pros and cons for using/not using this statement?
----------------------------------------------------------------------------
WDL sez:
I have this in my config.sys because eCS2.0 GA has a "kernel optimize"
function, with several modes. "PROCESSES" is one of the modes.
However, as I've noted before, in this case the optimizer has a Big
Bug and provides a number which the boot process resolutely rejects.
The number I use is selected on two criteria:
1. Searching the 'net provided a few clues, and
2. Trial/error gave me a number that lets me run huge programs:
Open Office, eg.
3. It seems to help.
----------------------------------------------------------------------------
Post by Christer JacobssonDoes it work under WSeB w/kernel 14.104 UNI? And how can I get a count
of how many processes the system runs?
Post by WD LoughmanSWAPPATH=Q:\SWAPPER 2048 102400
----------------------------------------------------------------------------
=drive,path,mmm(in kb),nnn (in kb)
OS/2 can allocate more memory than it actually has available. It does
this by swapping memory to a hard disk file called SWAPPER.DAT.
Parameter:
mmm is a number from 512 to 32767 which specifies how large the
SWAPPER.DAT file can grow before it stops consuming hard disk space. The
size is stated in the negative. In other words, if you have the mmm set
to 512, then the SWAPPER.DAT file can grow until there is only 512k left
on your hard disk.
nnn is the starting size of the SWAPPER.DAT file.
<<=TIP=>> When your swap file grows beyond the initial size you have
specified, OS/2 starts to manage the swap file. This increased overhead
can negatively impact your systems performance. Therefore, if your swap
file always exceeds its initial size, consider increasing the files
initial size. For example, if your swap file usually grows to 8MB, set
the initial size of 8MB.
<<=TIP=>> As time progresses, OS/2 will gradually swap dormant code from
real RAM to the swap file. So if you tend to use a few programs for a
long period of time you will notice a gradual performance improvement.
Try and avoid application hopping
<<=TIP=>> Normal operation of OS/2 can involves considerable disk
activity as operating system functions are loaded and pages are moved in
and out of the swap file. Here are a couple of tips to improve
performance. (1) Consider dedicating a separate partition for the swap
file. This helps avoid fragmentation of the swap file, because other
files will not be added or deleted from the dedicated partition. (2) If
you have both FAT and HPFS partitions, put the swap file on the HPFS
partition to take advantage of the better performance of HPFS. (3) If
you have a system with two hard disk controllers, put the swap file on a
disk managed by the least used controller. (4) Keep your swap file on
the MOST used partition of the LEAST used hard drive.
<<=WARNING=>> Never put your swap file on a networked drive.
<<=NOTE=>> Your swap file will grow (in 1MB increments), but it also
shrinks when two conditions are met. One, when the amount of free space
in the swap file is greater than 1.5MB, the swap file will be compressed
during system idle time. (It will not shrink if there is a constant
"hit" on the drive by a program such as a swap file monitor.) Two,
during the compression, free space is moved to the end of the swap file.
When this free space at the end of the swap file exceeds 1MB, the swap
file will be shrunk.
<<=NOTE=>> See the discussion of the COMMIT parameter for the MEMMAN
config.sys line including the <<=TIP=>>.
<<=WARP NOTE=>> Your swap file in Warp will be larger than in earlier
versions of OS/2. This is normal. The most significant change that has
been made is how system DLL's get loaded and what is now valid data for
swapping. System DLL's include: DISPLAY, SOM, PMMERGE, PMWP, DOSCALL1,
PMATM, PMMLE, IBMDEV32, PMCTLS, PMSPL, IBMVGA32, PMGPI, and PMVIOP.
In the previous versions of OS/2, DLL code was never copied to the
swapper file. In WARP, code for system DLL's can be written to the
swapper file and, in addition, during boot, PMMERGE, DOSCALL1, PMGPI,
PMWP and PMVIOP will be swapped out. This means that there will be an
overall increase in swapper size. This was done to increase overall
system performance.
To control the size of the swap file use e.g. the FREE SmartBar by
Alessandro Rossi available at
http://www.os2world.com/os2place/smartbar/indexe.html
----------------------------------------------------------------------------
Post by Christer Jacobsson******
I have mine set at 524288 as I *know* I'm needing a big swap file
[ snip ]
----------------------------------------------------------------------------
=n (in numbers)
OS/2 programs can have several different processes running at the same
time. These are called threads. This command sets the maximum number of
threads (from 32 to 4095 in OS/2 2.x and from 64 to 4095 in Warp 3) that
OS/2 can run at the same time. If this command is not included in your
config.sys file, OS/2 will default to 64. Jim Gilliland commented on
what happens if OS/2 runs out of Threads: "If an application tries to
start a new thread, and OS/2 has all of its threads already in use, then
OS/2 will generate an error. It may result in a popup, or it may return
the error information to the application."
<<=TIP=>> If you have more than 8MB of RAM and run lots of OS/2 specific
programs, you may be able to improve system responsiveness by increasing
the number of threads. Why? Because well written OS/2 programs will use
threads to improve program performance. Therefore, the more well written
OS/2 programs in use, the more threads that could be needed. But still
keep in mind that this only holds true only when you are using a fair
number of OS/2 specific programs at the same time.
<<=SERVER NOTE=>> On a server it is generally considered better to have
512 threads.
----------------------------------------------------------------------------
Post by Christer JacobssonHow can I determine the number of threads the system is running?
There are kinds of utilities "out there". "TOP" is one, and provides a
process killer as well.
----------------------------------------------------------------------------
=n (in kb)
The default value for VIRTUALADDRESSLIMIT in OS/2 Warp Server for
e-business is 1 GB (=1024). The VIRTUALADDRESSLIMIT parameter is also
available for OS/2 Warp Server SMP Feature and Warp 4.0 Fixpak 13. Areas
of memory below 512 MB have been remapped for higher availability in
that region.
2048 allows max. memory allocated 2 Gigs of shared RAM. Only useful for
developers.
You must have a hard disk that can accommodate the swap file. UW2SCSIs
are recommended for the swap disk unless you wish to see your computer
behave like a washing machine in spin dry mode.
<<=NOTE=>> The OS/2 Warp Server Advanced SMP addendum states that this
number can go to 3 Gigs. Memory support has also been enhanced since now
an application can access a virtual memory address space of up to 3 GB
by use of the VIRTUALADDRESSLIMIT = 3072 parameter in CONFIG.SYS. Areas
of memory below 512 MB have been remapped for higher availability in
that region.
----------------------------------------------------------------------------
Post by Christer JacobssonWhy the value 2048? Others have recommended 1536 instead here. Which
value is best?
Best? Don't know. Note that, per above, I could have made it even
larger. ...I've been experimenting.
----------------------------------------------------------------------------
=n
This will increase the number of available filehandles, default 20, for
the SHELL process with the specified number 'n'.
This setting is also inherited by child-processes and can avoid some
out-of-handles errors.
<<=Note=>> This became more important because the later (Workplace)
shell keeps more handles open for its own use, leaving less for started
processes to open. This has caused problems in several compiler/build
environments.
<<=Note=>> Applying this line with n=20 solves the WSeB fix1 problem,
that 'unable to write OS2SYS.INI is displayed very couple of minutes
----------------------------------------------------------------------------
Post by Christer JacobssonAnd what does this statement do? And why the high number here? I have
mine set at 20.
The big number is "on prospect". One of Yurio Dario's old pages
mentioned it as a help in getting BlueCad to run at all.
Remember, I'm having trouble running a program, BOINC/SETI, for which
the issues appears to be Shared Memory. How it's used, and by whom.
The *best* evidence I have is SETI runs out of resources (memory) and
freezes. That's why I'm tuning memory-related items in Config.Sys.
It's my *only* reason for fussing with it.
So far nothing has helped -- which is why I'm wondering what others
might use. Clutching at straws.
NB: Except for *my* one obvious comment, all these answers to your
questions come from the database included in ConfigTool130.zip and
updates. "Oldie but a Goodie"; still useful. Has a Swedish language
pack too. ;)
Post by Christer JacobssonIt's really funny with other users in this list experiencing freezes in
BOINC/SETI (v6 or v5?): on my ten-year old warhorse - a Fujitsu-Siemens
Primergy D170 server w/ 800MHz P-III, 640Mib RAM and 3 SCSI hdd's -
[ snip ]
Yeah, well... newer systems (mine) obviously aren't always better.
The "new" SETI ("enhanced"? - BOINC5, BOINC6), isn't working on this
"new" machine, new OS -- whereas the "old" SETI ran just fine. *Same
machine* (but eCS2.0 b7 'Silver')!
- Bill
--
WD "Bill" Loughman - Berkeley, California USA
http://home.earthlink.net/~wdloughman/wdl.htm
------------------------------------