🚀 go-pugleaf

michael@ceadg writes:

>Can anyone give me a good explanation of what PMGR does?  

PMGR means Peripheral Manager. In a nutshell, PMGR deals with the I/O to
peripheral devices like terminals and printers. Besides doing the actual
I/O, it is also responsible for the line-editing functions of the terminal,
if this is not handled by the controller (LAC etc.) locally.

>We are having
>a problem at one of our customer's where PMGR is using 2-3 times as much
>cpu as we expect (I used CPUTIME from DG's Performance Monitor). 

This usually means that PMGR is getting more interrupts than usual from
the I/O subsystem (hardware), i.e. from the serial devices on the system
board and/or from the LAC16.

This could be due to the fact that the buffers empty/fill too quickly, or that
I/O is done rapidly.

Is there more I/O activity going on on this machine than on the machines
you compared it with (and where you got your expectation for CPU utilization
from)?

>The 
>machine with the problem is an MV/1000 with 2 printers on the system
>board and a LAC16-II (RS422) with 7 RS422 terminals and the modem/printer
>ports on the LAC connected to input devices.  

What kind of input devices are you using? Are they sending a lot of data
into the system? Is this different from your reference system?

The ports on the system board need more CPU support than the ones on the LAC
as the LAC has local intelligence, whereas the system board's ports have to
be managed by the CPU itself. Is the excessive CPU utilisation also there 
when you close down the printers?

>The RS232 inputs on the LAC
>are not part of the problem, because the condition still exists when the
>ports are empty. There are no unterminated lines either.

This seems like a contradiction to me. Are the ports empty or not? It has
been known that PMGR CPU utilisation goes up when a line is connected to
nothing, or worse, to a cable ending in 'thin air'. PMGR receives the
interrupts from the serial controller, reads in the character (or handles
the framing error), and discards it.

>I was hoping that information on what PMGR does would help us determine
>why it is so busy on this system.  Any other suggestions about this 
>situation would be appreciated, also.

It might also be a good idea to look at the configuration of your I/O buffers
(that's part of the SYSGEN of the serial ports, i.e. the LAC). For outgoing
lines (printers etc.), you should use a large transmit buffer and a small
receive buffer. The same goes for terminals, as the input strings are usually
a lot smaller than the output. Devices that send a lot of data should have
this reversed.

>Thanks,
>mike

I hope this helps,
Ralf
-- 
Ralf Bayer                           UUCP: ...motcid!glas!bayerr
Motorola ECID                        Internet: bayerr@glas.rtsg.mot.com
Mahon Industrial Estate              Phone: +353 21 357 101
Cork, Republic of Ireland            FAX:   +353 21 357 635

In article <1992Apr8.175050.22842@ceadg>, michael@ceadg writes:
|> Can anyone give me a good explanation of what PMGR does?  We are having
|> a problem at one of our customer's where PMGR is using 2-3 times as much
|> cpu as we expect (I used CPUTIME from DG's Performance Monitor).  The 
|> machine with the problem is an MV/1000 with 2 printers on the system
|> board and a LAC16-II (RS422) with 7 RS422 terminals and the modem/printer
|> ports on the LAC connected to input devices.  The RS232 inputs on the LAC
|> are not part of the problem, because the condition still exists when the
|> ports are empty.  There are no unterminated lines either.

I'm no VS internals expert, but I have been a AOS/AOSVS/AOSVSII user since 
1979.  In the old days, PMGR used to be involved in passing characters to 
and receiving characters from all character-oriented devices (i.e. anyhting
that's not block-oriented).  Beginning with AOS/VS II rev 2.10, terminal 
services has moved to the kernel and is no longer part of PMGR.  

If I was having the problem you describe, I would use the DG Performance
Monitor to see how many characters PMGR was handling.  I'd probably also use
the LINE_MONITOR program to see if there was an excessive number of characters
coming in on a particular line.  You might also want to look at your parallel 
printer port and the DUART ports on the system board.  

|> I was hoping that information on what PMGR does would help us determine
|> why it is so busy on this system.  Any other suggestions about this 
|> situation would be appreciated, also.
|> 
|> Thanks,
|> mike

-- 

Coleman Poag                     Internet: poag@dg-rtp.dg.com
ECLIPSE Commercial Software      UUCP:     {world}!mcnc!rti!dg-rtp!poag
Data General Corporation
62 T.W. Alexander Drive
RTP, NC. 27709                   Phone:    919-248-5974