ndt-users list created

[Matthew J Zekauskas <>]

On 3/6/2008 12:04 AM, 

 wrote:
> I'm troubleshooting data transfers between New Jersey and California over 
> internet2.  The slowest link is 155 Mbps, rtt is 90 ms, servers and switches 
> are gigabit.
>
> Tuning tcp buffers only gets the throughput to 11.9 Mbits/sec.  If I change 
> the switch port to 100 Full, the throughput increases to 84.4 Mbits/sec.
>
> ndt reports packet loss and duplicate acks when the connection is gigabit, 
> the 100 full connection has no packet loss.
>
> The relevant ndt output is below.  iperf also backs up these results.
>
> Is there a known problem with gig switch negotiation?  No tcp buffer setting 
> improves the performance when gigabit.

Rich is away traveling, and might have a better answer to your question, 
but let me try...

So, when you "change the switch port to 100 full": is this at the last 
hop, between a switch and a "PC"?  If so, are you forcing both sides 
(the switch and the PC) to 100 full?

If not, then I think that there may be a problem with autonegotiation 
using your hardware.

If so... the bottleneck link is 155 Mbps.  When the gigabit-connected PC 
ramps up, it will start sending longer and longer trains of back-to-back 
packets at 1000 Mbps, which the device feeding in to the bottleneck link 
(and intermediate devices)  would have to queue.  It's possible that one 
of these devices cannot handle the number of packets that get blasted at 
it back-to-back.  An inexpensive gigabit switch might be such a device.

Looking at detailed NDT results might give us some clues.

Do you know if the 155 Mbps link is on your side or the California side?

There are also NDT servers located within Internet2; if you test to one 
of them I might be able to look at the results (but I don't want to get 
your hopes up too much :).

<http://ndt.newy.net.internet2.edu:7123/>  is the closest NDT server 
within Internet2 to Rutgers.

You might also try an NPAD test, which does complementary testing to 
NDT, looking to see if a device in the path has enough buffer space. 
There is one that I hope is configured correctly at 
<http://ndt.newy.net.internet2.edu:8000/>.  (Ignore the fact that it 
claims to be in Chicago.)  Use 70mS for the target RTT (basically 
cross-US), and 150mbps for the target speed, and let's see what that 
says.  That one gives a URL that has the results, send it to me.
Also try the one at the Internet2 office: <http://ndt.internet2.edu:8200/>

If the California school is connected via CENIC, the closest one there 
is <http://ndt.losa.net.internet2.edu:7123/>; you can test "the other 
way"-- the california side to the center.

It would also be helpful if you could tell us the devices at both sides; 
are they PCs?  Do you have the operating system and version?

Thanks,

--Matt


> Thanks
>
> ndt:
>
> gigabit connection:
>
> running 10s outbound test (client to server) . . . . .  13.67 Mb/s
> running 10s inbound test (server to client) . . . . . . 14.30 Mb/s
>
> There were 7 packets retransmitted, 178 duplicate acks received, and 245 SACK 
> blocks received
> Packets arrived out-of-order 2.64% of the time.
> The connection stalled 1 times due to packet loss.
> The connection was idle 0.30 seconds (3.00%) of the time.
>
>
> 100 full connection:
>
> running 10s outbound test (client to server) . . . . .  11.80 Mb/s
> running 10s inbound test (server to client) . . . . . . 20.46 Mb/s
>
> No packet loss was observed.
>
>
> iperf:
>
> gigabit:
>
> [  3]  0.0-60.1 sec  85.3 MBytes  11.9 Mbits/sec
>
>
> 100 full:
>
> [  3]  0.0-60.2 sec    606 MBytes  84.4 Mbits/sec