T.R | Title | User | Personal Name | Date | Lines |
---|
478.1 | S/W Support Schedule | DVOPAS::VACUUM::HOOVER | SCGAG Sales Support | Wed Apr 01 1992 19:42 | 3 |
| Can anybody provide me with information or point me to someone to determine what
S/W support will be provided for FDDI on ALPHA and in what time frame? I'm
assuming DECnet, but what about UCX?
|
478.2 | Alpha O.S. items discussed in vaxwrk::alphanotes | ORACLE::WATERS | I need an egg-laying woolmilkpig. | Thu Apr 02 1992 10:10 | 3 |
| Ask in vaxwrk::alphanotes. Also, you may need to be more specific
about which FDDI device you want supported. Like, "When will Alpha VMS
support the TURBOchannel-FDDI adapter for an Alpha machine with a TC bus?"
|
478.3 | Not sure I understand the question | STAR::SALKEWICZ | It missed... therefore, I am | Thu Apr 02 1992 16:38 | 10 |
| As far as device support in the operating system,.. it is generally
ready at the end of field test.
As far as software "layered products" (DECnet, LAT, UCX, whatever)
you have to ask each one individually for their schedules.
Sorry I can't be of more help
/Bill
|
478.4 | Trying to connect two Flamingos using DEFZAs... | CERN::JRS | John SHADE - 'Attila the Nun' | Tue Mar 02 1993 11:15 | 23 |
| Here's a question that maybe Bill Salkewicz would care to answer - but anyone
else is welcome to have a go ;-):
I'm trying to get two Flamingos (OpenVMS T1.5) connected back-to-back with FDDI
- but haven't managed thus far.
I've set PE3=1, and FCA1: exists on both systems. The PHY LED of both DEFZAs
blinks regularly, which is not what I'm after. .0 mentions the use of a
logical to overcome the fact that DECnet doesn't support the DEMFA in this
version of EVMS - do I need to do something similar to map FZA-0 onto FCA0:?
Both DEFZAs are at V1.2, and the cable is good. Both Flamingos are in a LAVc
(one Flamingo is a satellite of the other).
Does anyone have a check list of the things that I need to do in order to get
an FDDI circuit up between the two systems? It would be tremendously
appreciated...
Best regards,
John
P.S. cross-posted in Alphanotes
|
478.5 | | STAR::GAGNE | David Gagne - VMS/LAN Development | Tue Mar 02 1993 13:48 | 13 |
| The problem with directly connecting two FDDI adapters (on VMS) is that
the drivers for the two devices do not continually try to make them
join the ring. We do this to save CPU cycles. So because the drivers
work this way, it's difficult to get the two drivers to attempt to
join/create a ring at the same time.
One person told me that they put a loopback on both devices (to get
them running) and then very quickly pulled the two loopbacks out and
plugged the two devices together with a "regular" cable.
Of course, the easiest way to do this is to use a concentrator. The
concentrator is always looking down the wire for the other end. So
once you plug the cable into the adapter, it will join the ring.
|
478.6 | | KONING::KONING | Paul Koning, A-13683 | Tue Mar 02 1993 14:45 | 11 |
| HUH?
I don't understand why cycling through restart attempts saves CPU cycles.
The normal procedure is to start the device and wait to see what happens.
In any case, it now sounds like that approach actually creates a bug, so
it should be fixed. S to S connections are legal, and the ability to create
them is important. Telling the customer that he's got to buy a concentrator
is the wrong answer.
paul
|
478.7 | | STAR::GAGNE | David Gagne - VMS/LAN Development | Tue Mar 02 1993 15:11 | 14 |
| If there is no cable plugged in then the device does not "start".
That is, the device does not leave itself in a state where the driver
gets an interrupt when the cable is plugged in. The driver is forced
to continually check if it can "start" the device. We fall back to
checking once per minute (or once per five minutes). Also different
versions of VMS wait different times. Now that we have several FDDI
devices we are working on getting them to all have the same behavior.
If the device could operate more independently with regards to being
able to tell the driver when it's ready to be started or when the cable
has been plugged in, then we could wait for the interrupt - or even
check the device once per second (if it's one instruction). But to
spend many CPU cycles is a waste when you figure there will be times
when the device may not be plugged in for days/weeks/months.
|
478.8 | a concentrator means no full duplex | JEDI::CAUDILL | Kelly - NaC Tech Support - 264-3320 | Tue Mar 02 1993 17:26 | 2 |
| A concentrator is also not the right answer (in some cases) because it
prevents full duplex.
|
478.9 | Seems to be more than the lack of a concentrator | CERN::JRS | John SHADE - 'Attila the Nun' | Wed Mar 03 1993 07:53 | 16 |
| Well, I've tried using a concentrator, and still no joy. The LEDs on both
the concentrator and the DEFZAs blink as opposed to staying solid green.
Both Flamingos are plugged in to M-ports, so theoretically I should be able
to establish a connection.
I used NDU on a DS5000 to upgrade the DEFZAs to V1.2, the Flamingos both
run T1.5, the driver is SYS$FCDRIVER linked on 18-JAN-1993 10:37:29.79.
Any ideas on what I can do to get a connection?
Thanks,
John
P.S. The current VMS driver behaviour (as described in .5) clearly needs to be
revised.
|
478.10 | | KONING::KONING | Paul Koning, A-13683 | Wed Mar 03 1993 12:28 | 5 |
| Re .7: with fiber, the adapter has no idea, and doesn't care, whether there
is a cable or not. All it knows is that, once you tell it to start, it will
try to make the connection, and it will report when it's finished.
paul
|
478.11 | | QUIVER::WASHABAUGH | Born to be Mild | Thu Mar 04 1993 16:23 | 9 |
| In all of the FDDI drivers that our group does (NT, DOS, OS2, SCO, Novell)
we just enable the link and wait for an interrupt from the adapter
indicating that it has made a connection. This seems to work fine
for all of the protocols above us.
Of course, there may be some perfectly reasonable mitigating circumstances
in VMS or OSF/1 or ULTRIX which make this scheme unreasonable...
doug
|
478.12 | | STAR::GILLUM | Kirt Gillum | Thu Mar 04 1993 16:31 | 16 |
|
DEFZA to DEFZA works for me (after seeing the notes in here, I think
it needs some more attention). First of all, when connecting DEFZA to
DEFZA, don't forget to switch the connection on one adapter so you
aren't connecting xmit to xmit and recv to recv. I used this
configuration quite often when testing the driver (primarily with the
cluster protocol). I'll have to retry this with other protocols.
As Dave may or may not have eluded to, this is an area that we've
talked about redesigning. At this point, we have to decide what the
correct and most efficient thing to do is.
Kirt
P.S., Bill Salkewicz no longer works for the company.
|
478.13 | | STAR::GILLUM | Kirt Gillum | Thu Mar 04 1993 16:35 | 7 |
|
I just re-read .9...
There's something else basically wrong with your setup if using a
concentrator doesn't work. If the boards are not greater than rev C01,
I wouldn't trust them.
|
478.14 | | KONING::KONING | Paul Koning, A-13683 | Fri Mar 05 1993 14:43 | 7 |
| Aside: re .8: the presence of a concentrator doesn't necessarily prevent
full duplex mode. What does is the presence of a third MAC. If you're
trying to test full duplex, and this problem prevents you from getting
connections to work reliably, you might use as a workaround a concentrator
with NO management card. No third MAC, no problem with full duplex.
paul
|
478.15 | Rev C03 and above is key! | CERN::JRS | John SHADE - 'Attila the Nun' | Wed Mar 24 1993 09:32 | 5 |
| For the sake of completeness, my problem was the hardware revision of the
DEFZAs. My conclusion is that anything less than Rev C03 is about as close to
useless as one can get.
-John
|