| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2213.1 | | STAR::STOCKDALE | | Mon Feb 03 1997 11:23 | 12 |
| >> For this we propose the following modifications:
>> 1/replace the MVAX 3800 with VAX 4000_505
>>...
>> 2/Are there potential drawbacks we do not see in the way FDDI works
>> that may lead to not matching the Real time application (max 2
>> milliseconds to send a 1 Kbyte message)?.
Why not go to Alpha? FDDI performance on VAX is dismal at best (VAX 6000/7000
is ok with DEMFA). A VAX 4000 would use a QBUS FDDI adapter? If so, you could
expect miserable performance.
- Dick
|
| 2213.2 | some comments | JULIET::HARRIS_MA | Networks Sales Exec | Mon Feb 03 1997 13:27 | 8 |
| 1. Use Alpha instead of VAX
2. Use Full Duplex Point-to-point FDDI links between 2 systems
3. Consider CSS for real-time applications. They have a great deal
of experience in real-time applications.
Mark
|
| 2213.3 | Moved by moderator | NETCAD::STEFANI | | Tue Feb 04 1997 11:12 | 25 |
| <<< UPSAR::USER$411:[NOTES$LIBRARY]FDDI.NOTE;1 >>>
-< FDDI - The Next Generation >-
================================================================================
Note 2214.0 need more help No replies
COWBOY::MIRGHANE 18 lines 4-FEB-1997 05:25
--------------------------------------------------------------------------------
Thanks very much for your interest here.
For application reasons it is not possible to go to Alpha (some
applications are written in macro assembler)
Although the Gigaswitch/FDDI is looked as an option; There is not a lot
of throughput here only time constraints (maximum of 5 Kbytes in 2 milliseconds is
equivalent to 20 Mbits/sec ) .
So We really need to know the time the token will take to go from one
computer to another - Each computer loading 1 Kbyte of data when it
gets the token -.
We also need to know is this time is stable or if not what reasons could
make it not stable?
Thanks very much for help.
Soumetty.
|
| 2213.4 | FDDI has "encumbered" bandwidth | NETCAD::ROLKE | The FDDI Genome Project | Tue Feb 04 1997 13:04 | 33 |
| > So We really need to know the time the token will take to go from one
> computer to another - Each computer loading 1 Kbyte of data when it
> gets the token -.
On a "clean" ring with "fast" processors the situation is just as you are
describing it. Each node would get data to transmit and present it to the
FDDI ring driver. Then the data is queued to the FDDI hardware for
transmission. The hardware waits for a token, transmits its data and then
releases the token. The data load you are presenting to the FDDI link
is a reasonable load.
Be aware that there is communication on the FDDI link over which you have
no direct control. Stations on the ring communicate periodically but
this is no big deal.
> We also need to know is this time is stable or if not what reasons could
> make it not stable?
Any ring event such as "station insertion" or "station removal" will cause
a ring initialization. This will make the ring go unavailable for a period
of about one second (more or less). This is a normal process. Errors and
other events can cause abnormal ring outages.
Also, the token rotation time is negotiated during the ring initialization
claim process. This dictates the "longest you will have to wait" for a
token. The accepted low limit for TTRT (t_req) is 4 mS. See note 1491.4.
This means that your nodes will wait for the token for up to 8 mS before
your node declares the ring to be in trouble and begins a reinitialization.
FDDI is nothing like the dedicated bandwidth of a parallel interface.
See what kind of resources CSS has to help you with this.
Chuck
|