[Top] [All Lists]

Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis

To: Bogdan Costescu <bogdan.costescu@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis
From: jamal <hadi@xxxxxxxxxx>
Date: Mon, 4 Jun 2001 15:08:51 -0400 (EDT)
Cc: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>, Pete Zaitcev <zaitcev@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, <netdev@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.33.0106031401050.31050-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

On Sun, 3 Jun 2001, Bogdan Costescu wrote:

> On Sat, 2 Jun 2001, jamal wrote:
> > Still, the tx watchdogs are a good source of fault detection in the case
> > of non-availabilty of MII detection and even with the presence of MII.
> Agreed. But my question was a bit different: is there any legit situation
> where Tx timeouts can happen in a row _without_ having a link loss ? In
> this situation, we'd have false positives...

Two places:
1) no MII indicators
2) shaky hardware and MII bounces. Is it on, is it off? What is going on?
You  could use them to "probe" to make sure that infact the MII indicators
are not false positives.

Your mileage may vary.

> > "Dynamic" in the above sense means trying to totaly avoid making it a
> > synchronous poll. The poll rate is a function of how many packets go out
> > that device per average measurement time. Basically, the period that the
> > user space app dumps "hello" netlink packets to the kernel is a variable.
> Sounds nice, but could this be implemented light enough ?

Not as simple as synchronous polls.
Note, however, simple/light does not imply the best.


<Prev in Thread] Current Thread [Next in Thread>