bdb@becker.UUCP (Bruce D. Becker) (05/17/91)
In article <1991May15.002922.20778@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: | |Yeah, but I've already pointed out to him that saying "my HFC works with |UUCP transfers over a TrailBlazer PEP connection" doesn't prove anything. |[...] |The modems provide end-to-end flow control through the *uucp protocol* |rather than hardware handshaking. It matters not whether hardware flow |control is perfect or broken - the modems don't use it when they're |spoofing uucp. |[...] |My back-of-the-envelope calculations came up with 1,000 cps, but it's still |the same conclusion - 24 megabytes in 7 hours is much closer to 9600 bps |than 19200... I run a TB+ at 19200 without flow control or locked interface speed, and with modem compression turned off. The maximum throughput I seem to get over a clean line is nearer to 1200 bytes/sec, but this is hardly ever acheived due to line noise and system loading. As far as I can see, HFC is just a big source of problems and should be avoided if at all possible. Even if it works correctly (which for many versions of the O/S it doesn't), it's very susceptible to "skid" at high baud rates. This means that the time between the detection of overrun and the assertion of the appropriate control line can be long enough under some load conditions that characters are still dropped. HFC isn't actually useful for UUCP transfers, and wreaks havoc with interactive users because the modem's buffering system has no concept of interrupt characters (like "^C") needing special handling. I've run the serial port (actually tty002, but that oughtn't to be a real difference) at 19200 with a direct connection to a faster system (with respect to serial speed), using a protocol which sends a 1K block and gets an ACK in response. The fastest I can send stuff is about 1300 bytes/sec, which I take to be the maximum rate at which characters can be delivered out the serial port (probably interrupt service overhead). No flow control is in effect during these transfers, yet the error rate is fairly low (consistent with an overlong cable in an electrically noisy environment)... -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.
mhw@fithp (Marc Weinstein) (05/19/91)
From article <101141@becker.UUCP>, by bdb@becker.UUCP (Bruce D. Becker): > In article <1991May15.002922.20778@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes: > > As far as I can see, HFC is just a big source of > problems and should be avoided if at all possible. > Even if it works correctly (which for many versions > of the O/S it doesn't), it's very susceptible to > "skid" at high baud rates. This means that the > time between the detection of overrun and the > assertion of the appropriate control line can > be long enough under some load conditions that > characters are still dropped. We've found this is true at 19200, but not so at 9600. I've had *lots* of activity on the PC and can't seem to cause a file transfer to fail. > HFC isn't actually > useful for UUCP transfers, and wreaks havoc with > interactive users because the modem's buffering > system has no concept of interrupt characters > (like "^C") needing special handling. Well, sort of...The place where HFC on the UNIXPC really works is when your PC can send chars out faster than the remote modem can handle them. For instance, if either the DCE-to-DCE speed or the DCE-to-DTE speed on the far end are less than the host DTE-to-DCE speed, then the modems will apply HFC and the UNIXPC will properly halt data transmission. HFC does NOT seem to work for handling overflow on incoming PC ports. > I've run the serial port (actually tty002, but > that oughtn't to be a real difference) at 19200 > with a direct connection to a faster system > (with respect to serial speed), using a protocol > which sends a 1K block and gets an ACK in > response. The fastest I can send stuff is about > 1300 bytes/sec, which I take to be the maximum > rate at which characters can be delivered out > the serial port (probably interrupt service > overhead). Yeah - we'd like to try this, but we only support the 'g' protocol in UUCP. Is this a UUCP connection you're talking about, or a UMODEM-type transfer? Marc -- Marc Weinstein {simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL -or- {internet host}!linac.fnal.gov!fithp!mhw
bdb@becker.UUCP (Bruce D. Becker) (05/21/91)
In article <1991May18.170853.2649@fithp> mhw@fithp (Marc Weinstein) writes: |From article <101141@becker.UUCP>, by bdb@becker.UUCP (Bruce D. Becker): |[...] |> HFC isn't actually |> useful for UUCP transfers, and wreaks havoc with |> interactive users because the modem's buffering |> system has no concept of interrupt characters |> (like "^C") needing special handling. | |Well, sort of...The place where HFC on the UNIXPC really works is when your |PC can send chars out faster than the remote modem can handle them. For |instance, if either the DCE-to-DCE speed or the DCE-to-DTE speed on the far |end are less than the host DTE-to-DCE speed, then the modems will apply |HFC and the UNIXPC will properly halt data transmission. HFC does NOT |seem to work for handling overflow on incoming PC ports. I'm having a hard time understanding why speed changes are necessary. For most things compression is irrelevant, or they are done in the host as in news batches or uucp files. Doing compression in the modem seems wasteful of resources due to the fact that uncompressed data gets punped thru the serial interface with an interrupt service routine invocation for each character! Naturally on a little beastie like the 3B1 this is pretty ferocious CPU consumption at high baud rates. Better to have direct end-to-end transfers at the same speed, with no buffering in the modems. |> I've run the serial port (actually tty002, but |> that oughtn't to be a real difference) at 19200 |> with a direct connection to a faster system |> (with respect to serial speed), using a protocol |> which sends a 1K block and gets an ACK in |> response. The fastest I can send stuff is about |> 1300 bytes/sec, which I take to be the maximum |> rate at which characters can be delivered out |> the serial port (probably interrupt service |> overhead). | |Yeah - we'd like to try this, but we only support the 'g' protocol in |UUCP. Is this a UUCP connection you're talking about, or a UMODEM-type |transfer? Both, actually (UUCP 'g'). This is talking to an Amiga running Handshake terminal emulator (very fast), and Dillon UUCP 1.06. -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.
mhw@fithp (Marc Weinstein) (05/22/91)
From article <103431@becker.UUCP>, by bdb@becker.UUCP (Bruce D. Becker): > In article <1991May18.170853.2649@fithp> mhw@fithp (Marc Weinstein) writes: > |From article <101141@becker.UUCP>, by bdb@becker.UUCP (Bruce D. Becker): > | > |Well, sort of...The place where HFC on the UNIXPC really works is when your > |PC can send chars out faster than the remote modem can handle them. For > |instance, if either the DCE-to-DCE speed or the DCE-to-DTE speed on the far > |end are less than the host DTE-to-DCE speed, then the modems will apply > |HFC and the UNIXPC will properly halt data transmission. HFC does NOT > |seem to work for handling overflow on incoming PC ports. > > I'm having a hard time understanding why > speed changes are necessary. Most modems now support the ability to nail your port rate to something (9600 or 19200) and vary the modem-to-modem rate to suit the remote system. This makes administration much easier - one rate in gettydefs, one rate in your Systems file. > For most > things compression is irrelevant, or they > are done in the host as in news batches > or uucp files. Doing compression in the > modem seems wasteful of resources due > to the fact that uncompressed data gets > pumped thru the serial interface with > an interrupt service routine invocation > for each character! Hmmm - don't understand the logic here. If I want to send a file to someone, and I know my modem will compress the file anyway, then I don't have to bother with compressing the file before the fact. Less wory, less bother. > Naturally on a little beastie like the 3B1 > this is pretty ferocious CPU consumption > at high baud rates. Better to have direct > end-to-end transfers at the same speed, > with no buffering in the modems. True, if both ends use the same speed. -- Marc Weinstein {simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL -or- {internet host}!linac.fnal.gov!fithp!mhw
res@colnet.uucp (Rob Stampfli) (05/24/91)
>Well, sort of...The place where HFC on the UNIXPC really works is when your >PC can send chars out faster than the remote modem can handle them. For >instance, if either the DCE-to-DCE speed or the DCE-to-DTE speed on the far >end are less than the host DTE-to-DCE speed, then the modems will apply >HFC and the UNIXPC will properly halt data transmission. HFC does NOT >seem to work for handling overflow on incoming PC ports. The above comment seems to have the support of a number of people who have played around with hardware flow control. I was just perusing "Managing UUCP and Usenet" by O'Reilly & Associates, and here is what they have to say about this (brackets mine): "In the RS-232 standard, [ hardware ] flow control is defined only for half-duplex connections -- that is, for connections in which data can be transmitted only in one direction at a time. However, the standard has been adapted, de-facto, for full-duplex communications as well. "In the half-duplex standard, the DTE [ computer ] asserts RTS when it wants to send data. The DCE [ modem ] replies with CTS when it is ready, and the DTE begins sending data. Unless RTS and CTS are both asserted, only the DCE can send data. "However, in the full-duplex variations, RTS/CTS is used as a kind of throttle. The signals have the opposite meanings than they do for half-duplex communications. "When a DTE device is able to accept data, it asserts pin 4, Request to Send. If the DCE is ready to accept data, it asserts pin 5, Clear to Send. If the voltage on RTS or CTS drops at any time, this tells the sending system that the receiver is not ready for more data... This seems to agree with what the poster says above. Could it be that AT&T implemented the half-duplex standard, which deals only with DTE to DCE flow control? I have always assumed HFC worked like what was described as the full-duplex variation, but maybe this is not the case. It would be interesting to hear from someone more well versed in the implementation of the standards. PS: The short excerpt from "Managing UUCP and Usenet" is typical of the calibre of information contained in this publication. I would recommend it highly to anyone owning a Unix-PC. It is indeed the UUCP "bible". -- Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh
bruce@balilly (Bruce Lilly) (05/25/91)
In article <1991May24.054753.28804@colnet.uucp> res@colnet.uucp (Rob Stampfli) writes: > > "However, in the full-duplex variations, RTS/CTS is used as a kind of > throttle. The signals have the opposite meanings than they do for > half-duplex communications. > > "When a DTE device is able to accept data, it asserts pin 4, Request to > Send. If the DCE is ready to accept data, it asserts pin 5, Clear to > Send. If the voltage on RTS or CTS drops at any time, this tells the > sending system that the receiver is not ready for more data... > >This seems to agree with what the poster says above. Could it be that >AT&T implemented the half-duplex standard, which deals only with DTE to DCE >flow control? I have always assumed HFC worked like what was described as >the full-duplex variation, but maybe this is not the case. It would be >interesting to hear from someone more well versed in the implementation >of the standards. HFC in the 3b1 (at least with 3.51m) works as described above (full-duplex). There is, however a TCSRTS ioctl which only works in half-duplex. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM