Just browsing through my routing table status servlet and noticed
something worrying - a backed-off node whose last estimate was -27143ms.
Presumably we shouldn't be getting negative estimates for routing times.
I looked through the node's estimators and couldn't see anything
obviously
Ian Clarke wrote:
Just browsing through my routing table status servlet and noticed
something worrying - a backed-off node whose last estimate was -27143ms.
Presumably we shouldn't be getting negative estimates for routing times.
Hmmm, just found another 6 of them in my RT - it looks like this
Ian Clarke wrote:
Ian Clarke wrote:
Just browsing through my routing table status servlet and noticed
something worrying - a backed-off node whose last estimate was
-27143ms. Presumably we shouldn't be getting negative estimates for
routing times.
Hmmm, just found another 6 of them in my
Toad (or someone who can do this),
Since QR backoff was implemented, upgraded nodes have probably queried
far less than they did before. However, non-upgraded nodes are still
over-querying. In fact, we might reach a point where we have 10% of
connected nodes using the old version, but see
On Sun, 2003-11-16 at 12:30, Martin Stone Davis wrote:
Since QR backoff was implemented, upgraded nodes have probably queried
far less than they did before. However, non-upgraded nodes are still
over-querying. In fact, we might reach a point where we have 10% of
connected nodes using the
Many nodes now exceed their output bandwidth regularly and as a
result issue many QRs. We are trying to reduce the bandwidth wasted
sending QRs, and the waste of resources which occurs when a deeply
chained request gets QRed. The node which first receives the QR
does not try again with a
On Sun, 2003-11-16 at 21:40, Ken Corson wrote:
Edward J. Huff wrote:
chained request gets QRed. The node which first receives the QR
does not try again with a different node in its routing table, as
it would if it got a DNF. Instead, it passes the QR back, and
all of the preceding links
We need to reduce the number of queries coming from nodes which don't
use QR-backoff. A few ways to do this are:
1. Keep track of each node and punish those who don't back off.
* PRO: Would protect us from evil nodes who pretend to be upgraded but
don't back off. (The following two ways would
On November 16, 2003 10:17 pm, Edward J. Huff wrote:
I'm very confused by this. I was under the impression that a
QR meant DON'T back down the chain, just try another path and
that DNF meant send a failure all the way back down the chain,
as the HTL has been exhausted.
In fact, that's
Martin Stone Davis wrote:
Ian Clarke wrote:
Ian Clarke wrote:
Just browsing through my routing table status servlet and noticed
something worrying - a backed-off node whose last estimate was
-27143ms. Presumably we shouldn't be getting negative estimates for
routing times.
Hmmm, just
10 matches
Mail list logo
