jprad@faatcrl.UUCP (Jack Radigan) (09/09/89)
After getting 1.3.2 installed I've noticed a decent improvement in 19.2k
data transfers, but there are still a few things that I'd like to see for
1.4. I hope I'm not rehashing all this, but being new to the net I figured
I'd have a go...
- When a CMD_START is issued to the device the status word isn't updated
to clear the XOFF'd bits. Fixing this is a must to get a handle on the
lock-up condition when a spurious XOFF is received, especially during
modem disconnect.
- The best solution I can imagine for the XON/XOFF handshake is to add an
adjustable timeout parameter to restart an XOFF'd device. Also, some
logic that would track CD. When it goes low the device would be sent
a CMD_START and then disable the XON/XOFF handshake until carrier is
active again.
- Possibly add some logic to drop RTS when the receive buffer is almost
full to prevent data overruns when connected to buffered modems in
7-wire mode. With the new 14.4k HST the thing will overdrive the
serial.device, adding this would really help.
- Currently, 7-wire mode requires DSR to be active in order for data to
be passed, this is at odds with the default operation of most modems
which tie DSR to CD. Removal, or at least relaxing this so that data
can be passed when CD is also low would cure alot of headaches for
those users who aren't too familiar with the business end of RS-232...
- Add a SDCMD_DROPDTR for modems that can go on-hook and to command mode
when the DTR line is pulsed. I am currently forced to close/wait/re-open
the device to simulate this.
- Not sure where this one fits in, but several people have reported some
problems with certain hard disk controllers which use very high priorities
for their device drivers. Data loss is really a problem when they have
3 or more partitions active and are doing 19.2k downloads. Although
YMODEM-g offers the best throughput for MNP connections, these people
are forced to fall back to ZMODEM due to the lack of error recovery with
the former protocol. Is there some way to increase the priority for
serial reads to reduce, and hopefully, eliminate this?
Well, that's about it for now, what say CATS? Any of these possible for
the 1.4 serial.device? Hope so...
-jack-