bob@OHIO-STATE.ARPA (Bob Sutterfield) (11/12/86)
In article <1679@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: >Kermit dogs our VMS system down... whenever one of us uses kermit >to communicate over the modem, it really dogs our 11/750 down... it is >particularly bad when typing long messages or kermitting files... has anybody >else had this type of problem, and is there an easy fix? > I don't know if the problem is with VMS, or Kermit... Thanks. Yes, I've noted that problem on a 750 running VMS. Even at 1200 bps on a DMF-32 modem port, filling a screen (like by cat(1)ing a text file on the remote system) can grab over 90% of an otherwise-busy CPU (thus saith MONITOR). Curiously enough, unlike your report, I only saw the problem while CONNECTed to a remote system, never while SENDing or GETting a file to/from a remote server. The clue to the cause is to look (still via MONITOR) at all the buffered I/O that's going on in your process. Think about all those characters passing through the port drivers, the class drivers, etc. to get to your screen, generating high-priority interrupts as they go. It's pretty gruesome. I tried various permutations of the SYSGEN parameters concerning silo and DMA and typeahead buffer sizes, particularly the one that controls when the minimum-size thing that triggers a switch to "DMA mode" from character-by-character interrupt mode - I think it's TTY_DMASIZE (I no longer have any connection with VMS systems, so my memory is foggy of its name). Nothing seemed to help me. It seems to me that the only way to improve this problem would be to make Kermit much more intelligent about VMS guts, in order to bypass some of the layers that characters have to go through. This, of course, would make it much less portable, even to new versions of VMS, as the terminal driver is wont to change occasionally. Like, apparently, with new major releases of the operating system. (This inquiry would be much better directed to the lists info-kermit@cu20b.arpa or info-vax@sri-kl.arpa, so I've attempted to direct followups to Usenet groups mod.protocols.kermit and mod.computers.vax)
bob@OHIO-STATE.ARPA (Bob Sutterfield) (11/12/86)
In article <1679@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: >Kermit dogs our VMS system down... whenever one of us uses kermit >to communicate over the modem, it really dogs our 11/750 down... it is >particularly bad when typing long messages or kermitting files... has anybody >else had this type of problem, and is there an easy fix? > I don't know if the problem is with VMS, or Kermit... Thanks. Yes, I've noted that problem on a 750 running VMS. Even at 1200 bps on a DMF-32 modem port, filling a screen (like by cat(1)ing a text file on the remote system) can grab over 90% of an otherwise-busy CPU (thus saith MONITOR). Curiously enough, unlike your report, I only saw the problem while CONNECTed to a remote system, never while SENDing or GETting a file to/from a remote server. The same symptoms happen while doing SET HOST/DTE, which would indicate that it's a problem inherent to character I/O under VMS, and not something wrong with Kermit. The clue to the cause is to look (still via MONITOR) at all the buffered I/O that's going on in your process. Think about all those characters passing through the port drivers, the class drivers, etc. to get from the terminal port to the Kermit application, and then back out through the same layers to get to your screen, generating high-priority interrupts as they go. It's pretty gruesome. I tried various permutations of the SYSGEN parameters concerning silo and DMA and typeahead buffer sizes, particularly the one that controls when the minimum-size thing that triggers a switch to "DMA mode" from character-by-character interrupt mode - I think it's TTY_DMASIZE (I no longer have any connection with VMS systems, so my memory is foggy of its name). Nothing seemed to help me. It seems to me that the only way to improve this problem would be to make Kermit much more intelligent about VMS guts, in order to bypass some of the layers that characters have to go through. It would have to be smarter than SET HOST/DTE, for example. This, of course, would make it much less portable, even to new versions of VMS, as the terminal driver is wont to change occasionally. Like, apparently, with new major releases of the operating system. (This inquiry would be much better directed to the lists info-kermit or info-vax, so I've attempted to direct followups to Usenet groups mod.protocols.kermit and mod.computers.vax)