Skip to Content.
Sympa Menu

ndt-users - Re: how to find the 10 Mbps Ethernet in the path?

Subject: ndt-users list created

List archive

Re: how to find the 10 Mbps Ethernet in the path?


Chronological Thread 
  • From: Larry Vaden <>
  • To: Rich Carlson <>
  • Cc:
  • Subject: Re: how to find the 10 Mbps Ethernet in the path?
  • Date: Sun, 31 Oct 2010 16:04:52 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=p//cmMRmo+3HT13RsZSvdJ+ADfMiH/0SJDUJYxEG5Idjj04fnW/q9MR/ZMzd6yQAWM SqbGYgOlrwL2Bc+Fz5gZxs5oYxK7/XUOHbavDOMxYlSs8iK9kAUQ/lvTQU0itNVZSBuY adnH0Dk0kCj/GEBU/UatwdLIl9WXzu7Lwo2xQ=

Hi Rich,

Thanks for your reply.

The detection of the 10 Mbps Ethernet Link is uniform within our rural
wireless network and therefore I believe you have hit the nail on the
head.

In particular, the submitted NDT test transcript was for a MikroTik
access point running b/g and the client radio is a Ubiquiti 802.11n
NanoBridge M2.

We have yet to put up an NDT server on our rural network but I will
try to get this done in time for Thanksgiving.

Again, thanks for your reply.

Kind regards/ldv

