[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[3]: 20020213: [Fwd: Re: [Fwd: 20020207: missing products]]
- 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