Date: Sun, 25 Jun 1995 13:18:05 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: dennis@et.htp.com (dennis) Cc: phk@freefall.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: FreeBSD as a router Message-ID: <199506251818.NAA28203@brasil.moneng.mei.com> 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
> >Recv Frame 1 Recv Frame 2 Recv Frame 3 > >------------> ------------> ------------> > > Send Frame 1 Send Frame 2 ... > > > > 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. > > This is the same concept that applies more importantly to WAN communications > and the reason for the existance of cell relay to produce higher switching > thoughputs. Cells are smaller (53 octets or something for ATM) and > forwarding can begin as soon as the first cell is full. This is also exactly > why router based networks are slower than switched-protocol networks, > because routers lose a transmission time at every hop (although the big guys > are starting to do cell switching). This is also why when you chose an > internet provider make sure that your provider has high-speed connectivity, > because a 56k line to a router with a 56k connection only yields 28k to the > "real" net. Bull. You are taking a worst case scenario and forgetting that the average case is not worst case. You obviously have a good grasp of the fact that there is additional latency in delivery introduced by a router. This much is true! And when you shoot a single packet to a remote host, and it replies back to you, there is a further delay in delivery of the response - and it increases for each and every router between A and B. That's a very important concept to understand when dealing with "synchronous" IP protocols (think: NFS) because it effectively slows you down for obvious reasons. In the worst case, you end up with a scenario like you paint: Recv Frame 1 Recv Frame 2 ------------> ------------> ------------> Send Frame 1 ... But ONLY because of the send-acknowledge protocol that NFS uses.. However, TCP was designed with this fact in mind, and starts sending more frames before any acknowledgement of previous frames is received. (Good UDP based protocols can also take advantage of it, using the same technique). Recv Frame 1 Recv Frame 2 Recv Frame 3 ------------> ------------> ------------> Send Frame 1 Send Frame 2 ... There is *still* an additional delay caused for *each* packet, but in the bigger picture, this does not limit either wire to half the bandwidth. This is sort of like an argument I once heard in a CS class, where the lecturer was dealing with O() concepts. There are algorithms which may take O(1) to O(n) on a per-instance basis, but when amortized over many uses, ends up averaging O(log(n)) or some other in-between value. You are essentially arguing that because there is an O(n) case, *every* case is an O(n) case, even though in reality it ends up being much better than that for most uses. Definitely for average usage (ftp, www, telnet, etc.), you are not limited in the manner you are suggesting. On the 56k/56k thing: You are likely to get your 28k, but for an entirely different reason: if you run a 56k to a provider with a 56k, you are *sharing bandwidth*. If you were not, the provider would be charging you his costs for his 56k PLUS his operational expenses, and it would be cheaper for you to bypass the provider entirely and go to his source. Instead, you are sharing bandwidth with (potentially many other) people, all of whom are beating on the provider's 56k... :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506251818.NAA28203>