Xref: utzoo comp.dcom.lans:5673 comp.protocols.tcp-ip:12573
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!sgi!rpw3@rigden.wpd.sgi.com
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Token Ring frame sizes?
Message-ID: <67003@sgi.sgi.com>
Date: 16 Aug 90 07:11:49 GMT
References: <38470004@hpindwa.HP.COM> <1990Aug15.213146.2836@ibmpa>
Sender: rpw3@rigden.wpd.sgi.com
Reply-To: rpw3@sgi.com (Rob Warnock)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 28

In article <1990Aug15.213146.2836@ibmpa> brunner@ibmsupt.UUCP () writes:
+---------------
| You can expect to see implementations which hold a token for up to 10ms
| in the blind pursuit of big frames on what are essentially propriatary
| networks.
+---------------

10ms? That's easy. Any big, fast NFS server with lots of clients very well
may have more than 10ms (125 Kbytes, on FDDI) of data ready to go when the
token arrives.

And frame size has nothing to do with it; all of the packets might be small.
On FDDI any station is permitted to send multiple packets per token, up to
the limits of T_Opr (roughly speaking).


-Rob

p.s. The default T_Opr -- max "operational" time per token rotation -- for
FDDI is 165ms, which is just over 2 Mbytes. [O.k., it;s really T_Max, but in
the absence of any real-time guys, the negotiated T_Opr will just be T_Max.]


-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311