On Sun, Oct 31, 2010 at 3:53 PM, Rich Carlson
<>
wrote:
> Larry;
>
> I notice the 802.11b/g access point in what appears to be a path from the
> 7206 to the client PC.  Is the client connecting at b (11 Mbps) or g (34
> Mbps) rates?  Also wifi connections typically achieve about 50% of the
> access links capacity and that depends on may factors.
>
> As background, the NDT system was originally designed to operate in a
> university campus environment.  One of the design considerations was that
> only common network link technologies (10/100/1000 Ethernet, DS3, T1,
> OC-3/12/48/192) would be used.  I also assumed that the use of bonded links
> or subrate links would be limited so they aren't accounted for.
>
> The NDT server uses pkt-pair timings to determine the bottleneck link speed
> and technology.  Since the above assumption was used, individual timing
> measurements were quantized into a link-type bin instead of a measured speed
> bin.  Measurements are rounded up to the next quanta and the bin values are
> printed in the web100srv.log file.
>
> In this case, the 10 Mbps Ethernet message could mean that the Wifi link is
> operating at 802.11b rates.  Another option is to use one of the pkt-pair
> measurement tools to probe the path from your NDT server toward the client.
>  That might tell you something.
>
> Regards;
> Rich
>
> On 10/31/2010 1:05 PM, Larry Vaden wrote:
>>
>> Hello fellow ndt-users,
>>
>> This customer is connected to a Cisco 7206 with an upstream
>> fiber-based DS3 connection.
>>
>> How do we go about finding the "10 Mbps Ethernet" short of visiting
>> each of the rural pops in the path and running NDT from said pops?
>>
>> kind regards/ldv
>>
>> Larry Vaden, CoFounder
>> Internet Texoma, Inc.
>> Serving Rural Texomaland Since 1995
>> We Care About Your Connection!
>>
>>
>> Cisco 7206
>> |
>> |
>> HQ MikroTik distribution router
>> |
>> |
>> wireless backbone link
>> |
>> |
>> DD MikroTik distribution router
>> |
>> |
>> wireless backbone link
>> |
>> |
>> PW MikroTik distribution router
>> |
>> |
>> MikroTik 802.11b/g Access Point
>> |
>> |
>> Client radio (Ubiquiti NanoBridge M2)
>> |
>> |
>> Client Network
>> |
>> |
>> Client PC
>>
>> Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
>> checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
>> running 10s outbound test (client-to-server [C2S]) . . . . . 1.09Mb/s
>> running 10s inbound test (server-to-client [S2C]) . . . . . . 7.99Mb/s
>> The slowest link in the end-to-end path is a 10 Mbps Ethernet subnet
>>  [S2C]: Packet queuing detected
>>
>>
>> WEB100 Enabled Statistics:
>> Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
>> checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
>> running 10s outbound test (client-to-server [C2S]) . . . . . 1.09Mb/s
>> running 10s inbound test (server-to-client [S2C]) . . . . . . 7.99Mb/s
>>
>>        ------  Client System Details  ------
>> OS data: Name = Windows XP, Architecture = x86, Version = 5.1
>> Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_04
>>
>>        ------  Web100 Detailed Analysis  ------
>> 10 Mbps Ethernet link found.
>> Link set to Full Duplex mode
>> No network congestion discovered.
>> Good network cable(s) found
>> Normal duplex operation found.
>>
>> Web100 reports the Round trip time = 240.01 msec; the Packet size = 1460
>> Bytes; and
>> No packet loss - but packets arrived out-of-order 0.08% of the time
>> S2C throughput test: Packet queuing detected: 50.56%
>> This connection is receiver limited 40.93% of the time.
>> This connection is sender limited 52.17% of the time.
>> This connection is network limited 6.9% of the time.
>>
>> Web100 reports TCP negotiated the optional Performance Settings to:
>> RFC 2018 Selective Acknowledgment: ON
>> RFC 896 Nagle Algorithm: ON
>> RFC 3168 Explicit Congestion Notification: OFF
>> RFC 1323 Time Stamping: OFF
>> RFC 1323 Window Scaling: ON
>>
>> Server 'ndt.anl.gov' is probably behind a firewall. [Connection to the
>> ephemeral port failed]
>> Client is probably behind a firewall. [Connection to the ephemeral port
>> failed]
>> Packet size is preserved End-to-End
>> Server IP addresses are preserved End-to-End
>> Information: Network Address Translation (NAT) box is modifying the
>> Client's IP address
>>        Server says [aaa.bbb.126.34] but Client says [192.168.1.101]
>>
>>
>> WEB100 Kernel Variables:
>> Client: localhost/127.0.0.1
>> CurMSS: 1460
>> X_Rcvbuf: 16777216
>> X_Sndbuf: 16777216
>> AckPktsIn: 3759
>> AckPktsOut: 0
>> BytesRetrans: 0
>> CongAvoid: 0
>> CongestionOverCount: 0
>> CongestionSignals: 0
>> CountRTT: 3756
>> CurCwnd: 327040
>> CurRTO: 452
>> CurRwinRcvd: 262144
>> CurRwinSent: 5888
>> CurSsthresh: -616
>> DSACKDups: 0
>> DataBytesIn: 0
>> DataBytesOut: 11248720
>> DataPktsIn: 0
>> DataPktsOut: 7678
>> DupAcksIn: 3
>> ECNEnabled: 0
>> FastRetran: 0
>> MaxCwnd: 327040
>> MaxMSS: 1460
>> MaxRTO: 868
>> MaxRTT: 488
>> MaxRwinRcvd: 262144
>> MaxRwinSent: 5888
>> MaxSsthresh: 0
>> MinMSS: 1460
>> MinRTO: 264
>> MinRTT: 64
>> MinRwinRcvd: 262144
>> MinRwinSent: 5840
>> NagleEnabled: 1
>> OtherReductions: 3
>> PktsIn: 3759
>> PktsOut: 7678
>> PktsRetrans: 0
>> RcvWinScale: 8
>> SACKEnabled: 3
>> SACKsRcvd: 0
>> SendStall: 0
>> SlowStart: 0
>> SampleRTT: 232
>> SmoothedRTT: 228
>> SndWinScale: 3
>> SndLimTimeRwin: 4590486
>> SndLimTimeCwnd: 773620
>> SndLimTimeSender: 5850347
>> SndLimTransRwin: 1786
>> SndLimTransCwnd: 81
>> SndLimTransSender: 1867
>> SndLimBytesRwin: 10372540
>> SndLimBytesCwnd: 731760
>> SndLimBytesSender: 144420
>> SubsequentTimeouts: 0
>> SumRTT: 901464
>> Timeouts: 0
>> TimestampsEnabled: 0
>> WinScaleRcvd: 3
>> WinScaleSent: 8
>> DupAcksOut: 0
>> StartTimeUsec: 707808
>> Duration: 11216397
>> c2sData: 3
>> c2sAck: 3
>> s2cData: 4
>> s2cAck: 3
>> half_duplex: 0
>> link: 10
>> congestion: 0
>> bad_cable: 0
>> mismatch: 0
>> spd: 8.02
>> bw: 46.41
>> loss: 0.000001000
>> avgrtt: 240.01
>> waitsec: 0.00
>> timesec: 11.00
>> order: 0.0008
>> rwintime: 0.4093
>> sendtime: 0.5217
>> cwndtime: 0.0690
>> rwin: 2.0000
>> swin: 128.0000
>> cwin: 2.4951
>> rttsec: 0.240006
>> Sndbuf: 16777216
>> aspd: 0.00000
>> CWND-Limited: 325.54
>> minCWNDpeak: 265720
>> maxCWNDpeak: 327040
>> CWNDpeaks: 3
>>
>> The theoretical network limit is 46.41 Mbps
>> The NDT server has a 8192.0 KByte buffer which limits the throughput to
>> 533.32 Mbps
>> Your PC/Workstation has a 256.0 KByte buffer which limits the throughput
>> to
>> 8.33 Mbps
>> The network based flow control limits the throughput to 10.39 Mbps
>>
>> Client Data reports link is 'Ethernet', Client Acks report link is
>> 'Ethernet'
>> Server Data reports link is 'T3', Server Acks report link is 'Ethernet'
>>
>



Archive powered by MHonArc 2.6.16.

Top of Page