From: shah@angelo.amd.com (Amit Shah)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: TTRT
Keywords: wrong
Date: 31 Aug 92 02:37:59 GMT
Organization: Advanced Micro Devices, Santa Clara, CA

In article <p7lne2k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>I've been fumbling with high speed, single virtual circuit TCP over
>FDDI lately.  Among my problems has been giving the receiver a chance
>to send ACK's without letting the transmitter out of the groove.  To
>solve that problem, I've been thinking about the general situation.
>
>Several FDDI vendors have decided to make all of their equipment have a
>default T_Req of from 4 to 8 milliseconds.  Since the target token
>rotation time is the smallest of all of the values CLAIM'ed by all
>stations on the ring, many and perhaps most multi-vendor rings in the
>world have TTRT's of just over 5 milliseconds.  (5 ms because that is
>the value chosen by Raj Jain's employer.  Raj Jain's analysis is the
>excuse people use for forcing their customers to use such low TTRT's.)
>
>Could someone remind me of why that does not waste as much as 30% of
>the ring throughput?
>
I cannot and yes I too have observed that people have chosen to really
go low on the TTRT value.  While 5 ms is a good value for certain applications
it is certainly not good for most burst-mode applications, e.g. file-transfers.

We have just recently concluded a study of applying various mixtures of traffic
when operating the FDDI network in asynchronous, synchronous and mixed 
async+sync modes.  I found that 
for the pure data traffic case in an asynchronous only network (most FDDI nets
today), a TTRT of 24 ms was significantly better than a TTRT of 8 ms.

The instances where 8 ms was better was in a mixed traffic case with voice/video
restricting the max. access delays.  In a true integrated environment where
the requirements of interactive, file transfer, voice, video and imaging had to
be met, I found that 16 ms was the optimum value.

>Imagine a pair of TCP hosts with TCP-Large-Windows trying to move data
>at maximum speed from one to the other.  Assume the ring latency is a
>little high at 1 ms, because there is a lot of cable and 200
>concentrator ports and hosts on the ring (many concentrators increase
>the ring latency by 2*(N+1) microseconds, where N=number of physically
>present ports, whether in use or not).  Maybe there are not 200 ports,
>but the ring has a 90 kilometer excursion to another town using
>single mode fiber, as has been done in existing, production rings.
>(ANSI X3.139-1987 allows D_Max to be 1.617 ms.)
>
>The TCP transmitter will have to release the token every 5 ms or
>60-70KBytes.  The token will have to go around twice before the
>transmitter can resume sending.  Those two rotations will consume 2 ms,
>or 29% of the total available bandwidth, limiting the TCP virtual
>circuit to less than 70Mbit/sec.  I'll admit it is not entirely wasted,
>because the TCP receiver might use about 10 microseconds or 0.5% to
>send an ACK on the 2nd token rotation, and any other stations might
>each use similarly trivial amounts to send their 30-second NIF's.
>
>If the TTRT were only 20 ms, the cost of token rotations in this
>hypothetical ring would go down to 9%.  At the ANSI standard default,
>the cost would be about 1%, and TCP would get around 97Mbit/sec.
>
>
>Vernon Schryver,  vjs@sgi.com


--
Amit Shah
Sys. Engg. & Prod. Planning Engineer		Ph.:(408)987 2479
High Speed Networking   			Fax:(408)987 2814
901 Thompson Place, M/S 70			email:amit.shah@amd.com