🚀 go-pugleaf

In article <71126@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>It is true that if you set TRT=8, then the worst case latency goes down
>by about 165/8.  This means that with the maximal 500 stations, you have
>around 10 seconds of worst case latency.  I work for a graphics workstation
>company and hear from  customers who build simulators, and many of those
>customers worry about keeping screens up to date and synchronized.  Latency
>guarantees for them of seconds are funny, not just useless.  There might be
>applications that coud use guaranteed latencies of large parts of seconds,
>and I would like to hear about them.  Only they would care about the FDDI
>token ring guanrantees.

Right -- but Raj also argues eloquently that using 500 stations is a bad
idea.  More stations implies higher bit error rates, and bridges work
quite well.

He computes the max delay and average efficiency for 500 stations with
TTRT at 8ms as 8 secs and 75%.  But if, as he suggests, you keep
yourself to a max of about 100 stations, max access delay is about
0.8 seconds and 86%.  (If you are willing to get smaller, down to
around 10 stations, its 0.15 and 99.5%).

Now I admit (as you point out) 0.8 seconds still ain't great for
synchronization -- but it is close.  We're going to have to worry about
synchronization delays of several 100s of milliseconds in gigabit wide
area networks anyway.  And making nets smaller and using bridges can
help.

I also agree with your point that we're worry about extremes.  A
distribution of how likely we are to hit, say 0.8 seconds would be
of interest, but that requires reasonable traffic models (which is
always hard to do...).

Craig Partridge