evan@telly.on.ca (Evan Leibovitch) (02/12/91)
I've been looking at the Equinox Megaport boards and they look like a
decent deal. Then someone said that they won't do hardware flow control
and modem control on the same port at the same time.
Is this true? It would strike me that having both functions is to get a
Telebit going at top speed. Or is it -- can a Telebit be run at full
speed on UUCP transfers using Xon-Xoff? I would think that this could be
a problem if the Xon is imbedded in a binary transfer...
--
Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario
evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504
Ididntdoit, nobodysawmedoit, youcantproveathing. - Bartcpcahil@virtech.uucp (Conor P. Cahill) (02/14/91)
In article <27B79130.5C72@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >I've been looking at the Equinox Megaport boards and they look like a >decent deal. Then someone said that they won't do hardware flow control >and modem control on the same port at the same time. That is correct. >Is this true? It would strike me that having both functions is to get a >Telebit going at top speed. Or is it -- can a Telebit be run at full >speed on UUCP transfers using Xon-Xoff? I would think that this could be You cannot use xon-xoff flow control with UUCP because they can appear as a character within the data (or in the packet headers). We have a T2500 running full blast on our Equinox 24 port card with no problems. We get about 1500 bytes/sec on output and 900-1100 bytes/sec on input. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
chip@chinacat.Unicom.COM (Chip Rosenthal) (02/14/91)
In article <1991Feb13.170319.13308@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <27B79130.5C72@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >>[Someone said that Megaport serial cards] won't do hardware flow control >>and modem control on the same port at the same time. > >That is correct. Conor...are you sure about that? I use the Equinox boards. I've done just about everything you can do with them except high-speed dialin/dialout modems. According to the manual - it does work. But I won't state that unequivocally since I haven't tried that one item. The way you get it is a little bit tricky. The Megaport cards provide a pair of control signals per port. It is up to the distribution box to route them to the appropriate pins, and the driver to interpret them as the appropriate RS-232 signals. So, normally you can get DSR/DTR or RTS/CTS per port. If you need both pairs, you need to steal the control signal pair from an adjacent port. Megaport provides a utility which configures this. The tricky part is that you can't steal signals from any arbitrary port and place them on any other arbitrary port. Half the ports are predesignated as potential donors, and a donor can only give its control signals to one particular port. Therefore, you need to exercise a little forethought before hooking things up. This scheme is not pretty, but it is usable in most cases. Since most folks use a three-wire connection for terminals, you usually have an abundance of control signals to steal. If however, you are trying to drive a bank of high speed modems with full modem control, or you like to bring DTR out to your terminals, then this board is not appropriate. BTW...the Megaport manual has an appendix on how to hookup up the Telebit. I've also found their support folks to be pretty good - you might want to give them a holler with any questions. So again, on paper, the Megaport looks like it will do what Evan wants. However, I concede to not testing it first-hand. Please correct me if I'm overlooking something, or if things don't work quite the way they are documented. -- Chip Rosenthal 512-482-8260 | Unicom Systems Development | I saw Elvis in my wtmp file. <chip@chinacat.Unicom.COM> |
cpcahil@virtech.uucp (Conor P. Cahill) (02/15/91)
In article <1855@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: > >Conor...are you sure about that? I use the Equinox boards. I've done It is correct that they won't do hardware flow control and modem control on the SAME port. You are correct that they have a work around that deals with stealing signals from a second port. However, that second port then ends up without any control (modem or hardware flow). We haven't found the need to do this on our system even though it would be pretty easy since we use punch blocks for our connections off the system. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
kdenning@pcserver2.naitc.com (Karl Denninger) (02/15/91)
In article <27B79130.5C72@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >I've been looking at the Equinox Megaport boards and they look like a >decent deal. Then someone said that they won't do hardware flow control >and modem control on the same port at the same time. > >Is this true? It would strike me that having both functions is to get a >Telebit going at top speed. Or is it -- can a Telebit be run at full >speed on UUCP transfers using Xon-Xoff? I would think that this could be >a problem if the Xon is imbedded in a binary transfer... You >can< make an Equinox card do hardware flow control, but you have to live with a couple of strnage things :-) First, you have to wire a very strange cable. This is no big deal, but it is a difference from what you've done in the past (basically you steal control signals from the next port up). Secondly, the next port up the line from the one you have connected with full modem control has to run either data only or not be used. These are good ports to use for printers that only need 2,3 and 7 connected, however. If you need ALL FMC ports then you're limited to 24/2 or 12 ports on the 24 port cards..... Third, you do a "megamap +fmc </dev/ttyxx", where the tty name is the name of the port which you have connected the device to which needs the full control. That activates it. It stays that way until you reboot. If you're using the Telebits for uucp or interactive use, you DO NOT need to do this. The Equinox cards can easily keep up with the data requirements without help, and UUCP is a self-pacing protocol. However, if you intend to use something like Zmodem at high speeds you >do< need it. In any event it does work and is quite useful in the cases that you actually require it. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
richard@pegasus.com (Richard Foulk) (02/15/91)
>>Is this true? It would strike me that having both functions is to get a >>Telebit going at top speed. Or is it -- can a Telebit be run at full >>speed on UUCP transfers using Xon-Xoff? I would think that this could be >>a problem if the Xon is imbedded in a binary transfer... > > [...] > >If you're using the Telebits for uucp or interactive use, you DO NOT need to >do this. The Equinox cards can easily keep up with the data requirements >without help, and UUCP is a self-pacing protocol. However, if you intend >to use something like Zmodem at high speeds you >do< need it. > Uucp connections in general are not "self-pacing", if by that you mean they do their own handshaking. Uucp connections via Telebits in PEP mode with uucp-spoofing enabled are "self-pacing". If all you need to do is make uucp connections via PEP then you don't need any hand-shaking, and in some instances things work a little faster that way. If you need to also make reliable 8-bit transparent connections at other speeds you will either have to insure that the data rate of the modem connection matches the port baud-rate, or have hardware hand-shaking that works (modem compression, etc., cause problems here). Pegging your port speed at 19200 and trying to make uucp exchanges with other modems at 1200, 2400 and 9600 V.32 will most likely fail without hardware handshaking. If you want to use your Telebit in answer mode for a variety of calling situations and uses, not just uucp, you really do need hardware handshaking to take full advantage of the modem.
witr@rwwa.COM (Robert W. Withrow) (02/16/91)
In article <1991Feb15.083043.11636@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >Uucp connections in general are not "self-pacing", ... >Pegging your port speed at 19200 and trying to make uucp exchanges with >other modems at 1200, 2400 and 9600 V.32 will most likely fail... My experience indicates that these statements are incorrect. The UUCP `g' protocol *is* ``self-pacing'' in the sense that it has a limited window and limited packet sizes, and is an ARQ protocol, requiring an acknowlegement for each packet transmitted. Thus the flow-rate is ultimately controlled by the receiving computer. In the case of Telebit modems, for PEP and Direct V.32 (but not V.42 LAP-M) connection, the modem ``spoofs'' the `g' protocol, and thus the pacing (aka flow-control) is performed by the modem in this way. With other modems (and telebit modems using LAP-M), the pacing is done by the two computers via the `g' protocol. In cases where the DTE-to-modem bit rate is higher than the modem-to-modem bit rate, modern modems generally have enough buffer capacity to run UUCP `g' protocol without using *any* DTE-to-modem flow control! As an example, UUNET has *all* DTE-to-modem flow control disabled on their modems. On my system I have found that I get the most reliable operation by doing likewise. I have my DTE speed set at 38400 BPS, and have successfully performed UUCP `g' to other modems operating at 2400, 4800, and 9600 BPS. -- --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Uucp: witr@rwwa.COM
kdenning@pcserver2.naitc.com (Karl Denninger) (02/16/91)
In article <1991Feb13.170319.13308@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <27B79130.5C72@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >>I've been looking at the Equinox Megaport boards and they look like a >>decent deal. Then someone said that they won't do hardware flow control >>and modem control on the same port at the same time. > >That is correct. See my post on this subject. It's plain wrong. >>Is this true? It would strike me that having both functions is to get a >>Telebit going at top speed. Or is it -- can a Telebit be run at full >>speed on UUCP transfers using Xon-Xoff? I would think that this could be > >You cannot use xon-xoff flow control with UUCP because they can appear >as a character within the data (or in the packet headers). > >We have a T2500 running full blast on our Equinox 24 port card with >no problems. We get about 1500 bytes/sec on output and 900-1100 bytes/sec >on input. However, if you turn on XON/XOFF in a Telebit modem and use spoofing (S111-30), it is smart enough to disable it when a uucp call comes in or out. Thus, it works for both interactive users AND UUCP calls. This is not obvious, but it does work. I do it that way myself on one modem, the other I wired strange for full modem control (CTS/RTS + modem control) since it has V.32 capability and you need it there. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
chip@chinacat.Unicom.COM (Chip Rosenthal) (02/16/91)
In article <1991Feb15.165755.3231@pcserver2.naitc.com> kdenning@pcserver2.naitc.com (Karl Denninger) writes: >However, if you turn on XON/XOFF in a Telebit modem and use spoofing >(S111-30), it is smart enough to disable it when a uucp call comes in or >out. True...but in the general case I don't believe it's a good thing to do. This is a function of the spoofing code (thus I assume we have Honeyman's foresight to thank for the modem `doing the right thing'). However, if you've got uucp connections with non-telebit modems, the XON/XOFF handshaking will not be inhibited, and you will almost certainly encounter problems. I'd be hard pressed to recommend an option because `it's just going to get disabled anyway'. Realistically, I think your choices are either: (1) run RTS/CTS handshaking, or (2) use no handshaking and run the serial line speed at the modem speed. Since the uucico g protocol only allows a number of outstanding packets, it tends not to overrun buffers on either side of the communication channel and option #2 tends to work just fine. A third option is to lock the serial speed and run without any flow control, but you'd better pray you've got big and fast buffers in the serial cards on both ends. For those unfamiliar with the problem, if you've got XON/XOFF flow control enabled in the modem, transmission of a binary file with a '\023' byte will look like an XOFF character to the modem, and thus it will halt all transmission back to the system. This problem manifests itself by uucico going into an `alarm 1...alarm 2......alarm N...giving up' mode. In the typical case, this will occur when sending a compressed news batch. -- Chip Rosenthal 512-482-8260 | Unicom Systems Development | I saw Elvis in my wtmp file. <chip@chinacat.Unicom.COM> |
randy@wa4mei.UUCP (Randy Jarrett) (02/16/91)
In <27B79130.5C72@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >I've been looking at the Equinox Megaport boards and they look like a >decent deal. Then someone said that they won't do hardware flow control >and modem control on the same port at the same time. >Is this true? It would strike me that having both functions is to get a >Telebit going at top speed. Or is it -- can a Telebit be run at full >speed on UUCP transfers using Xon-Xoff? I would think that this could be >a problem if the Xon is imbedded in a binary transfer... >-- > Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario > evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504 > Ididntdoit, nobodysawmedoit, youcantproveathing. - Bart In their manual Equinox shows you how to combine two ports and use a special feature of their driver to handle the handshaking. -- Randy Jarrett WA4MEI UUCP ...!{emory,gatech}!wa4mei!rsj | US SNAIL: P.O. Box 941217 PHONE +1 404 493 9017 | Atlanta, GA 30341-0217
root@equinox.UUCP (Super user) (02/19/91)
In article <1855@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: >In article <1991Feb13.170319.13308@virtech.uucp> > cpcahil@virtech.UUCP (Conor P. Cahill) writes: >>In article <27B79130.5C72@telly.on.ca> > evan@telly.on.ca (Evan Leibovitch) writes: >>>[Someone said that Megaport serial cards] won't do hardware flow control >>>and modem control on the same port at the same time. >> >>That is correct. > >Conor...are you sure about that? I use the Equinox boards. I've done >just about everything you can do with them except high-speed dialin/dialout >modems. According to the manual - it does work. But I won't state that >unequivocally since I haven't tried that one item. > >The way you get it is a little bit tricky. The Megaport cards provide a >pair of control signals per port. It is up to the distribution box to >route them to the appropriate pins, and the driver to interpret them as >the appropriate RS-232 signals. So, normally you can get DSR/DTR or >RTS/CTS per port. If you need both pairs, you need to steal the control >signal pair from an adjacent port. Megaport provides a utility which >configures this. > Chip's right, we do support Hardware Flow Control RTS/CTS OR DTR/DCD. The tricky part comes in when you need both. Very few peripherals need both. Contrary to popular belief, Telebit to Telebit transfers work fine. We download netnews using a Telebit with only xon/xoff flow control setup. It seems to work fine. And Chip's right again, when in an earlier posting, he mentioned how the equinox full modem control scheme was "a bit screwy". In order to get eight lines, you've got to rewire and take two from a "donor port". I've emailed chip about his posting. We're going to be changing to make it easier for the user. We're not sure whether we will sell a different dsub housing box, with six full-modem control ports and six data-only ports on it, or provide a special adaptor which plugs into two six-line ports and convert them to an eight full-modem line port and a four data- only port. The disadvantage of the new 12 housing box, is that it has been called "overkill" here, since it is doubtful whether most sites would have more than 1 or 2 fax modems or Telebits. I welcome any input from the net. Since we sell through Distributors, sometimes it is not as easy to get direct customer feedback as when you sell direct. Postings about MEGAPORT from USENET are routed through the entire MEGAPORT division. Feedback from the Net really does make a difference e.g., we are going to change from the ribbon cable to a 100-pin round cable which is neater--and shielded. I know this whole issue of full-modem control, Telebits, flow control, donor ports is confusing (but it does work) -- but something confusing should be changed. If I can answer any questions, please email me, of if you have a support problem you can send it to: uunet!equinox!support and it goes to about four-five people.
larry@nstar.rn.com (Larry Snyder) (02/19/91)
kdenning@pcserver2.naitc.com (Karl Denninger) writes: >>That is correct. >See my post on this subject. It's plain wrong. Ok, it's wrong unless you want to tie up 2 ports for every one port that you desire hardware flow control on -- So in reality, a 12 port board yields 6 ports with hardware flow control -- -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
scotto@ipars.UUCP (Scott O'Connell) (02/20/91)
In article <27B79130.5C72@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >I've been looking at the Equinox Megaport boards and they look like a >decent deal. Then someone said that they won't do hardware flow control >and modem control on the same port at the same time. The Equinox Megaport _will_ do hardware flow control. I'm doing it here on ipars and it works great. It does take some work and you need Equinox drivers that support this feature. Since the origins of Equinox products only needed 2 control signals (1-in 1-out) per data port, they support DTR/CD on each port by default. This is sufficent for standard ports. If you want to use RTS/CTS you must "steal" the hardware from an ajacent port. Here is an example of my installation: ttyaA Telebit T2500 with 19200 locked interface and hw/flow ttyab Wyse 60 with xon/xoff ttyaC Telebit T2500 with 19200 locked interface and hw/flow ttyad Wyse 60 with xon/xoff ttyaE PPI 9600SA with 38400 locked interface and hw/flow ttyaf Wyse 60 with xon/xoff ttyaG Hayes 2400 using DTR/CD only. In the above example I use the control signals from ttyab on ttyaa to give me DTR/CD and RTS/CTS. etc.. >Is this true? It would strike me that having both functions is to get a >Telebit going at top speed. Or is it -- can a Telebit be run at full >speed on UUCP transfers using Xon-Xoff? You don't need hardware or xon/xoff flow control with UUCP.
woods@eci386.uucp (Greg A. Woods) (02/21/91)
In article <1991Feb15.165755.3231@pcserver2.naitc.com> kdenning@pcserver2.naitc.com (Karl Denninger) writes: > In article <1991Feb13.170319.13308@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > >We have a T2500 running full blast on our Equinox 24 port card with > >no problems. We get about 1500 bytes/sec on output and 900-1100 bytes/sec > >on input. > > However, if you turn on XON/XOFF in a Telebit modem and use spoofing > (S111-30), it is smart enough to disable it when a uucp call comes in or > out. Thus, it works for both interactive users AND UUCP calls. > > This is not obvious, but it does work. I do it that way myself on one > modem, the other I wired strange for full modem control (CTS/RTS + modem > control) since it has V.32 capability and you need it there. I don't feel entirely qualified to say much directly about Equinox ports boards, or Telebit's, but I do have a great deal of async experience on a wide variety of hardware. From what I understand the particular combination of an Equinox card and a Telebit will work fine when sending files, since the Telebit properly paces everything such that its buffer's don't over-flow. However, in certain circumstances when receiving a file via UUCP with this setup, I can see that the uucico may lose packets if there is no hardware flow control. Maybe the uucico is swapped out. Maybe the system has a load average of 15. Remember, UNIX isn't a real time O/S. Any lost packets will mean timeouts in the uucico. That's probably why Conor is seeing only an average of 1000 cps input. I'd be real disappointed if that's all I was seeing on my system. Now, for any other devices, i.e. non-spoofing modems, hardware flow control will be required when sending *or* receiving files with UUCP. In fact I wish our Anchor 2400 modem had working hfc sometimes, since when our system gets busy, packets get dropped, and because the alarm timeouts are lengthy, it can do a real number on the over-all throughput. On a busy day, our receive throughput may drop from 190 cps to 90 cps at 2400 bps. All you folks running single user 33 Mhz 386's and 16 Mb RAM won't have to worry, but the rest of us do. Finally, I don't care how fast that little Equinox card can receive characters, if I can't get them safely onto my disk, all the speed in the world won't help. I.e. can I cat from each port into separate files, and receive every byte without any flow control? That's potentially over 90 Kbytes per second coming into the system. It just won't happen on my 386, no matter what O/S I'm running. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
cpcahil@virtech.uucp (Conor P. Cahill) (02/21/91)
woods@eci386.uucp (Greg A. Woods) writes: >However, in certain circumstances when receiving a file via UUCP with >this setup, I can see that the uucico may lose packets if there is no >hardware flow control. Maybe the uucico is swapped out. Maybe the The only time you should loose packets is if the buffers between the host and the modem cannot hold a window's worth of packets (8 packet window with 64 bytes per packet == 512 bytes of buffering are needed). Between the Clists and the buffers on the I/O card, there should be no reason to loose a packet. >system has a load average of 15. Remember, UNIX isn't a real time >O/S. Any lost packets will mean timeouts in the uucico. That's >probably why Conor is seeing only an average of 1000 cps input. I'd >be real disappointed if that's all I was seeing on my system. I hadn't seen any higher numbers from other people when accessing UUNET, so you haven't convinced me that we have a problem. In fact, running uucico with debug turned on show NO TIMEOUTS (no alarm messages) which does indicate that we are NOT loosing packets. >Now, for any other devices, i.e. non-spoofing modems, hardware flow >control will be required when sending *or* receiving files with UUCP. Again, the only thing that is needed is enought room to store a window's worth of packets on the recieving end (then the transmitting end will wait for the acknowledgement of the first packet). >cps to 90 cps at 2400 bps. All you folks running single user 33 Mhz >386's and 16 Mb RAM won't have to worry, but the rest of us do. We have a 33MHZ 386 with 16MB of ram, but we still don't loose packets even when we are processing news from the last download, running a system backup and I am logged in on my 4 or 5 xterms compileing/editing verry slowly because in this environment we are usually swapping). >Finally, I don't care how fast that little Equinox card can receive >characters, if I can't get them safely onto my disk, all the speed in >the world won't help. I.e. can I cat from each port into separate >files, and receive every byte without any flow control? That's Remember that there is a built-in flow control in UUCP (that 8 packet window), so you don't need hardware flow control on top of it unless your recieve buffers cannot hold 8 packets. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
kdenning@pcserver2.naitc.com (Karl Denninger) (02/23/91)
In article <1991Feb20.202915.21242@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >In article <1991Feb15.165755.3231@pcserver2.naitc.com> kdenning@pcserver2.naitc.com (Karl Denninger) writes: >> In article <1991Feb13.170319.13308@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >> >We have a T2500 running full blast on our Equinox 24 port card with >> >no problems. We get about 1500 bytes/sec on output and 900-1100 bytes/sec >> >on input. >> >> However, if you turn on XON/XOFF in a Telebit modem and use spoofing >> (S111-30), it is smart enough to disable it when a uucp call comes in or >> out. Thus, it works for both interactive users AND UUCP calls. >> >> This is not obvious, but it does work. I do it that way myself on one >> modem, the other I wired strange for full modem control (CTS/RTS + modem >> control) since it has V.32 capability and you need it there. > >I don't feel entirely qualified to say much directly about Equinox >ports boards, or Telebit's, but I do have a great deal of async >experience on a wide variety of hardware. As do I.... >From what I understand the particular combination of an Equinox card >and a Telebit will work fine when sending files, since the Telebit >properly paces everything such that its buffer's don't over-flow. Actually, the entire connection has pacing in at least three locations -- on your end, the remote end, and the link between the modems itself. All done with the "must ack within 3 packets" UUCP windowing. >However, in certain circumstances when receiving a file via UUCP with >this setup, I can see that the uucico may lose packets if there is no >hardware flow control. Maybe the uucico is swapped out. Maybe the >system has a load average of 15. Remember, UNIX isn't a real time >O/S. Any lost packets will mean timeouts in the uucico. That's >probably why Conor is seeing only an average of 1000 cps input. I'd >be real disappointed if that's all I was seeing on my system. Not true. The Equinox boards can buffer more than the 64 x 3 characters which can exist "outstanding" in a uucp window of standard size. The Telebits can buffer something like 10x that number without losing any internally. And they WILL do the appropriate things (like stop sending "acks" temporarially) when the buffers get to be nearly full. There is a REASON why UUCP has a window of 3 normally. That reason is that you want the characters in the window to fit within a clist, so that if the process is swapped out you don't drop anything on the floor! (You'd be surprised how many people don't know this and patch "windows" to 7 blindly!) >Now, for any other devices, i.e. non-spoofing modems, hardware flow >control will be required when sending *or* receiving files with UUCP. Actually that is not true either. Again, the window size of 3 works here, since you MUST ack packet #1 before #4 gets sent. Since the characters all fit within the clist structure, your CPU can be slow as molasses and again you won't lose anything. This is, of course, providing you can service the interrupts coming from the serial port if any. If you can't, you're doomed since the hardware flow control "trip" requires a interrupt to be processed too! If you patch the window size to >3, then you are going to get in trouble if you can't keep the buffers from filling up. >In fact I wish our Anchor 2400 modem had working hfc sometimes, since >when our system gets busy, packets get dropped, and because the alarm >timeouts are lengthy, it can do a real number on the over-all >throughput. On a busy day, our receive throughput may drop from 190 >cps to 90 cps at 2400 bps. All you folks running single user 33 Mhz >386's and 16 Mb RAM won't have to worry, but the rest of us do. Sure. If you're getting alarms then something else is wrong (ie: you're not servicing incoming com port interrupts fast enough). >Finally, I don't care how fast that little Equinox card can receive >characters, if I can't get them safely onto my disk, all the speed in >the world won't help. I.e. can I cat from each port into separate >files, and receive every byte without any flow control? That's >potentially over 90 Kbytes per second coming into the system. It just >won't happen on my 386, no matter what O/S I'm running. Well, >my< 386 can receive 90kb/sec to the disk without any problem at all. That's less than 1/6th of the throughput of my disk subsystem on a BAD day. On a good day I can do something like 10-15x that number of bytes to or from the disk. 90kB/sec is not a big number. Nor is it a problem for a reasonable system with good disk I/O performance. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
gene@zeno.mn.org (Gene H. Olson) (03/09/91)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >Remember that there is a built-in flow control in UUCP (that 8 packet >window), so you don't need hardware flow control on top of it unless >your recieve buffers cannot hold 8 packets. Remember that you may not be interfacing to the modem at the same speed the modem transmits. If that happens, and you are using a large window size, you will find the data backing up in the transmit buffer of the transmitting modem. If the transmitting modem doesn't have enough buffer space, it might be forced to discard the data. I haven't seen modems back up data with a window size of 3, but with a window size of 7 I see them flow controlling like crazy. I work for DigiBoard. We run our internal modem lines as fast as possible (usually 19200 or 38400) and use hardware flow control to keep the computer from overrunning the modem buffers. The only time I see problems is on modems that drop CTS whenever RTS is dropped. RTS from the host computer means that the input buffer is nearly full, and the modem should stop sending data until the host program can consume the data. CTS tells the host system not to send more data. If the modem drops CTS just because RTS is low, you may find the host program stopped from transmitting because CTS is low, and unable to receive data (to raise RTS) until this occurs. Then you get a lockup condition. To see if you are susceptable to this sort of lockup, I suggest you hook up a breakout box or RS232 tester and watch it closely. If you see CTS regularly drop with RTS, you have a potential problem. With all the better intelligent serial cards the input buffer is considerably larger than the regular clist line discipline size of 192-256 bytes. So generally with UUCP you never have to slow the flow of receive data. Almost all the time you can live with CTS flow control only. There is one circumstance where RTS flow control is very important. There are some versions of CU that are terrible CPU hogs; they appear to do single character tty reads and writes. If you dial out with CU and start receiving data, you'll saturate your host CPU right away and data will back up in the tty receive buffer. On any long transfer (eg ~%take) even a large buffer will eventually overflow, and you'll lose big chunks of data. If you want to do those kinds of operations, you'll need RTS. My personal opinion (based on lots of customer calls) is that you should always hook up RTS and CTS on high speed modems. If your modem vendor or serial port vendor has problems making it work, its time to look for another vendor. _________________________________________________________________________ __ / ) Gene H. Olson uunet!digibd!gene / __ _ __ _ Senior Staff Engineer (__/ _(/_//_(/_ DigiBoard, Inc. gene@digibd.com