Conference 7.286::fddi

"sync" in FDDI has a meaning totally unrelated to its normal meaning in
communications!

Normally it relates to the way bytes are framed: in async each byte is
framed separately by start and stop bits; in sync the bytes are not
separately framed, but instead byte framing is done at start of packet and
maintained thereafter.

In FDDI, as in all LANs, byte framing is done at the packet level, so it
is "sync" in the traditional sense.

"async" and "sync" as the term is used in the FDDI standard refers to different
rules for scheduling frame transmission.  FDDI is a "timed token" datalink,
similar to 802.4 (but different from 802.5, incidentally...).

"Timed token" means that there is a timer, called Target Token Rotation Timer
(TTRT) which specifies the longest allowed time between successive passes
of the token around the ring.  A typical value for TTRT is 8 ms.

Each station maintains a timer "Token Rotation Timer" (TRT) which measures
elapsed time since the token was last seen there.  Every time the token
comes by, this timer is reset.  

When I want to transmit a frame in "async" mode, I wait for the token to
arrive.  When it does, I look at TRT.  If TRT (the time between the previous
token arrival and this one) is less than TTRT (the target rotation time)
then I am allowed to transmit the frame.  If I have additional frames
to transmit, I am allowed to transmit for TTRT-TRT.  (If the time is up
halfway through a frame, I finish transmitting that frame.)  When time
is up, I have to stop transmitting data; the token is then released.

For example, if TTRT is 8 ms, and the token comes to me 1 ms since I last
saw it, I'm allowed to transmit for up to 7 ms.

If TRT is >= TTRT (i.e., it took longer for the token to come around
than the target) the token is "late" and I cannot transmit this time around.
For example, this can happen if the station(s) upstream have just transmitted
a lot of data and thereby used up the entire time allotment.

By the way, if you carefully chart how this works for a case of N nodes each
of which have "infinite" amounts of data to transmit, you'll see that each
one will transmit TTRT worth of data every N token rotations, and the
nodes all transmit in rotation.  This means (a) the system is fair, (b) delay
is bounded, and (c) the worst case delay is N times TTRT.  (Under "normal"
loads, the delays are very small, in the order of a ms or so.  You don't
even approach the worst case until you get to VERY extreme situations...)

So you see that async service allows you to take your fair share of the
available capacity whenever  you want it, and whenever you don't want it,
it's available to others.  Typical delays are low but worst case delay can
be significant.  For almost all applications, async service is the one
of choice.

For a few applications, you need guaranteed low delay, and you have a fairly
steady (and modest) flow of data.  In those cases, "sync" service may be
the one to use.

If I want to transmit a frame in "sync" mode, I simply wait for the token
to arrive, then I transmit the frame.  The difference here is that I don't
have to check for "late" token: whether it's later or not, I can transmit.

Obviously, if lots of people all transmit lots of stuff in sync mode on the
same token rotation, the token will take a very long time to go around.
This isn't allowed; the token MUST come around in 2*TTRT or it is assumed to
have been lost and the ring is reset.  (If this rule didn't exist then you'd
lose the advantage of "timed token" -- you would no longer have any time
bounds on latency.)

This means that, for a given TTRT value, the total amount of sync mode traffic
that can be sent per rotation is limited to somewhat less than TTRT.
(The token must come around in 2*TTRT; async mode can use up TRT plus the
"overrun" time of one packet; and you need some slack for propagation time
around the ring and such.)  Each station that needs to use sync mode service
is assigned -- via network management -- a "sync bandwidth allocation"
which says how much it is allowed to transmit each time the token comes
around.  Management must ensure that the sum of the individual allocations
is less than the allowed total amount, i.e., less than TTRT - whatever.
Clearly you would allocate sync bandwidth to a station to match the requirements
of its application closely: you need to allocate enough but you would want
to avoid allocating more than is needed.

Note that sync service allows transmission on EVERY token arrival, so the
worst case delay is equal to the worst case token rotation time, i.e. 2*TTRT.
Compare that with the worst case for async: N*TTRT.  (Under other than
worst case loads, the typical delays are roughly the same.)  The price
you pay for this is the requirement to preallocate sync bandwidth to the
stations that need it.  A nice property of sync service is that any unused
part of your allotment is available to the other nodes on the ring.
This makes it ideal for applications which need very low delay but have
bandwidth demands that fluctuate (so long as the maximum demand is well defined
and low enough to allow you to allocate it).

