strange behaviour: toasted network cards? - DEC

This is a discussion on strange behaviour: toasted network cards? - DEC ; About a week ago, there was an unexpected power outage. After the cluster came back up, some strange behaviour was noticed. Maybe there is no relation, but I suspect there is, due to the coincidence in time. The strange behaviour ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: strange behaviour: toasted network cards?

  1. strange behaviour: toasted network cards?

    About a week ago, there was an unexpected power outage. After the
    cluster came back up, some strange behaviour was noticed. Maybe there
    is no relation, but I suspect there is, due to the coincidence in time.

    The strange behaviour is the following. While working interactively,
    everything is fine, then things freeze up for a few seconds, then work
    fine again. It is ALMOST like a slow network, but not quite; when the
    network is slow since it is overloaded, it is SLOW---what is happening
    now is that throughput is in fits and starts---it's either there at
    apparently normal speed or it is not there at all.

    I'm accessing the cluster remotely, but I'm sure that the problem is
    within the cluster since other machines on the LAN, both locally and
    remotely, don't show this problem.

    Here is the error count on PEA0: for the three nodes currently in the
    cluster: 1229, 819 and 20472. In the first case, this is the error
    count since 18 March. For the other two, there was an unplanned reboot
    (i.e. it happened automatically; no power outage) a day and a half ago,
    so the error count was reset then. Before this reboot of the two nodes,
    the ratio of errors was about the same. Of course, 20472 is a huge
    error count on PEA0: for a day and a half!

    Could a too-high error count cause a reboot?

    Could the power outage have damaged network cards or something,
    resulting in this problem? (There have been power outages before, and
    they never seemed to have bad effects.)

    The error count doesn't grow gradually, but also in fits and starts, but
    it is NOT the case that it increases when there is a freeze up; the two
    problems seem to be unrelated temporaally.

    Is there a way, after an unplanned reboot, to find out WHY the reboot
    occurred? I didn't find any crash dump.


  2. Re: strange behaviour: toasted network cards?

    Phillip Helbig---remove CLOTHES to reply a écrit :
    > About a week ago, there was an unexpected power outage. After the
    > cluster came back up, some strange behaviour was noticed. Maybe there
    > is no relation, but I suspect there is, due to the coincidence in time.


    >
    > Could the power outage have damaged network cards or something,
    > resulting in this problem? (There have been power outages before, and
    > they never seemed to have bad effects.)
    >

    could be bad negotiation (half/full duplex) between the NIC and switch
    on one (or more) systems in the cluster...
    It can cause nodes disappearing/coming back in a cluster under heavy
    network load.



  3. Re: strange behaviour: toasted network cards?

    In article <44253127$0$27895$626a54ce@news.free.fr>, rejoc
    writes:

    > could be bad negotiation (half/full duplex) between the NIC and switch
    > on one (or more) systems in the cluster...
    > It can cause nodes disappearing/coming back in a cluster under heavy
    > network load.


    OK, but is this something one would expect to have changed after a power
    cycle?


  4. Re: strange behaviour: toasted network cards?

    Phillip Helbig---remove CLOTHES to reply a écrit :
    > In article <44253127$0$27895$626a54ce@news.free.fr>, rejoc
    > writes:
    >
    >> could be bad negotiation (half/full duplex) between the NIC and switch
    >> on one (or more) systems in the cluster...
    >> It can cause nodes disappearing/coming back in a cluster under heavy
    >> network load.

    >
    > OK, but is this something one would expect to have changed after a power
    > cycle?
    >

    If the connections are autonegocatied, yes, I've seen such
    mis-negociation after a power off/on.

    That's why I always force the configuration of NIC and switch port.

    You can check the configuration with LANCP on the system side...

  5. Re: strange behaviour: toasted network cards?


    "Phillip Helbig---remove CLOTHES to reply"
    wrote in message news:e038fm$afp$1@online.de...
    > About a week ago, there was an unexpected power outage. After the
    > cluster came back up, some strange behaviour was noticed. Maybe there
    > is no relation, but I suspect there is, due to the coincidence in time.
    >
    > The strange behaviour is the following. While working interactively,
    > everything is fine, then things freeze up for a few seconds, then work
    > fine again. It is ALMOST like a slow network, but not quite; when the
    > network is slow since it is overloaded, it is SLOW---what is happening
    > now is that throughput is in fits and starts---it's either there at
    > apparently normal speed or it is not there at all.
    >
    > I'm accessing the cluster remotely, but I'm sure that the problem is
    > within the cluster since other machines on the LAN, both locally and
    > remotely, don't show this problem.
    >
    > Here is the error count on PEA0: for the three nodes currently in the
    > cluster: 1229, 819 and 20472. In the first case, this is the error
    > count since 18 March. For the other two, there was an unplanned reboot
    > (i.e. it happened automatically; no power outage) a day and a half ago,
    > so the error count was reset then. Before this reboot of the two nodes,
    > the ratio of errors was about the same. Of course, 20472 is a huge
    > error count on PEA0: for a day and a half!
    >
    > Could a too-high error count cause a reboot?
    >
    > Could the power outage have damaged network cards or something,
    > resulting in this problem? (There have been power outages before, and
    > they never seemed to have bad effects.)
    >
    > The error count doesn't grow gradually, but also in fits and starts, but
    > it is NOT the case that it increases when there is a freeze up; the two
    > problems seem to be unrelated temporaally.
    >
    > Is there a way, after an unplanned reboot, to find out WHY the reboot
    > occurred? I didn't find any crash dump.
    >


    The following network problem just happened to me and was caused by cheap
    network hardware. After a power surge, I started to notice poor network
    performance (but no OpenVMS crash). My problem was traced to an old LinkSys
    Router (BEFSR41 ver-1) which we were using as an inexpensive alternative to
    the CISCO PIX firewall. A Google search revealed a known power supply
    problem in the 16-LED version of this product. See the following link for
    pictures.
    http://www.dondoucette.com/befsr41/
    I opened my unit and noticed the primary filter capacitor was bulged out
    more than the pictures in the link above. Note that "Ver-1" (16-LED) units
    have a 16v filter capacitor while "Ver-3" (6-LED) units have a 25v
    capacitor. We've only got one bad unit out of many so don't get the
    impression that I'm against LinkSys products.

    Neil Rieck
    Kitchener/Waterloo/Cambridge,
    Ontario, Canada.
    http://www3.sympatico.ca/n.rieck/lin...l_openvms.html




  6. Re: strange behaviour: toasted network cards?

    In article <442540b4$0$9638$636a55ce@news.free.fr>, rejoc
    writes:

    > Phillip Helbig---remove CLOTHES to reply a écrit :
    > > In article <44253127$0$27895$626a54ce@news.free.fr>, rejoc
    > > writes:
    > >
    > >> could be bad negotiation (half/full duplex) between the NIC and switch
    > >> on one (or more) systems in the cluster...
    > >> It can cause nodes disappearing/coming back in a cluster under heavy
    > >> network load.

    > >
    > > OK, but is this something one would expect to have changed after a power
    > > cycle?
    > >

    > If the connections are autonegocatied, yes, I've seen such
    > mis-negociation after a power off/on.
    >
    > That's why I always force the configuration of NIC and switch port.
    >
    > You can check the configuration with LANCP on the system side...


    Sounds interesting; where do I start?


  7. Re: strange behaviour: toasted network cards?

    Phillip Helbig---remove CLOTHES to reply a écrit :
    > In article <442540b4$0$9638$636a55ce@news.free.fr>, rejoc
    > writes:
    >
    >> Phillip Helbig---remove CLOTHES to reply a écrit :
    >>> In article <44253127$0$27895$626a54ce@news.free.fr>, rejoc
    >>> writes:
    >>>
    >>>> could be bad negotiation (half/full duplex) between the NIC and switch
    >>>> on one (or more) systems in the cluster...
    >>>> It can cause nodes disappearing/coming back in a cluster under heavy
    >>>> network load.
    >>> OK, but is this something one would expect to have changed after a power
    >>> cycle?
    >>>

    >> If the connections are autonegocatied, yes, I've seen such
    >> mis-negociation after a power off/on.
    >>
    >> That's why I always force the configuration of NIC and switch port.
    >>
    >> You can check the configuration with LANCP on the system side...

    >
    > Sounds interesting; where do I start?
    >

    $ mc lancp show conf
    will show you the speed and duplex currently setup on the NIC.

    For the switch, if it is manageable you should be able to check the
    configuration.

    Check this on all the systems in the cluster.

  8. Re: strange behaviour: toasted network cards?

    In article , "Neil Rieck"
    writes:

    > The following network problem just happened to me and was caused by cheap
    > network hardware. After a power surge, I started to notice poor network
    > performance (but no OpenVMS crash). My problem was traced to an old LinkSys
    > Router (BEFSR41 ver-1) which we were using as an inexpensive alternative to
    > the CISCO PIX firewall. A Google search revealed a known power supply
    > problem in the 16-LED version of this product. See the following link for
    > pictures.
    > http://www.dondoucette.com/befsr41/
    > I opened my unit and noticed the primary filter capacitor was bulged out
    > more than the pictures in the link above. Note that "Ver-1" (16-LED) units
    > have a 16v filter capacitor while "Ver-3" (6-LED) units have a 25v
    > capacitor. We've only got one bad unit out of many so don't get the
    > impression that I'm against LinkSys products.


    Actually, I am using this router. I'm not sure if it was also affected
    by the power outage (it is in another room). It certainly has survived
    power outages in the past, and in general I've been quite happy with it.
    (I especially like the fact that lynx -dump can extract the WAN email
    address. This lets me update the DNS for the dynamic IP via a batch
    job. Many more "modern" routers are accessible only via javascript.)


  9. Re: strange behaviour: toasted network cards?

    In article <442546b6$0$7934$636a55ce@news.free.fr>, rejoc
    writes:

    > $ mc lancp show conf
    > will show you the speed and duplex currently setup on the NIC.


    SYSMAN> do $ mc lancp show conf
    %SYSMAN-I-OUTPUT, command execution on node DANEEL
    LAN Configuration:
    Device Medium Default LAN Address Version
    ------ ------ ------------------- -------
    EZA0 CSMA/CD 08-00-2B-92-26-9D Not available
    %SYSMAN-I-OUTPUT, command execution on node ELIJAH
    LAN Configuration:
    Device Medium Default LAN Address Version
    ------ ------ ------------------- -------
    EZA0 CSMA/CD 08-00-2B-BF-A4-AB Not available
    %SYSMAN-I-OUTPUT, command execution on node GLADIA
    LAN Configuration:
    Device Parent Medium/User Version Speed Size LAN Address
    ------ ------ ----------- ------- ----- ---- -----------------
    ESA0 CSMA/CD 00000000 10 1500 08-00-2B-96-22-35

    Note that GLADIA is an ALPHA; DANEEL and ELIJAH are VAXes.

    > For the switch, if it is manageable you should be able to check the
    > configuration.


    The VMS systems are connected via a DECrepeater. A long cable goes from
    that to a switch/router upstairs. I'll have a look at that later. The
    DECrepeater is I believe manageable, but I don't have access to it now.
    (My cluster is 500 km away, but this week I'll be moving it to my place
    of residence, which will make hardware work easier.)


  10. Re: strange behaviour: toasted network cards?


    "Phillip Helbig---remove CLOTHES to reply"
    wrote in message news:e05ljk$ne0$1@online.de...
    > In article , "Neil Rieck"
    > writes:
    >
    >> The following network problem just happened to me and was caused by cheap
    >> network hardware. After a power surge, I started to notice poor network
    >> performance (but no OpenVMS crash). My problem was traced to an old
    >> LinkSys
    >> Router (BEFSR41 ver-1) which we were using as an inexpensive alternative
    >> to
    >> the CISCO PIX firewall. A Google search revealed a known power supply
    >> problem in the 16-LED version of this product. See the following link for
    >> pictures.
    >> http://www.dondoucette.com/befsr41/
    >> I opened my unit and noticed the primary filter capacitor was bulged out
    >> more than the pictures in the link above. Note that "Ver-1" (16-LED)
    >> units
    >> have a 16v filter capacitor while "Ver-3" (6-LED) units have a 25v
    >> capacitor. We've only got one bad unit out of many so don't get the
    >> impression that I'm against LinkSys products.

    >
    > Actually, I am using this router. I'm not sure if it was also affected
    > by the power outage (it is in another room). It certainly has survived
    > power outages in the past, and in general I've been quite happy with it.
    > (I especially like the fact that lynx -dump can extract the WAN email
    > address. This lets me update the DNS for the dynamic IP via a batch
    > job. Many more "modern" routers are accessible only via javascript.)
    >

    The external power supply converts 120 vac into 9 vac before it enters the
    BEFSR41-ver1. Rectification and filtering results in 12.73 vdc. In my case,
    the building power supply "averages" 125 vac which results in 13.26 vdc
    which is starting to eat into the 20% margin of the 16 vdc cap. (some
    designers will use a 33% margin). Power surges make things worse.

    We are not a poor company but this problem had piqued my curiosity so I
    decided to repair the unit by replacing the 16 vdc cap with another rated 25
    vdc. To quote the movie 2001, "The AE35 unit is now back in service" (but
    has not failed 100% in 72 hours)

    Neil Rieck
    Kitchener/Waterloo/Cambridge,
    Ontario, Canada.
    http://www3.sympatico.ca/n.rieck/lin...l_openvms.html



  11. Re: strange behaviour: toasted network cards?

    Phillip Helbig---remove CLOTHES to reply a écrit :
    > In article <442546b6$0$7934$636a55ce@news.free.fr>, rejoc
    > writes:
    >
    >> $ mc lancp show conf
    >> will show you the speed and duplex currently setup on the NIC.

    >
    > SYSMAN> do $ mc lancp show conf
    > %SYSMAN-I-OUTPUT, command execution on node DANEEL
    > LAN Configuration:
    > Device Medium Default LAN Address Version
    > ------ ------ ------------------- -------
    > EZA0 CSMA/CD 08-00-2B-92-26-9D Not available
    > %SYSMAN-I-OUTPUT, command execution on node ELIJAH
    > LAN Configuration:
    > Device Medium Default LAN Address Version
    > ------ ------ ------------------- -------
    > EZA0 CSMA/CD 08-00-2B-BF-A4-AB Not available
    > %SYSMAN-I-OUTPUT, command execution on node GLADIA
    > LAN Configuration:
    > Device Parent Medium/User Version Speed Size LAN Address
    > ------ ------ ----------- ------- ----- ---- -----------------
    > ESA0 CSMA/CD 00000000 10 1500 08-00-2B-96-22-35
    >
    > Note that GLADIA is an ALPHA; DANEEL and ELIJAH are VAXes.
    >
    >> For the switch, if it is manageable you should be able to check the
    >> configuration.

    >
    > The VMS systems are connected via a DECrepeater. A long cable goes from
    > that to a switch/router upstairs. I'll have a look at that later. The
    > DECrepeater is I believe manageable, but I don't have access to it now.
    > (My cluster is 500 km away, but this week I'll be moving it to my place
    > of residence, which will make hardware work easier.)
    >

    I suppose that the ethernet interface on the VAXes are not "native" 10bT
    interfaces. So they must be connected to the DECrepeater through 10bT
    transceivers and there is nothing to do regarding half/full duplex.

    On the Alpha, it would be interesting to know the "duplexing" of the
    interface but lancp doesn't seem to give the value (too old version of
    VMS ?). This can be checked at the console prompt (>>>) or during boot.
    As you are connected to a DECrepeater, your interface should be
    configured no-auto-negotiate, 10Mb/s, *half duplex*.

  12. Re: strange behaviour: toasted network cards?

    In article <4428161f$0$29721$636a55ce@news.free.fr>, rejoc
    writes:

    > I suppose that the ethernet interface on the VAXes are not "native" 10bT
    > interfaces. So they must be connected to the DECrepeater through 10bT
    > transceivers and there is nothing to do regarding half/full duplex.


    Right, converting the thickwire to twisted pair.

    > On the Alpha, it would be interesting to know the "duplexing" of the
    > interface but lancp doesn't seem to give the value (too old version of
    > VMS ?).


    7.3-2, all patches (up until the batch which started coming about 2
    weeks ago).

    > This can be checked at the console prompt (>>>) or during boot.
    > As you are connected to a DECrepeater, your interface should be
    > configured no-auto-negotiate, 10Mb/s, *half duplex*.


    I'm moving the hardware here on Thursday, so I can more easily check
    things like this.

    ALL nodes are having trouble, but a) the ALPHA has the most and b)
    perhaps the troubles on the VAXes are a result of the ALPHA troubles.


  13. Re: strange behaviour: toasted network cards?

    Phillip Helbig---remove CLOTHES to reply a écrit :
    > In article <4428161f$0$29721$636a55ce@news.free.fr>, rejoc
    > writes:
    >
    >> I suppose that the ethernet interface on the VAXes are not "native" 10bT
    >> interfaces. So they must be connected to the DECrepeater through 10bT
    >> transceivers and there is nothing to do regarding half/full duplex.

    >
    > Right, converting the thickwire to twisted pair.
    >
    >> On the Alpha, it would be interesting to know the "duplexing" of the
    >> interface but lancp doesn't seem to give the value (too old version of
    >> VMS ?).

    >
    > 7.3-2, all patches (up until the batch which started coming about 2
    > weeks ago).

    Sorry, I don't have any more Alpha 7.x systems to check. But perhaps the
    hardware cannot transmit the information to the system ???

    If the system keeps on crashing and if the command exists, you could
    perhaps try a
    $ mc lancp set device esa0 /noautonego/nofull_duplex/speed=10
    (don't really know if the command will do anything because of "show
    conf" doesn't give the duplexing...)
    >
    >> This can be checked at the console prompt (>>>) or during boot.
    >> As you are connected to a DECrepeater, your interface should be
    >> configured no-auto-negotiate, 10Mb/s, *half duplex*.

    >
    > I'm moving the hardware here on Thursday, so I can more easily check
    > things like this.
    >
    > ALL nodes are having trouble, but a) the ALPHA has the most and b)
    > perhaps the troubles on the VAXes are a result of the ALPHA troubles.
    >

    When a node has problem to "talk" to the others within a cluster it can
    mess up all the cluster. Usually there are many messages about lost
    connections to a node, then the node is coming back, etc...

  14. Re: strange behaviour: toasted network cards?

    same thing happened to us with a DE500 card ...
    our TCPware NIC failover dual cards keep us
    up but we had sluggishness that after slowly
    increasing error counts turned to really slow ...
    a card change fixed the problem so probably
    some kind of line surge?


  15. Re: strange behaviour: toasted network cards?


    "Phillip Helbig---remove CLOTHES to reply"
    wrote in message news:e09ipp$v7j$1@online.de...
    > In article <4428161f$0$29721$636a55ce@news.free.fr>, rejoc
    > writes:
    >
    >
    >> On the Alpha, it would be interesting to know the "duplexing" of the
    >> interface but lancp doesn't seem to give the value (too old version of
    >> VMS ?).

    >

    [...snip...]
    >
    >> This can be checked at the console prompt (>>>) or during boot.
    >> As you are connected to a DECrepeater, your interface should be
    >> configured no-auto-negotiate, 10Mb/s, *half duplex*.

    >

    [...snip...]
    >

    Rule of thumb: if you are using ?-BASE-T and are connecting directly to an
    Ethernet switch, then you can go full duplex. At all other times (eg.
    "Ethernet hub" or "shared transmit + receive paths") then you must go half
    duplex.

    Neil Rieck
    Kitchener/Waterloo/Cambridge,
    Ontario, Canada.
    http://www3.sympatico.ca/n.rieck/lin...l_openvms.html



  16. Re: strange behaviour: toasted network cards?

    rejoc wrote:
    > Phillip Helbig---remove CLOTHES to reply a écrit :
    >
    >> In article <442546b6$0$7934$636a55ce@news.free.fr>, rejoc
    >> writes:
    >>
    >>> $ mc lancp show conf
    >>> will show you the speed and duplex currently setup on the NIC.

    >>
    >>


    >> SYSMAN> do $ mc lancp show conf


    Try "SYSMAN> do $ mc lancp show dev/all/char"

    On 7.3-2, this definitely shows full/half duplex status as well
    as speed. (On V8.2, "mcr lancp show conf" shows duplex state,
    but on my one 8.2 node, it is *WRONG*. It shows 10Mb Full, but
    the DE435 adapter on my AlphaStation 200 4/100 (worlds slowest
    Alpha?) isn't capable of full duplex and "mcr lancp show dev/all/char"
    says it's in Half-Duplex.)


    >> %SYSMAN-I-OUTPUT, command execution on node DANEEL
    >> LAN Configuration:
    >> Device Medium Default LAN Address Version
    >> ------ ------ ------------------- -------
    >> EZA0 CSMA/CD 08-00-2B-92-26-9D Not available
    >> %SYSMAN-I-OUTPUT, command execution on node ELIJAH
    >> LAN Configuration:
    >> Device Medium Default LAN Address Version
    >> ------ ------ ------------------- -------
    >> EZA0 CSMA/CD 08-00-2B-BF-A4-AB Not available


    Unless you are using a 3rd-party ethernet adapter (Nemonix?),
    all VAX Ethernets are 10Mb HD. If the switch isn't set the
    to 10Mb, it won't work at all. I've never seen a 10Mb FD, is
    this even possible?

    >> %SYSMAN-I-OUTPUT, command execution on node GLADIA
    >> LAN Configuration:
    >> Device Parent Medium/User Version Speed Size LAN
    >> Address
    >> ------ ------ ----------- ------- ----- ----
    >> -----------------
    >> ESA0 CSMA/CD 00000000 10 1500
    >> 08-00-2B-96-22-35
    >>
    >> Note that GLADIA is an ALPHA; DANEEL and ELIJAH are VAXes.
    >>


    The Alpha is running at 10Mb, but was this the most it can do,
    or the result of bogus autonegotiation?

    mcr lancp show dev/all/char should help clear this up.


    >>> For the switch, if it is manageable you should be able to check the
    >>> configuration.

    >>
    >>
    >> The VMS systems are connected via a DECrepeater. A long cable goes from
    >> that to a switch/router upstairs. I'll have a look at that later.
    >> The DECrepeater is I believe manageable, but I don't have access to it
    >> now.
    >> (My cluster is 500 km away, but this week I'll be moving it to my
    >> place of residence, which will make hardware work easier.)
    >>

    > I suppose that the ethernet interface on the VAXes are not "native" 10bT
    > interfaces. So they must be connected to the DECrepeater through 10bT
    > transceivers and there is nothing to do regarding half/full duplex.
    >
    > On the Alpha, it would be interesting to know the "duplexing" of the
    > interface but lancp doesn't seem to give the value (too old version of
    > VMS ?). This can be checked at the console prompt (>>>) or during boot.
    > As you are connected to a DECrepeater, your interface should be
    > configured no-auto-negotiate, 10Mb/s, *half duplex*.



    Another give-away of duplex mismatch is lots of frame-check
    and alignment errors under load. These usually get logged
    to OPCOM, at least when running DECnet-Plus.

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  17. Re: strange behaviour: toasted network cards?

    In article <442856f9$0$7689$636a55ce@news.free.fr>, rejoc
    writes:

    > >> I suppose that the ethernet interface on the VAXes are not "native" 10bT
    > >> interfaces. So they must be connected to the DECrepeater through 10bT
    > >> transceivers and there is nothing to do regarding half/full duplex.

    > >
    > > Right, converting the thickwire to twisted pair.
    > >
    > >> On the Alpha, it would be interesting to know the "duplexing" of the
    > >> interface but lancp doesn't seem to give the value (too old version of
    > >> VMS ?).

    > >
    > > 7.3-2, all patches (up until the batch which started coming about 2
    > > weeks ago).


    I haven't posted in a while, since I've been setting up hardware. After
    moving all my hardware 500 km in a van and plugging everything back in
    the way it was, the problem has disappeared. I don't know what caused
    it, but I am happy that it is no longer present. Obviously, I don't
    want to switch the power on and off just to check.


  18. Re: strange behaviour: toasted network cards?

    In article , John Santos
    writes:

    > Try "SYSMAN> do $ mc lancp show dev/all/char"


    Value Characteristic
    ----- --------------
    1500 Device buffer size
    Normal Controller mode
    External Internal loopback mode
    08-00-2B-96-22-35 Hardware LAN address
    Multicast address list
    CSMA/CD Communication medium
    FF-FF-FF-FF-FF-FF Current LAN address
    128 Minimum receive buffers
    256 Maximum receive buffers
    No Full duplex enable
    No Full duplex operational
    Unspecified Line media type
    10 Line speed (mbps)
    Disabled/No Failset Logical LAN state
    0 Failover priority

    This is 7.3-2 ALPHA; doesn't work on 7.3 VAX.

    > >> %SYSMAN-I-OUTPUT, command execution on node ELIJAH
    > >> LAN Configuration:
    > >> Device Medium Default LAN Address Version
    > >> ------ ------ ------------------- -------
    > >> EZA0 CSMA/CD 08-00-2B-BF-A4-AB Not available

    >
    > Unless you are using a 3rd-party ethernet adapter (Nemonix?),
    > all VAX Ethernets are 10Mb HD. If the switch isn't set the
    > to 10Mb, it won't work at all. I've never seen a 10Mb FD, is
    > this even possible?


    I have Allied/Telesyn adapters to convert AUI to UTP. Things are then
    plugged into a Netgear hub. (I had been using a DECrepeater. When I
    have time, I'll see if perhaps it got damaged and was the source of the
    problem.

    > The Alpha is running at 10Mb, but was this the most it can do,
    > or the result of bogus autonegotiation?


    I think the hub is just 10 Mb/s, and probably the (quite old) ALPHA as
    well.


+ Reply to Thread