dg@lakart.UUCP (David Goodenough) (11/10/89)
lenny@icus.islp.ny.us (Lenny Tropiano) sez: > What if one assumes they have RTS/CTS hardware flow control on both > end-points? Wouldn't that prevent against serial port overrun > problems with the modem sending too much to the system? That will only help the modems from being overrun. One problem with RS232 is that it is not symmetrical: the terminal doesn't have a CTS equivalent to tell the modem to wait a while. Sure, you could drop DTR, but most modems will stop sending with extreme prejudice if you do that: they hang up :-( It is always assumed that DTE can accept data as fast as the modem can send it. Why else did I have my 19th. nervous breakdown writing an interrupt driven serial I/O driver for my CP/M machine, so that it could do nice things with a V.32 MNP 9 modem at 19.2 KBPS, and the system at work? (And you should see those two swapping mail :-) ) -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
david@ms.uky.edu (David Herron -- One of the vertebrae) (11/13/89)
In article <1009@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >What is the "G" protocol? Also the "d" protocol? I've also seen >the "x" protocol? I'm not familiar with G I saw 'd' the other day being offered by a 3b20 in Orlando that's on the AT&T Datakit. I assumed at the time that 'd' was some special purpose gadget for datakit connections, and I was going to report the sighting of it but forgot. Oh well. As I recall, 'x' is a protocol in HDB for X.25 connections. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- New official address: attmail!sparsdev!dsh@attunix.att.com
david@ms.uky.edu (David Herron -- One of the vertebrae) (11/13/89)
In article <1014@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >In article <1989Nov6.024128.1992@terminator.cc.umich.edu> honey@citi.umich.edu, >Peter Honeyman writes: >|>Lenny Tropiano writes: >... >What if one assumes they have RTS/CTS hardware flow control on both >end-points? Wouldn't that prevent against serial port overrun >problems with the modem sending too much to the system? Lenny ... Even if your hardware flow control works well (if memory serves right, the flow control is unidrectional only) you still have some sections of unprotected wire through which you can have noise come into the picture. The signals going through the phone wire do come out flow controlled and error corrected, but the tb's don't make any gaurantees beyond the phone wire (or, at any rate, some point in the wiring inside the box). Trust Peter ... not only does he know what he's talking about he's also fun at parties :-) -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- New official address: attmail!sparsdev!dsh@attunix.att.com
csg@pyramid.pyramid.com (Carl S. Gutekunst) (11/17/89)
In article <90157@pyramid.pyramid.com> I wrote: >>rmesg - 'P' got PGged >>... > >'G' and 'P' are both oddballs of uncertain parentage. Rick Adams experimented >with a "fixed" version of 'g' that he called 'G', but I don't think he gave it >away to anyone. 'P' I've never seen before. I was asleep at the wheel. The 'P' is the "protocol" query code, of course. <csg>