Selection of sync or async transmission mode is done on a per-packet basis.
The implementation of the transmission rules I described is part of the MAC
chip.

	paul

.1 provides an excellent description of sync and async modes of operation.

A follow on question I have, is what to our own FDDI products implement?  Can
they do either sync or async, or are they restricted to async operation?

Additionally, if they can implement sync operation, how is the "sync bandwidth"
allocated to each station, as there doesn't appear to be any means of doing
this vis DECelms for example.

For all practical purposes, you're limited to asynch service.

If you dig deep, you'll find this is not quite true.  The hardware is quite
willing to let you send sync frames.  (You may not get the driver to cooperate,
though, depending on the driver.)  Two major things are missing which would
be needed to have "real" sync service support:

1. No enforcement of sync bandwidth allocation.  You can in fact do it, by
   keeping track of it yourself and setting appropriate flags ("release the
   token after this frame") at the right points in the stream of frames,
   but that's not really good enough for general use.
2. Only a single transmit queue exists, so if you have both sync and async
   frames waiting to be transmitted, a sync frame may have to wait for a
   preceding async frame, even though the frame transmission rules allow the
   sync frames to be transmitted "right now".
   If you have no async traffic (except the occasional control message from
   SMT) then this isn't a major issue, but again that's probably not
   realistic for most cases.

Incidentally, note that there are NO limitations or issues with RECEIVING
sync traffic.

The two items I mentioned are likely to be fixed at some point, but that
won't be soon.  (Item 2 has a rather significant effect on the design of
the hardware...)

	paul

  My highly technical customer wants to do "real-time" data collection on FDDI.
  If He wrote his own device driver, you're saying that he would have enough
  control over his node hardware to generate a more or less controlled-latency
  stream of packets using our FDDI products; say.. the 700 and DEMFA?  Let's 
  assume here were talking of an FDDI ring consisting solely of either DEC-
  station/risc or VAX processors and perhaps VME-based instrumentation devices.
  In other words, we're not concerned with fairness here; we're more interested
  in being able to mechanize effectively a sync channel or multiple channels for
  the purpose of real-time data collection. This ring would be dedicated to
  lab instrumentation.

  Jim Timmerman

I'm not positive about the DEMFA (though I'm almost certain the answer is
YES).  For the DEFZA, the answer is definitely yes.

That would give you definite control over latency (I wouldn't call it "more
or less"); the latency bound will be TTRT*2.  TTRT is 8 ms by default, given
our standard parameters, and can be as low as 4 ms.

Note that async service ALSO gives you a latency bound... but a larger one.
The upper bound there is TTRT*N, where N is the number of stations.  (More
precisely, the number of stations that simultaneously want to transmit.)
So for small enough N, or large enough permissible latency bound, you may
get the effect you want simply by using the standard product in a well-
controlled configuration.

	paul

    Make sure your customer knows that, if the driver sends a mix
    of sync and async frames, the sync frames could get "stuck" behind
    async frames...and you'd get inconsistent latencies.  If the driver is
    marking ALL frames to be transmitted as "sync", then it won't have that
    problem.
    
    But judicious use of async (as suggested in .5) might give good results
    with less work.
    
    Maurene

Yes....  Given hardware with a single transmit queue (which is the case
for all our current adapters) we don't have really useable sync service
support.  In general it's best to try to avoid it, and often a network
can be set up to meet requirements even with async service.  

If you have a really special case where that just isn't good enough, then
it IS possible to use sync service but you MUST then send ONLY sync type
data through that adapter.

	paul

  The answers are most helpful.  Thanks all .  Boeing will be dedicating an
  FDDI ring to VME-based simulators and 'real-time' workstation engines to
  interact with the simulators.  They will have at most around 15 stations
  on the ring and will probably only be interacting with one simulator at a
  time.  The issue here is simply being able to pump packets into the
  interface in as synchronous a way as possible.  I believe what I'm hearing
  indicates that they will be able to do this without any problem from the
  DEC supplied driver interface.  I was concerned that the customer would
  have to write their own driver in order to flip the bits required to
  transmit in synchronous mode.  I'm still interested in the mechanism for
  doing this.  Does the driver programming interface allow a flag to be
  placed in the packet que to indicate whether to transmit sync or async?

  Jim Timmerman

I don't believe the driver gives you the choice; if you want sync service
you have to modify the driver.

You said "...as synchronous a way as possible."  Watch out for the term
"synchronous service"; I think you may be reacting to what the name seems
to promise rather than what it actually delivers.

In most cases, synchronous service is LESS desirable than normal (async)
service.  Reasons:

1. You have to allocate bandwidth in advance -- currently this is a 
   manual process.
2. Since the sum of all the allocations has to be less than (approximately)
   TTRT, you are allowed LESS bandwidth than you could have gotten under
   most conditions with normal async service.

The benefit you get from this is:

If one or more nodes on the ring are putting such a high load on that they
together consume TTRT worth of time for a given token rotation, then
sync service would give you a chance to transmit when async makes you wait
for the next rotation.

This is actually quite an unlikely scenario.  If only one station at a time
transmits, then you WILL NOT get benefit from sync service.  (Indeed, you
will lose out, see above.)  If other stations are also transmitting, but the
sum of the instantaneous loads consumes less than TTRT (for example, 10 nodes
each transmitting one max sized packet at the exact same instant takes about
3 ms, well below TTRT) then you WILL NOT get benefit from sync service.
If some number of nodes put on a big instantaneous load, but the total
time it takes to transmit that is less than the permitted max real-time
delay, then you WILL NOT get a USEFUL benefit from sync service.  (In that
last case, you will get the transmission out faster, but either way you 
would have met the permitted delay numbers.)

In short, "...as synchronous a way as possible" is not a meaningful
statement.  It sounds like a marketing phrase that has no technical
content.  A meaningful requirement has a specific delay bound in it, under
specific conditions of load from each of the nodes on the ring.  Given
such a statement, you can decide which service (if any) is adequate.
Without one, you can't do that.  But the best guess I can make from the
rough description you gave is that ordinary async service is the best choice.

	paul

Let's take a simple example (Paul, correct me if I've got it wrong).  If only
one node wants to transmit, synchronous transmission just adds overhead.

