ndt-users list created

[Richard Carlson <>]

Oops,

One quick correction.  The NDT server has 2 different mismatch detection 
heuristics.  The original heuristic is listed below.  I changed to a newer 
version some time ago.  It uses
        packets arrive out of order more than 20% of the time (35.58% here)
        ack packet rate skewed from normal 50%  (64% here)
                more than 70% or less than 35%
                (unfortunately, this is very OS specific)
        asymmetric speed between inbound and outbound tests (factor of 60 
here)

So the detection failed because the ack packet rate didn't skew far 
enough.  You can enable the old detection heuristic by running the 
web100srv process with the "-o" flag.

Rich

At 11:44 AM 11/4/2005, Richard Carlson wrote:
> Hi Matt;
>
> Welllll it kind of reports it "Excessive packet loss is impacting your 
> performance, check the auto-negotiate function on your local PC and 
> network switch" and the asymmetric throughput is another clue,  but yes 
> the mismatch detection algorithm failed in this case.
>
> Here's why.
>
> The current duplex mismatch detection heuristics is based on some 
> experiments I ran several years ago.  I have been actively working on 
> enhancing this part of the NDT code ever since.  The current heuristic 
> using a logical AND of the following conditions.
>         Congestion Window limited over 90% of the time (99.93% here)
>         Theoretical speed over 2 Mbps (7.32 Mbps here)
>         more than 2 packets being retransmitted per second (2.19 here)
>         SSthresh value has been set (4344 Bytes here)
>         Connection was idle more than 1% of the time (0 here)
>
> So the first 4 conditions are true but the 5th is false so the condition 
> is not reported.
>
> While I am working on fixes for this problem, including a more 
> mathematically rigorous model for this condition, the going is slow.  I 
> need to figure out when a problem is caused by the mismatch condition and 
> when it is an artifact of the specific OS/browser.  To make this problem 
> harder, the condition changes when you reverse the mismatch condition (try 
> setting the laptop to full and the switch to half).  Lastly, I'm trying to 
> keep the false positive rate as low as possible.  I'm of the option that 
> its better to fail to detect the condition than it is to falsely report it 
> (and have techs running around trying to find a non-existent problem).
>
> So all these things combined make detecting duplex mismatches a hard 
> problem.  Right now, you still need someone to interpret the results to 
> determine what the tool says.  But at least you have some data to work from.
>
> Hopefully I can get a better detection algorithm out by the end of the 
> year.  Keep your fingers crossed.
>
> Rich
>
> [snip snip snip]

------------------------------------



Richard A. Carlson                              e-mail: 

Network Engineer                                phone:  (734) 352-7043
Internet2                                       fax:    (734) 913-4255
1000 Oakbrook Dr; Suite 300
Ann Arbor,  MI  48104