-- [ From: John P. Burke * EMC.Ver #2.10P ] --
 
We discovered and, with the help of the Response Center and Lab,
identified the cause of, a problem that can seriously impact the
performance of serially connected devices under MPE/iX 5.0.
Fortunately, there is a simple work-around available until a
permanent solution is found.
 
The symptom is "jerky" throughput on printers or at terminal
sessions; e.g. a LISTF will display 3-5 lines, pause for several
seconds, display the next 3-5 lines, pause for several seconds,
etc. The system console and VT sessions are not affected.
Performance tools will not indicate any CPU, disk I/O or memory
pressure (this is what made it so hard to diagnose). If you have
a sufficiently comprehensive performance tool it will show
excessive resource locking.
 
This is something of a corner case defined by the following
conditions:
 
   You must be sending bulk data to multiple (although it could
   be as few as one in small configurations) low-speed (<=
   2400bps throughput) serial devices (printers or terminals/PCs
   with attached printers). The ratio of the number of
   simultaneous low-speed devices to the number of configured
   serial LDEVs can be as low as 1/12. In our particular case, we
   had 48 serial LDEVs configured and the threshold was 4
   simultaneous low-speed devices.
 
This problem was created when the serial I/O portions of MPE/iX
were extensively modified for release 5.0. The problem does not
occur on MPE/iX 4.0.
 
MPE/iX 5.0 allocates 2 terminal buffers for each configured
serial LDEV (in our case 2 x 48 = 96). This number is probably
too low, but is not configurable by the user (remember TBUFs in
MPE/V?). What really creates the problem, though, is the way this
number interacts with the profiles defined in NMMGR. For example,
the profile for termtype 18 specifies that any device using that
profile can acquire up to 24 terminal buffers. This number is
almost certainly too high and is also not user-configurable. What
happens is that low-speed devices receiving bulk data rather
quickly acquire and tie up their maximum allotment of terminal
buffers (in our case, 4 x 24 = 96), possibly exhausting the
available supply. When there are no available tbufs, other
processes have to pause until one or more are freed up.
 
If you have this problem now, or suspect you might have it when
you move to MPE/iX 5.0, the work-around is to configure one or
more "virtual" DTC72s. Each fully configured "virtual" DTC72
gives you 144 additional tbufs. You can do your own calculations
to determine a "safe" number.
 
As of last week, there was no decision on how to "fix" this
problem permanently, nor had an SR been assigned. If this affects
you, please report it to the Response Center.
 
No longer frustrated with MPE/iX 5.0,
John Burke
[log in to unmask]