lauren@RAND-UNIX.arpa (08/02/86)
Actually, the higher speeds reported with the ethernet and direct X.25 connection protocols in X.25/ethernet environments is not so much a result of the "error-free" end-to-end (computer-to-computer) connection but the result of the end-to-end hardware flow control that must be present on such circuits. The combination of X.25 and/or ethernet environments, full end-to-end error correction AND hardware-based end-to-end flow control allows for running the connection at higher speeds than would otherwise be possible in the X.25 and ethernet environments, but error-correction alone is not the only factor--flow control is critical. --Lauren--
guy@sun.uucp (Guy Harris) (08/03/86)
> Actually, the higher speeds reported with the ethernet and direct > X.25 connection protocols in X.25/ethernet environments > is not so much a result of the "error-free" end-to-end (computer-to- > computer) connection but the result of the end-to-end hardware flow > control that must be present on such circuits. What hardware flow control? An Ethernet interface doesn't know whether anybody's picking up the packets you're sending; there's no end-to-end flow control in Ethernet. The "e" protocol runs over protocols like TCP that *do* provide end-to-end flow control; that's usually not done in the hardware, though. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
jhc@mtune.UUCP (Jonathan Clark) (08/04/86)
Lauren Weinstein @ Vortex: >Actually, the higher speeds reported with the ethernet and direct >X.25 connection protocols in X.25/ethernet environments >is not so much a result of the "error-free" end-to-end (computer-to- >computer) connection but the result of the end-to-end hardware flow >control that must be present on such circuits. Guy Harris @ Sun: >What hardware flow control? An Ethernet interface doesn't know whether >anybody's picking up the packets you're sending; there's no end-to-end flow >control in Ethernet. The "e" protocol runs over protocols like TCP that >*do* provide end-to-end flow control; that's usually not done in the >hardware, though. Both authorities are correct but there is some terminology confusion. Lauren doesn't mean flow control in Guy's sense - he means 'resource control'. If I write a 4K block down a Ethernet then the remote end is always able to accept it (expect in rare circumstances) so the data doesn't have to hang around waiting for the resources to be made available. The cost of grabbing a 4K buffer when asked, as well as the protocol overhead of saying 'there is 4K coming your way - let me know when you're ready' sounds rather large. I can well believe that that and the n (32?) inter-packet gaps (and the buffer copies saved) are most of the reason for the speedup. Lauren also doesn't mean 'hardware flow control' in Guy's sense - he means 'out-of-band flow control'. In the cases discussed here the flow control is combined with the rest of the protocol, so comes free. -- Jonathan Clark [NAC,attmail]!mtune!jhc My walk has become rather more silly lately.