dg@lakart.UUCP (David Goodenough) (08/22/89)
Can anyone explain the following to me. A local BBS I call uses ^S ^Q for flow control, and when they were running with a standard 2400 BPS modem all was well. However they've started using a USR for 9600 BPS access, and since then the system takes about 30 seconds to respond to a ^S. This makes it very difficult to read long messages. The SYSOP swears up and down it's not the modem, but I've had a couple of comments that you need to do some initialization to the HST to get it to pass ^S instantly to the application. Anybody know anything about this and can recommend anything? Thanks in advance, -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
steve@conch.UUCP (Steve Froeschke) (08/23/89)
In article <663@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >Can anyone explain the following to me. A local BBS I call uses ^S ^Q >for flow control, and when they were running with a standard 2400 BPS >modem all was well. However they've started using a USR for 9600 >BPS access, and since then the system takes about 30 seconds to >respond to a ^S. This makes it very difficult to read long messages. >The SYSOP swears up and down it's not the modem, but I've had a couple >of comments that you need to do some initialization to the HST to get >it to pass ^S instantly to the application. > >Anybody know anything about this and can recommend anything? > David, I used to use the HST on the BBS system here, but have since switched to the TB+. The problem sounds to me like the Sysop of your system has locked the port rate of the computer<-->modem to either 9600 or (most likely) 19200. Depending on what bbs software he/she is using, that can cause problems with 'hot keys' not responding, etc. The fix that I used was to limit the transmit buffer down to 128 bytes vice the normal (default) of 1024 bytes (1K). This helped quite a bit, but still, there was a little delay in response. (But considering you can interrupt it every 128 bytes vice 1K, it worked much much better). What I would recommend is letting the Sysop of the system know about the transmit buffer size, and see if he/she is agreeable to reducing it. I hope this helps David. Steve -- --------------------------------------------------------------------------- If it moves, Salute it, if it doesn't paint it gray and sail it! --------------------------------------------------------------------------- Steve Froeschke | uunet!conch!steve
cth_co@tekno.chalmers.se (CHRISTER OLSSON) (08/24/89)
In article <218@conch.UUCP>, steve@conch.UUCP (Steve Froeschke) writes: > cause problems with 'hot keys' not responding, etc. The fix that I used > was to limit the transmit buffer down to 128 bytes vice the normal (default) > of 1024 bytes (1K). This helped quite a bit, but still, there was a > little delay in response. (But considering you can interrupt it every > 128 bytes vice 1K, it worked much much better). What I would recommend > is letting the Sysop of the system know about the transmit buffer size, > and see if he/she is agreeable to reducing it. The transmitt buffer is 3.5K in ARQ-mode and 1.5K, not 1K in non-ARQ-mode. ATS15=8 reducing the non-ARQ-buffer from 1.5K to 128 bytes.