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 +---+
prc@erbe.se (Robert Claeson) (11/12/89)
In article <747@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >... 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 :-( Ahm, the high-speed modems we use here (V.32 modems with MNP class 9) can be set to use many different flow-control schemes. Aside from not using flow control at all, they can also be set to use unidirectional and bidirectional xon/xoff and h/w flow control (unidirectional: as per the intended use of the RS232C standard; bidirectional: modem uses CTS and terminal uses RTS to tell each other when they're ready to receive). We use the latter. We have tried using the uucp 'e' protocol over such a link (with MNP enabled). No errors at this time. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
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
news@bbn.COM (News system owner ID) (11/14/89)
In article <1016@maxim.erbe.se> prc@erbe.se (Robert Claeson) writes:
< ... We have tried using the uucp 'e' protocol over such a
< link (with MNP enabled). No errors at this time.
You are "gettin' lucky" then. Even if you have a modem-to-modem error
free connection, and perfect flow control between each modem and
computer, there is STILL a non-zero chance of loosing a bit or two in
the cables. Therefore, you MUST use a protocol that checks the data
END-TO-END (not just modem-to-modem). Doing otherwize is for PC
weenies who don't know better (and who end up hand-checking the files
they download anyway).
Look at it this way: RAM doesn't fail often, but it does every once in
a while. Would you rather run memory without any checking, memory
with parity, or memory with error-correction?
-- Paul Placeway <PPlaceway@bbn.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>