From owner-freebsd-hackers Sun Jun 25 11:15:11 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA00297 for hackers-outgoing; Sun, 25 Jun 1995 11:15:11 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA00288 for ; Sun, 25 Jun 1995 11:15:07 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA16699; Sun, 25 Jun 1995 20:15:04 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA03517; Sun, 25 Jun 1995 20:15:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id TAA18696; Sun, 25 Jun 1995 19:55:34 +0200 From: J Wunsch Message-Id: <199506251755.TAA18696@uriah.heep.sax.de> Subject: Re: FreeBSD as a router To: dennis@et.htp.com (dennis) Date: Sun, 25 Jun 1995 19:55:33 +0200 (MET DST) Cc: phk@freefall.cdrom.com, freebsd-hackers@freebsd.org In-Reply-To: <199506251650.MAA26983@mail.htp.com> from "dennis" at Jun 25, 95 12:50:53 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1354 Sender: hackers-owner@freebsd.org Precedence: bulk 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. ;-)