Let's say that you have 8 nodes and TTRT=8MS.  You give each node 1MS for
synchronous transmission .  Only one node wants to transmit,  and it can keep
the line busy for as long as it is permitted.

Now, the token is going around and only 1 node wants to transmit.  It can
transmit synchronous for only 1MS and then it must give up the token.  The
token goes around fast, and the same station gets it again.  Again, it can
transmit sync for 1MS and then it must give up the token.  And so on.

Same situation, but transmission is async:  The node that wants to transmit can
transmit 8MS (minus delays) before it gives up the token.  Then the token goes
around fast, and the node can transmit for another 8MS.

(If all the nodes don't need sync, you could give each one that DOES need 
it more bandwidth (e.g. 2MS to each of 4 stations), but that doesn't
change the basic scenario).

Now, if 2 nodes want to transmit (say one workstation and one simulator are
exchanging a lot of data simultaneously without waiting for each other), 
they play pingpong with the token.  For sync, the pingpong is every 1MS, 
and with async it's every 8MS.  Again, there's no advantage for sync.  If you
MUST get SOMETHING out faster than every 8MS, you could use async with a
reduced TTRT...and save tinkering with the driver.

When more than two nodes want to transmit at once, and you need GUARANTEED
transmission every 2TTRT, then sync starts to show some advantage in some
circumstances.

Hope I've got this straight,
Maurene

Exactly right.

Here's a way to summarize it all.  Suppose you have a ring of some number
of stations; out of those, there are N that are offering an "infinite load".
("infinite load" means that each will transmit as much as the rules permit,
rather than letting the token go early.)

In that scenario, the worst-case transmit delay using async service is
N * TTRT; for sync service it is 2 * TTRT.

So you can see very clearly that sync service is pointless whenever N is 2 or
less.  When N is greater than 2, it makes a difference.  Whether that
difference is a USEFUL difference depends on what the acceptable worst
case latency is.  Here there are 3 cases:

1. Required delay < 2 * TTRT.
	This means neither service will work.  Reduce TTRT.  If you can't
	make it small enough (for example, required delay < 8 ms) then
	this application CANNOT work on FDDI under "infinite load".
	Pick a different LAN, or control your load such that no node ever
	offers an "infinite load".  Be prepared to do detailed simulation...

2. Required delay >= 2 * TTRT, but < N * TTRT.
	In this case sync service will work and async will not.

