Date: Sun, 25 Jun 1995 19:55:33 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: dennis@et.htp.com (dennis) Cc: phk@freefall.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: FreeBSD as a router Message-ID: <199506251755.TAA18696@uriah.heep.sax.de> In-Reply-To: <199506251650.MAA26983@mail.htp.com> from "dennis" at Jun 25, 95 12:50:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As dennis wrote: > > It has nothing to do with receiving while transmitting, it has to do with > physical science. > > Box A ----> Box B (the Ethernet Router) -----> Box C > > I transmit a frame from Box A to Box B. For simplicity say it takes 100 > microseconds to get to point B at 10mbs. I now need to re-transmit the > frame to get it to Box C. It takes ANOTHER 100 microseconds to get it to Box > C (Assuming no latency). To get from Box A to Box C with a non-specialized > controller takes 200 microseconds, or 1/2 the single medium's max throughput. If your theory were true, no FreeBSD version would never even have arrived here. We've seen propagation delays in the range of 20 seconds to ftp.freebsd.org. The point is that the TCP protocol allows a `window' of pre-sent packets without acknowledge, so it remains `streaming'. (Btw., even UUCP-g did this, for very the same reason.) This way, the propagation delays will only add up as delays, but do not significantly lower the bandwidth. The error in your thinking is that, even though the packet needed 200 µs from A to C, the next packet at C will still arrive after another 100 µs, even though it took 200 µs again to come down from A. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506251755.TAA18696>