Conference 7.286::fddi

>>  My customer question is:
>>  - do our FDDI equipments support synchronous operations
>>  - in particular, is it supported on our FDDI adapters, more especially the 
>>  DEFEA and DEFPA.
    
    Near as I can tell, all of our FDDI gear supports synchronous operation
    since it's controlled at the MAC chip level and we all use the Motorola
    MAC chips in one form or another.
    
>>  My complementary question: does it make sense with usual data protocols 
>>  (e.g. IPX/NEtware or IP), or are they able to use synchronous operation.
  
    However, this requires support from the hardware all the way up through
    the stack level, so it's extremely unlikely for you to see synch FDDI
    support on the commercial OS's (NetWare, Windows, etc).  As it stands
    today, all of the drivers we write within NPB use asynch.
    
    That's not to say that your customer can't have their own OS and write
    the SW necessary to take advantage of synchronous services on FDDI.
    
       - Larry

    I'm not sure, but i think Larry is addressing a different issue. From
    what little i understand our FDDI product set, it does not support
    synchronous operation.
    
    Synchronous implies that a frame will arrive at an end station during
    some well defined interval. FDDI does not necessarily guarantee this
    since each node may only use a small portion of the transmit time
    allocated to it. For example, when a node gets the token it may not
    have anything to transmit. It will then pass the token on to the next
    station. Given that level of ambiguity synchronous operation is not
    possible since token (and hence packet) arrival time is so dynamic.
    
    However this very problem was addressed by IBM and they came up with a
    plesiochronous (*almost* synchronous) mode of operation for FDDI. I
    recall that they exploited some aspect of the token rotation algorithm in
    order to "shoe-horn" in a packet at some well defined interval. I can't
    remember how successful it was, or if it ever made its way into the
    ANSI standard. This mode of operation may have been part of what was
    called FDDI II. But i don't think FDDI II ever got off the ground.
    
    If you want real plesiochronous operation, look to ATM. That's it's big
    advantage over LANs like FDDI.
    
    
    bill

There are several types of frame on the FDDI link which are distinguished
by their Frame Control (FC) byte.  The types are Void, SMT, MAC, Async LLC,
Sync LLC, Implementor and Reserved.

If your question is "Do we receive/transmit frames of type Sync LLC?" I 
believe the answer is yes.  Note that the DEFEA/DEFPA hardware can handle
these frames but if a specific driver/operating system doesn't expect them
then they "won't work".

If your question is "Are frames of type Sync LLC handled specially?" I 
believe the answer is no.  They will be passed by the hardware to the host
in the same order as Async LLC frames.

Here's what you have architecturally:

		.-------.	.---------.
		|	|	|	  |
		|	|	|  Frame  +-----> SMT/MAC to adapter CPU
	FDDI	|  MAC	| Rx 	| Control |
	------->| Chips +------>|         +-----> LLC to host CPU
	Receive	|	| Frame	|	  |
		|	|	|	  +--+
		|	|	|	  |  | Implementor and Reserved
		`-------'	`---------'  V frames are discarded. If
					       not discarded then they go
					       to host CPU queue.

So if you have a Sync LLC frame or an Async LLC frame then the hardware
will treat them the same and stuff them into the same queue in the host.
If the idea of a Sync LLC frame is to be processed ahead of Async LLC 
frames, as in a network Control request to be processed ahead of a Data
request, then that is not supported by hardware.

I hope this helps,
Chuck

p.s.  "plesiochronous"?  That's beautiful!

    ...note 234 has a discussion on support of synchronous mode in our
    products...