Eric Thomas <ERIC@FRECP11>
Sat, 14 Mar 1987 22:27 SET
|
I've just spent nearly one full day on LSVBITFD to improve it -- it was
badly needed. The new version seems to work but I'll be very careful about it
considering the number of changes I have made. I would like 2-3 beta-test
sites before I distribute the new module along with release 1.5i.
The following enhancements have been made:
- The restriction that no more than (about) 60 nodes may be passed as
arguments has been removed. This was the hardest thing but the most
important one. It will allow me to 'officialize' more than 60 servers as
soon as everybody has installed the fix. Right now, there are about 10 nodes
waiting to be added to PEERS NAMES because if I exceed the limit of 60, all
the LISTSERVs in the world will crash as soon as they try to use LSVBITFD.
Removing this restriction decreased performances by 3% :-(
- The restriction that link weights be in the 1..9 range (with '9' temporarily
equated to '100' (btw, it was actually '101' due to an error in the program
but who cares :-) )) has been removed. Link weights up to '9999' are now
allowed, and it is possible to set a link weight of '0' if desired (for
example, a CTC link).
- It is now possible to specify two different weights for the same physical
link, depending on the direction of the transfer. For example, you can say
that CUNYVM -> PSUVM is 5 nodes but PSUVM -> CUNYVM is only 2. This should
be handled with GREAT CARE as files going from PSU to CUNY will slow down
those going in the other direction. But still, I think it would be a good
thing to place more load on BITNIC -> EARNET (100% busy) than on EARNET ->
BITNIC. The default option is the same weight for both directions.
- Using the NOWEIGHT option no longer causes the in-storage links table to be
dropped upon completion of the program. Also, the algorithm used was changed
and caused an overall performance improvement of 25% for the NOWEIGHT
option, PLUS the fact that you're not doing large amounts of DASD I/O every
time.
- The program has been optimized (again), which caused an overall performance
improvement of a little more than 15%. That was measured before I fixed the
60 nodes restriction, so the overall savings are only 12% or so. It now runs
in about 0.16/0.17 (depending on the parameters) on my CPU.
Drawbacks:
- The format of the LINKSUM file had to be changed. The new format is fully
INcompatible with the old one, and the new program does NOT support the old
format (but it detects it and sets rc=102). Also, the new format file is 25%
larger than the old one :-(
- The program reserves and keeps around 40k additional storage. Part of this
is due to the larger LINKSUM file, but I also had to keep another work
buffer across execution because it took much more time to build with the new
format than with the old one.
- LSVBITFD can no longer be called from EXEC 1. It will exit with rc=103 in
that case. No problem with EXEC 2, REXX, XEDIT or CMS console mode
invocation of course.
Other changes:
- LSVBITWT (the NODESGEN WTONLY processor) has been updated to support the new
LINKSUM file format. It accepts the old format as input without problem so
that you don't have to re-generate the LINKSUM file. Actually, NODESGEN will
still generate files in the old format and let LSVBITWT convert them. It
takes 0.35 additional seconds to make the conversion but who cares --
NODESGEN takes around 5 minutes CPU... LSVBITWT is now slower but that's not
important as it's executed only once a month normally and eats only 1.35 sec
CPU or so.
Eric
|
|
|