JRD@cc.usu.edu (Joe Doupnik) (09/08/90)
Paul Guthrie commented that a half dozen fast typists using MS-DOS Kermit to access Unix on a 3b2 started to overwhelm the packet processing capabilities of the 3b2. This might be true, but it might be mitigated by the overhead of the application being typed into. Paul wondered if there were another comms program capable of using the AT&T NetBios method but which did timed clustering of keystrokes to reduce the packet rate. I wish I had one to suggest. I did not put timed clustering into MS-DOS Kermit for several reasons, including doing the timing part and the fear that making the timing a tad too long would drive some users bonkers waiting for the echo. Lets see - say 60 wpm on PC keyboards that means a word per second or about 6 characters/sec or one character per 0.166 sec. That's just at the start where a delay in echoing becomes noticable (and seems like a mushy keyboard to me). So grouping even a pair of characters would start to produce a delay. This math also says the 3b2 would be receiving say 6 * 6 packets/sec from the group and sending back an equal number of echos. Some keyboards can be speeded up to nearly this rate for auto-repeating and might be a quick way of loading the machine. My 3b1/7300/Unix PC seems to cope with a couple dozen packets/sec when talking to VI or similar using the same comms path as Paul's people, but I don't hold down the autorepeating keys all that long. So Paul I wish you luck finding a suitable replacement program for the PCs. I think this is a situation where Kermit is still better off not adding the extra delays. A good Unix/386 system might be the ultimate answer. Another is to toggle down the cpu speed on the client PCs; ugly, but doable. Joe D.