From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.misc
Subject: Re: Token Ring vs. Ethernet
Date: 20 Nov 92 17:19:13 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Nov20.003409.24882@engage.pko.dec.com>, moroney@ramblr.enet.dec.com writes:
> In article <1992Nov18.172211.10451@mccc.edu>, pjh@mccc.edu (P. J. Holsberg) writes:
> > If you were starting from scratch (in a college) and had to network 5
> > rooms of 30 MS-DOS/Windows PCs (using multiple servers), would you use
> > Ethernet or Token Ring, and why?
> > He contends that Token Ring is the answer to the question in the first
> > paragraph in that it is now about the same cost as Ethernet, has larger
>                                                                ----------
> > packets and is thus more efficient, and has about 60% higher throughput.
>   ----------------------------------
> 
> Don't let the "has larger packets" argument sway you.  In the worst case
> with Ethernet (802E packets) you have 1492 data bytes available (1514 byte
> packet -12 src/dst bytes -2 length -3 DSAP/SSAP/UI -5 protocol) in a
> total of 1538 byte times (1514 packet+4 CRC+8 preamble+12 IPG), which means
> there's about a 3% overhead.  So even if you had a network which allowed
> infinitely sized packets, you save 3% at most.  Most of the time you won't
>even have that as most of the time you won't be sending maximal-length packets


I must disagree with this.  I guess I'm just contrary and picky.

If your station is running at its limits on the protocols I know about,
(TCP, UDP, IP, competators, predecessors, and some recent would-be
successors), the speed of your station is roughly proportional to the
number of packets it handles.  In other words, if you can somehow
double the packet size, a saturated system will move a lot more bytes
per second.  The speed up is not quite linear, but it is large.

I have seen this effect experimentally on more than one combination of
hardware and protocol.

This effect can be seen in performance curves, where you vary the
packet size from very small to maximal.  It is common to see a
throughput-vs.-packetsize curve that is very steep for very small
packets and then flattens out as the machine bumps up against the
medium speed limit.  This effect is probably why the (honest) router
guys measure their boxes in minimum-sized packets switched per second.

If you think about it, this effect is unsurprising.  The cost of
handling a packet (on a station, not a bridge or router) consists of
fixed costs including interrupt handling and (de)mux'ing, and of
variable costs proportional to packet size including byte copying and
checksumming.  Eventually, as you reduce the packet size, the fixed,
per-packet costs dominate.

However, no modern computer should be significantly loaded by up to
2MByte/sec in packets from 1KByte to 8KB.

It should also be noted that the large token ring packet size is not
entirely a given.  I've been given to understand that it is not like
the universal and constant 1500 ethernet size, that bridges and other
non-protocol, non-application effects reduce the median token ring
packet size.


Vernon Schryver,  vjs@sgi.com