| Title: | POLYCENTER Console Manager |
| Notice: | Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS: |
| Moderator: | CSC32::BUTTERWORTH |
| Created: | Thu Aug 06 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1541 |
| Total number of notes: | 6564 |
Hello, I have been working the following issue with one of the BANKS, They use PCM 1.5 with the mup to monitor their production cluster. They very much would like to have real-time hardcopy output of the cluster environment. So they use the WATCH process on the 19 nodes in the cluster. The problem appears when we have a flurry of opcom messages, and they get backed up when trying to print to the LA75 printer off of the PCM engine. This is especially a problem when they reboot one of the nodes, because this backlog on the printer will inevitably slow down the nodes boot-time. For example a node normally takes 8 minutes to boot-with the printer turned off. When the node is booted with the printer turned on, we have seen times as great as 40 minutes. I have suggested that they could wait and do an extract and then print out this information, but they feel that it is not unreasonable to ask for real-time hardcopy output. You know how reasonable the BANK can be! Thanks in advance for any help you can offer. John Gonzalez CSC/CS dtn:592-4651
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 691.1 | YOSSAM::PHILIP | And through the square window... | Tue Apr 25 1995 14:45 | 15 | |
John, If your customer wants real-time hardcopy output, then suggest to them that they get a printer which can keep up with the amount of data they are outputting!!!! The problem your customer is seeing is actually described in the documentation, see section 6.4.2 in the Users guide. There is absolutely NOTHING we can to to alleviate this situation for your customer. Cheers, Phil | |||||
| 691.2 | CSC32::J_GONZALEZ | Tangled Up In Blues? | Tue Apr 25 1995 15:31 | 12 | |
Phil, I looked at the reference you gave me and yes this does address this problem. Some further questions... 1.Is it true that the booting systems console is getting XOFFed from the PCM engine because the printer cannot keep up with the amount of data? Thanks, John | |||||
| 691.3 | YOSSAM::PHILIP | And through the square window... | Tue Apr 25 1995 15:53 | 24 | |
John, >> 1.Is it true that the booting systems console is getting XOFFed from the PCM engine >>because the printer cannot keep up with the amount of data? Indirectly, yes. What actually happens is this... The WATCH process will stall on its qrite to the printer (when the printers buffer is full), this will prevent the WATCH process from reading it mailbox to the console controller daemons, consequently, they will stall writing data to the mailbox connecting them to the WATCH process. Now, as a result of this, the controller will no longer service data on the console line (via a QIO), so when the TT drivers buffer is full, it will XOFF the line. So as you can see, we dont explicitly XOFF the console line, it is done for us when we dont read the data fast enough and the typeahead buffer fills. Now, V1.6 could (and I stress COULD) help your customer here, as we service our QIO's to both the console devices and the mailboxes asynchronously, that is, we keep reading the data and simply place it on a work queue. The drawback to this is that if you queue too much your process may run out of Virtual Memory and croak!!! Hope this helps, Cheers, Phil | |||||
| 691.4 | Thanks for the explaination! | CSC32::J_GONZALEZ | Tangled Up In Blues? | Tue Apr 25 1995 17:55 | 11 |
Thanks Phil for your explaination. I discussed the information in the User's Guide with the customer, and he has agreed with this section. Also I mentioned that he may see some improvement with the next version of the product. Thank you, John | |||||