[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | FDDI - The Next Generation |
|
Moderator: | NETCAD::STEFANI |
|
Created: | Thu Apr 27 1989 |
Last Modified: | Thu Jun 05 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 2259 |
Total number of notes: | 8590 |
2027.0. "Point to point on FDDI physical layer without MAC?" by 52175::MARTINR_P (Advice: Say nothing often...) Tue Apr 30 1996 05:02
I am working on a pilot project, where the customer has bought
an Alphastation 600 systems with Digital UNIX, and the DEFPA,
with an option of buying Alpha's for another $10 mill if this
pilot is succesfull. We would very much like this to
happen, cause we could use the money :-).
The issue is as follows:
We are actually trying to use the FDDI as a point to point
communication link between a digitizer and the Alpha. Nothing
else is on the "ring", and the digitizer is just pouring out the
bits while I try to receive them on the Alpha side.
The digitizer is actually not using the whole FDDI protocoll, but
is "compatible with the fddi physical layer standard". What this
basically means is that the MAC layer is not used, instead the
customer is using their own MAC type layer. My task is therfor
to find a way to do this point to point fddi communication,
bypassing the MAC layer, and put the data into memory.
My thinking has been something like this:
a) Put the adapter into promiscous mode.
b) Use the Socket and DLI interface
c) Get the data into memory
d) Do FFT on the data
Unfortunatly I have a problem to understand how this can
be done practically, and questions like:
a) How can the adapter be put into promiscous mode?
Will this bypass the MAC layer, and will the Link
Available be able to start the adapter since no
real ring is pressent and the MAC layer is bypassed?
I still need the 4B5B coding, will this be maintained
in promiscous mode?
b) How can I connect to a promiscous adapter from the
Socket/DLI interface? How do you specify that you
want the promiscous data? Do any example code exist?
etc. etc.
I have also ben looking for a CSS group that does customized
hardware -- but without luck. Anybody know if we are still doing
these type of things?
Any help to shine some light on this issue is highly appreciated
Thank's.
-MARTIN-
T.R | Title | User | Personal Name | Date | Lines |
---|
2027.1 | been there, done that | NETCAD::ROLKE | Tune in, turn on, fail over | Tue Apr 30 1996 11:05 | 22 |
| Yes. This feature is shipping today except nobody but a select few
know about it and I've sworn not to reveal their names.
We in the FDDI firmware camp call this "MAC passive" mode. It was
developed for Frontier Software's NetScout product. You plug in a
DEFPA, their driver enables MAC passive mode and they can receive
everything without ever going on-ring. This is specially useful
when they run from a 10% tap -- they can jump in with the monitor
without disturbing the ring! Picture a Gigiswitch with an FDDI segment
that is acting funny. How can you monitor it? This special function
in DEFPA firmware is just the solution.
What you will be missing from your application is an Alpha UNIX device
driver function which will enable this firmware mode for you. Frontier
and I write our own drivers to test and use MAC passive mode but no
official and shipping drivers have ever heard of this mode. You will
require support from your local operating system.
Contact me by mail NETCAD::ROLKE.
Regards,
Chuck
|
2027.2 | Great! | 51549::MARTINR_P | Advice: Say nothing often... | Wed May 01 1996 11:43 | 3 |
| Great stuff Chuck, I'll get in touch with you offline.
-MARTIN-
|
2027.3 | DEFPA no can do | NETCAD::ROLKE | Teletype resurrection | Fri May 17 1996 10:32 | 17 |
| > The digitizer is actually not using the whole FDDI protocoll, but
> is "compatible with the fddi physical layer standard". What this
> basically means is that the MAC layer is not used, instead the
> customer is using their own MAC type layer.
After some follow up research we determined that the customer is
using no framing at all! They simply present parallel words to
a transmitter chip (TAXI) and send a continuous stream of data.
This is a lovely application of FDDI media to haul some data but it
completely cuts any of our FDDI NICs out of the loop. There is no
normal FDDI framing, addressing nor packet boundaries. From a
NIC hardware standpoint this data stream is hopeless; a custom
hardware solution is required.
Sorry to have sounded positive in an earlier reply,
Chuck
|