3. Required delay >= N * TTRT.
	In this case either service will work.  Async service will be
	easier to apply, require less management, and be more efficient.

    paul

These notes have proven most helpful in understanding what Sync FDDI is. 

However, I'm not clear on whether or not an entire FDDI ring must be 
dedicated to sync or async service or whether some stations in a ring can 
send sync, and some async. If a ring must be set up to be one way or another, 
what happens if you bridge two rings, one sync and one async (ie,  with a
GIGAswitch)?

I'm setting up our FDDI demo at Interop Europe and IBM is proposing SDDI to 
show a video clip art library application on PC's from an OS/2 server. So, I 
need to know if I have to ensure that their application is behind a router 
or is in some other way isolated from our stuff. (And if one of our pc's 
with FDDI card could even participate in their demo.)

Thanks,
Lee

    No, the whole ring does not need to operate in sync mode. .1 explicitly
    states that sync or asynch transmission is done on a per packet basis.

>>I'm setting up our FDDI demo at Interop Europe and IBM is proposing SDDI to 
>>show a video clip art library application on PC's from an OS/2 server. So, I 
>>need to know if I have to ensure that their application is behind a router 
>>or is in some other way isolated from our stuff. (And if one of our pc's 
>>with FDDI card could even participate in their demo.)
    
    Lee,
    
       Just as an FYI, Digital's FDDI EISA controller (DEFEA) is available
    in SAS and DAS and comes with NDIS 2.01 OS/2 and DOS drivers.  If
    you're looking to demo a PC as an FDDI OS/2 server or DOS client, please
    consider using the DEFEA.  They're available through 1-800-DIGITAL and
    other internal channels.
    
       - Larry Stefani
         FDDI Adapter Development
         High Performance Networks

Larry,

>       Just as an FYI, Digital's FDDI EISA controller (DEFEA) is available
>    in SAS and DAS and comes with NDIS 2.01 OS/2 and DOS drivers.  If
>    you're looking to demo a PC as an FDDI OS/2 server or DOS client, please
>    consider using the DEFEA.  They're available through 1-800-DIGITAL and
>    other internal channels.

Yes certainly I am. However, I need to know if the EISA FDDI controller 
can participate in IBM's SDDI network. It's actually not so simple since 
IBM requires a proprietary video decompression card (which they'll probably 
"lend" us) but since they are  using SDDI they will likely want to ensure
that our PC runs SDDI. Still, I'd like to have a DECpc participate. Does our 
EISA FDDI controller support SDDI operation? (either DOS or OS/2). 

Thanks,
Lee

What do you mean by "SDDI"?

I assumed you meant shielded twisted pair copper.  If so: I don't think there
is a DEFEA of that type, but you could connect a fiber DEFEA via a concentrator
that has ports of both kinds.  You might also use that as an opportunity to
push for the use of standard media rather than obsolescent proprietary ones.

Apparently some people think "SDDI" means "synchronous FDDI".  There is no
such thing.  Synch service does not require anything special.  All our products
can send and receive synch traffic.

	paul

    re: .15 & .16
    
    Right.  We don't have a DEFEA with IBM's SDDI implementation.  If we do
    build an FDDI EISA controller that runs over shielded twisted-pair, it
    will likely be ANSI standard rather than IBM's proprietary one.  As for
    DEFEA STP futures, you may want to ask Sharon (DELNI::ONEILL) Oneill
    who is the DEFEA, DEFTA, DEFZA Product Manager.
    
    As for getting this demo to work, Paul's suggestion sounds like the
    only possible one.  If you can get a SDDI concentrator with an FDDI MIC
    or ST port, you should be all set.  Interoperating with the video card
    shouldn't be a problem, and if there are any driver or configuration
    questions, we can try to answer them.  If the demo requires an SDDI/STP
    FDDI adapter, then you won't be able to use the DEFEA.
    
       - Larry

      

	I have a govt customer requesting:

	"Synchronous bandwith, as specified in ISO 9314-2
	is required"

	In terms of the DEFTA and OSF/1, is the correct
	answer that synchronous bandwidth capability is
	supported at the chip/mac layer, but would require
	modifications to the driver software to utilize
	this capability ?

	thanks,

	larry cole
	govt programs office
	landover, md
	Email:	etonic::cole

More precisely: the hardware supports it BOTH at the chip level and the
adapter level.  But you would need a bunch of software work to use it.

	paul