[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[3]: 20020213: [Fwd: Re: [Fwd: 20020207: missing products]]

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Re[3]: 20020213: [Fwd: Re: [Fwd: 20020207: missing products]]
  • Date: Tue, 5 Mar 2002 11:02:42 -0700
Harry,

I'm a bit curious about the frequent network interface messages on sunny.
This seems to me that both interfaces are re-negotiating speed and duplex
fairly often -- are you willing to hardwire these parameters an see if
this helps?

Mar  5 09:34:05 sunny vmunix: tu1: link up: negotiated 100BaseTX: full duplex
Mar  5 09:34:06 sunny vmunix: tu0: link up: negotiated 100BaseTX: full duplex
Mar  5 09:44:05 sunny vmunix: tu1: link up: negotiated 100BaseTX: full duplex
Mar  5 09:44:07 sunny vmunix: tu0: link up: negotiated 100BaseTX: full duplex

Also, I've run across an interesting article on google about the following;

vmunix: tu0: transmit FIFO underflow: threshold raised to: 512 bytes

one person had this to say;

> I was able to observe that the DE500 shortly takes the link down upon
> enlarging it's FIFO buffer. This brief link transition was seen by the
> Ethernet switch port (with STP enabled) as a network topology change,
> which induced the port to enter in the blocking state for the duration
> specified by the "bridge forward delay timer", which is 15 seconds by
> default with our network hardware. So, every time the FIFO size was
> adjusted, the server was cut from the rest of the network for this
> interval. Since our servers do not act themselves as bridging devices in
> the network, there is no need to have STP enabled on the switch ports
> they are connected to. Disabling STP on server ports effectively
> prevents a flick in link transition from triggering the 15-second wait.

and we might see the same on any of our systems that drop the network link
due to a spanning tree/port fast issue on our Cisco network gear.  What
type of networking gear is this (these) systems plugged into?

mike

On Mar 1,  4:09pm, Harry Edmon wrote:
> Subject: Re[3]: 20020213: [Fwd: Re: [Fwd: 20020207: missing products]]
> I looked at the tcpdump on both sunny and air in a case where they lost
> contact when sunny was trying to send a McIDAS product to air.  The
> traffic just stops for a minute.  It goes along with sunny sending air,
> and air acknowledging.  Then, when the hang up occurs air sends an
> acknowledgement, but sunny sends nothing for 60 seconds.  This really
> starts to look like a problem with the ldm.
>
>
> --
> Dr. Harry Edmon                       E-MAIL: address@hidden
> 206-543-0547                          address@hidden
> Dept of Atmospheric Sciences  FAX:    206-543-0308
> University of Washington, Box 351640, Seattle, WA 98195-1640
>-- End of excerpt from Harry Edmon