Results 1 to 20 of 20

Thread: Need Help on TCP/IP Analyzer

  1. #1

    Question Need Help on TCP/IP Analyzer

    I use AUSU ADSL ROUTE.
    My advised speed is 2048 up/ 640 down.

    I use WINDOWS 98. I have set the MTU To 1492.

    After made a TCP/IP Analyzer on SpeedGuide.net and a Tweak Test on DSLreports.com, I have two questions:

    First, on DSLreports.com, the MTU is 1492, same as my setting, but on SpeedGuide, the MTU is 1452, diffrent from my setting. Why?

    Second, on DSLreports.com, the RWIN is ok, but on SpeedGuide, it advise me consider changing RWIN to a multiple of MSS.

    How do I to do? Could anyone can give me a explanation on the TCP/IP Analyzer result? And How to tweak my TCP/IP setting?

    Thanks a lot!

    Below is my adsl route status page and the TCP/IP Analyzer result:

    *****My adsl route status page********

    Channel 1 : open for IP, sent 411, received 367
    PPPoE setting : port 0 vpi 0 vci 35 acname "" servicename ""
    Transport : IP
    Our login protocol : CHAP
    Our login name : xxxxxxxxxx
    Interface : 1 (0a:e0:18:1f:16:48)
    MAC address : 06:e0:18:1f:16:48
    Phase : Network
    LCP : state : Opened
    LCP : local options : MRU=1500 magic=0
    LCP : remote options : MRU=1492 magic=1552962074 auth=0xc223
    PAP : login as user : 'xxxxxxxxxx'
    CHAP : login as user : 'xxxxxxxxxx'
    IPCP : state : Opened
    IPCP : local options : IP address=xx.xxx.xxx.xxx
    IPCP : local options : primary DNS server=yyy.yy.yyy.yy
    IPCP : local options : secondary DNS server=zzz.zz.zzz.zz
    IPCP : remote options : IP address=xx.xxx.xxx.x

    ************End of ADSL route status page***********


    ***********TCP/IP Analyzer result***************

    TCP options string = 020405840101080a000000000000000001010402

    MTU = 1452
    MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput.

    MSS = 1412
    Maximum useful data in each packet = 1412, which is equal to MSS.
    MSS is not fully optimized for broadband (although it might work well for slower connections). Consider increasing your MTU value.

    Default Receive Window (RWIN) = 46720
    RWIN Scaling (RFC1323) = 0 bits
    Unscaled Receive Window = 46720
    For optimum performance, consider changing RWIN to a multiple of MSS.
    Other values for RWIN that might work well with your current MTU/MSS:
    519616 (MSS x 46 * scale factor of 8)
    259808 (MSS x 46 * scale factor of 4)
    129904 (MSS x 46 * scale factor of 2)
    64952 (MSS x 46)

    bandwidth * delay product:
    Your RcvWindow limits you to: 1868.8 kbps (233.6 KBytes/s) @ 200ms
    Your RcvWindow limits you to: 747.52 kbps (93.44 KBytes/s) @ 500ms

    MTU Discovery (RFC1191) = ON

    Time to live left = 110 hops
    TTL value is ok.

    Timestamps (RFC1323) = ON
    Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.

    Selective Acknowledgements (RFC2018) = ON

    IP type of service field (RFC1349)= 00000000

    ********End of TCP/IP Analyzer result***********

  2. #2
    Elite Member Lobo's Avatar
    Join Date
    Nov 2000
    Location
    Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves
    Posts
    17,660
    I have sent for PPPoE man hold on

  3. #3
    Advanced Member Bob Carrick's Avatar
    Join Date
    Sep 2001
    Location
    Ottawa, ON, Ca
    Posts
    705
    Both tweaking sites have different ideas of what tweaks are the best, you really need to try for yourself. What PPPoE application are you using to conenct to the internet with?
    Bob
    www.carricksolutions.com - The largest PPPoE / Broadband Help Website.

  4. #4
    Elite Member Lobo's Avatar
    Join Date
    Nov 2000
    Location
    Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves
    Posts
    17,660
    I have always believed that DSLR somehow reads what is in registry instead of what is being sent out (Analyzer), try it , and Bob, if you know RWIN that works good with MTU 1492, please tell me so I can include it

  5. #5
    Advanced Member Bob Carrick's Avatar
    Join Date
    Sep 2001
    Location
    Ottawa, ON, Ca
    Posts
    705
    I'm not a tweaker so I can't answer the RWIN question.
    Bob
    www.carricksolutions.com - The largest PPPoE / Broadband Help Website.

  6. #6
    TCP/IP Dude rmrucker's Avatar
    Join Date
    Sep 2000
    Location
    Long Beach, CA, USA
    Posts
    896
    It is distincly rare that both sites report a different MTU. Can you post a link to your DSLR test? Also, please try a third site here:
    http://whisper.cs.utk.edu:7123/

    Best two out of three wins!

    Also, the RWIN values have been hotly debated between these two sites ad nauseum. Try it both ways and use whatever gives you the best speed. Whenever two sides take strongly opposite opinions, it is clear that NEITHER side is correct...
    _______________________________________________

    As I have thoroughly investigated both the Tweak Tester and the TCP Analyzer, I can tell you that by design BOTH tests are supposed to sniff the Syn packet from your computer to read the "MSS" value. Neither the Tweak Tester at DSLR nor the TCP Analyzer here obtain any information from your registry. Since both tests determine the MSS the same way, this value should be the same on both tests.

    The "MTU" value reported on the DSLR Tweak Test is based on the size of the largest packet that is received by your computer while they upload 146,000 bytes on to your computer. Under almost all instances, this numbers will differ from the MSS by 40.

    I believe that the "MTU" on the TCP Analyzer is calculated by simply adding 40 to the MSS value in the Syn packet. However, Philip does measure the "data field" of a full size TCP/IP packet -- and this is reported under the MSS data in this line:

    "Maximum useful data in each packet "

    The TCP Analyzer is not designed to measure download efficiency, so the data field is measured during the upload of a much smaller amount of data -- around 7000 bytes.

    I hope this is instructive.

  7. #7
    Advanced Member Bob Carrick's Avatar
    Join Date
    Sep 2001
    Location
    Ottawa, ON, Ca
    Posts
    705
    Yes the MTU is very odd, the URL for the DSLreports test results would help.
    Bob
    www.carricksolutions.com - The largest PPPoE / Broadband Help Website.

  8. #8
    Elite Member Lobo's Avatar
    Join Date
    Nov 2000
    Location
    Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves
    Posts
    17,660
    See I know which thread you are speaking of and I was wrong, I will leave that up to the Pro's , to get back to registry reading, their is no other way to get RWIN but read whats in registry, if you are on Win 2000 or XP, Analyzer reads Tcp Recieve Window, type any number in RWIN box on another application and that is what DSLR shows

  9. #9
    TCP/IP Dude rmrucker's Avatar
    Join Date
    Sep 2000
    Location
    Long Beach, CA, USA
    Posts
    896
    Lobo, I disagree. The RWIN value is NOT read out of the registry by either of these two tests. The only site I know that reads the RWIN out of your registry is PCPitstop. And to do this, you must allow them to download an ActiveX control that gives them the power to read your registry. There is no other way.

    Both the Tweak Tester and the TCP Analyzer are calculating the RWIN from the data in the TCP/IP three-way handshake.

  10. #10
    Elite Member Lobo's Avatar
    Join Date
    Nov 2000
    Location
    Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves
    Posts
    17,660
    URL for DSLR, take tweak test:


    http://www.dslreports.com/tools

  11. #11
    Originally posted by Bob Carrick
    What PPPoE application are you using to conenct to the internet with?
    My ADSL Route support route pppoe with NAT. I don't use any pppoe software. I let the adsl route dial.

  12. #12
    [QUOTE]Originally posted by rmrucker
    [B]It is distincly rare that both sites report a different MTU. Can you post a link to your DSLR test? Also, please try a third site here:
    http://whisper.cs.utk.edu:7123/

    1. Here is the link to DSLR test
    http://monitor.dslreports.com/tweak/...ia=routerpppoe


    2. here is the result on http://whisper.cs.utk.edu:7123/

    TCP/Web100 bandwidth test v4.3
    click START to begin
    running 10s outbound test... 160 Kbs outbound
    running 10s inbound test... 472 Kbs inbound

    web100 Connection Variables:

    Round Trip times were sampled 223 times
    for a total time of 133720 millisecs
    giving an average RTT of: 599.0 millisecs(0.599 secs)
    You received 459 packets
    of size 1412 from the remote host
    and it took a total of 11370.0 millisecs
    Maximum Expected Bandwidth: 623 Kbs
    Good Data Stream--No retransmits!
    You are advertising a window of 46720 bytes
    The remote host is advertising a window of 186880 bytes
    The Remote Host has a send buffer of 128000 bytes
    and a receive buffer of 128000 bytes
    Buffer sizes are very important in determining the
    advertised window sizes. Larger window sizes can
    help increase thruput. If your window is smaller
    than the remote host, your should investigate
    increasing your socket buffer sizes.

    web100 reports Tweakable Settings as:
    RFC 2018 Selective Acknowledgment: ON
    RFC 1323 Time Stamping: OFF
    RFC 1323 Window Scaling: OFF


    WEB100 Kernel Variables:
    BytesRetrans: 0
    CountRTT: 223
    CurrentCwnd: 48008
    CurrentMSS: 1412
    CurrentRTO: 810
    CurrentRwinRcvd: 46720
    CurrentRwinSent: 5840
    CurrentSsthresh: 2147482560
    DSACKDups: 0
    DataBytesOut: 648108
    DataPktsIn: 0
    DataPktsOut: 459
    DupAcksIn: 0
    MaxCwnd: 48008
    MaxMSS: 1412
    MaxRTO: 3000
    MaxRTT: 4700
    MaxRwinRcvd: 46720
    MaxRwinSent: 5840
    MaxSsthresh: 0
    MinMSS: 1412
    MinRTO: 790
    MinRTT: 550
    PktsIn: 222
    PktsOut: 459
    PktsRetrans: 0
    Recoveries: 0
    SACKEnabled: 3
    SACKsRcvd: 0
    SmoothedRTT: 580
    SumCwndAtRecov: 0
    SumRTT: 133720
    Timeouts: 0
    TimeoutsAfterFR: 0
    TimestampsEnabled: 0
    WinScaleRcvd: 0
    WinScaleSent: 0
    Rcvbuf: 128000
    Sndbuf: 128000

  13. #13
    Advanced Member Bob Carrick's Avatar
    Join Date
    Sep 2001
    Location
    Ottawa, ON, Ca
    Posts
    705
    That leads me to beleive that your modem is set to 1452 then, and your Ethernet card is set to 1492.
    Bob
    www.carricksolutions.com - The largest PPPoE / Broadband Help Website.

  14. #14
    Originally posted by Bob Carrick
    That leads me to beleive that your modem is set to 1452 then, and your Ethernet card is set to 1492.
    But my ADSL ROUTE STATUS PAGE displays

    LCP : local options : MRU=1500 magic=0
    LCP : remote options : MRU=1492 magic=1552962074 auth=0xc223


    What is MRU?

  15. #15
    Can I take MRU as MTU? if it does, my NIC's MTU is 1492, and the ADSL MODEM'S is 1500.

  16. #16
    TCP/IP Dude rmrucker's Avatar
    Join Date
    Sep 2000
    Location
    Long Beach, CA, USA
    Posts
    896
    Well, there are a couple of weird things. Your advertized MSS is agreed upon by all three tests -- the MSS field in your SYN packet is clearly set at 1412. First, the SG TCP Analyzer displays the SYN packet TCP Options string, and the MSS field is "0x0584" = 1412. The three tests report it here:
    ___________________________

    SG: MSS = 1412
    Maximum useful data in each packet = 1412, which is equal to MSS.

    DSLR: MSS requested: 1412

    Web100: MaxMSS: 1412
    ____________________________

    Then, the size of packets your computer downloaded (the MTU) is the same on all three tests:
    ____________________________

    SG: MTU = 1452

    DSLR: Max packet sent (MTU): 1452

    Web100: You received 459 packets of size 1412 from the remote host...
    If the data in each packet is 1412 and the headers are 40, the MTU is 1452.
    ____________________________

    The only thing where the "MTU" appears to be inconsistent is here:

    DSLR: Max packet recd (MTU): 1492

    This means is that YOUR computer was able to SEND packets that are 1492 bytes in size -- but that is not what you were able to receive. This is likely because your ROUTER is assymetrically modifying the MSS field of the SYN and SYN,ACK packets.

    It is changing the outgoing SYN packet to an MSS of 1412, while it is allowing the incoming SYN,ACK packet to either retain an MSS of 1460, or it is cutting down to 1452. Either way the result would be the same -- you are on PPPoE.

    Test your connection with RASPPPoE and no router and the "problem" will disappear. Also, try setting the MTU of you NIC to 1430 and retest at DSLR.
    ____________________________________________________

    There is one more thing that is weird about your tests -- the TimeStamps results. Here is what the tests say:
    _____________________________

    SG: Timestamps (RFC1323) = ON
    Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.

    DSLR: RFC1323 Time Stamping: ON
    --req 1323 ws/ts: N/Y

    Web100: RFC 1323 Time Stamping: OFF
    -- TimestampsEnabled: 0
    _____________________________

    Now, Web100 previously stated that their test was unreliable in identifying the TCP1323 options -- but that warning no longer is present on their page. So, perhaps you turned off TimeStamps between tests??

    However, that is not the only weird part. Notice the SpeedGuide test results:

    MSS = 1412
    Maximum useful data in each packet = 1412, which is equal to MSS.
    Timestamps (RFC1323) = ON
    Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.

    You will note -- even though Timestamps are reportedly ON, they were not used -- because the MSS size and the data size are the same -- and they should differ by 12.

    So... I suspect your router might be turning OFF time stamps in the returning SYN,ACK packet -- that would explain all test results.

  17. #17
    When I set my ADSL Modem to Routed PPPoE(NAT ROUTER), what the Modem packed is a IP package without IP heard, so the result is 1452

    When I set my ADSL Modem to PPPoE Relay, and use raspppoe, what the Modem packed is a PPPoE package(this package has included a IP heard), so the result is 1492.

    Is it right?

  18. #18
    TCP/IP Dude rmrucker's Avatar
    Join Date
    Sep 2000
    Location
    Long Beach, CA, USA
    Posts
    896
    I am not sure I understand your terminology. I suspect "heard" must mean "header". And perhaps you could tell us a little more about the "ADSL Route" -- is this a combined modem-router?

    It looks to me like your ADSL Route is incorrectly processing your SYN packets on PPPoE.

    Are you saying yhat your MTU when using RASPPPoE is 1492?

  19. #19
    Originally posted by rmrucker
    I am not sure I understand your terminology. I suspect "heard" must mean "header". And perhaps you could tell us a little more about the "ADSL Route" -- is this a combined modem-router?

    It looks to me like your ADSL Route is incorrectly processing your SYN packets on PPPoE.

    Are you saying yhat your MTU when using RASPPPoE is 1492?

    I am sorry for my mistake. "heard " should be "header".

    These are some M6000EV ADSL Router Specification.

    Multi-PVC, up to 16 channels, individually supporting bridged or routing channel

    ADSL Specification
    Line Coding Discrete Multi-Tone (DMT)
    Standard Compliant Full rate ADSL ANSI T1.413 Issue 2
    ITU G.992.1 (G.dmt) Annex A, B and C
    Splitterless G.992.2 (G.lite)
    ITU G.994.1, G.996.1
    Data Rate Maximum transmission rate: Downstream up to 8 Mbps, and Upstream up to 800 kbps
    Rate Adaption Data rate auto-negotiate in 32 kbps increments

    ATM specification
    ATM Adaptation Layer Support AAL5, AAL2
    VCs Support 16 Permanent Virtual Circuits (PVCs)
    Service Class UBR, CBR, rt-VBR, nrt-VBR
    OAM ITU-T I.610 OAM Principles & Functions (include F4/F5)

    Basic Protocol & RFC
    RFC 1483 Multiple protocol encapsulation over AAL5:
    Support Logical Link Control (LLC) encapsulation
    Support VC-based multiplexing
    Support Bridged and Routing
    RFC 2364 PPP over AAL5:
    Support LLC encapsulation
    Support VC-based multiplexing
    Support VPN (PPTP)
    RFC 2516 PPP over Ethernet Relay, PPP over Ethernet
    RFC 1577 Classical IP & ARP over ATM
    RFC 1661 PPP Link Control Protocol (LCP)
    RFC 1332 Internet Protocol Control Protocol (IPCP)
    RFC 1334 PPP Authentication Protocol (PAP)
    RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP)
    RFC 2433 Microsoft PPP CHAP extensions
    RFC 1144 V. Jacobson compression support.

    Bridged Function
    IEEE802.1d Transparent bridge with spanning tree support.

    Routing Function
    RFC 792 Internet Control Message Protocol (ICMP)
    RFC 1058, 1723 Routing Information Protocol (RIP, RIPv2)
    RFC 1631 Network Address Translator (NAT)
    Support Port mapping and IP mapping
    Support FTP, mail, Telnet, Http
    Support TCP, UDP, ICMP
    Support NetMeeting 3.0 and 3.01
    Support Real Player, ICQ, mIRC and games ...
    RFC 2131 Dynamic Host Configuration Protocol (DHCP)
    Support DHCP server and client
    Support DHCP relay
    VPN Virtual Private Networks
    Support Point-to-Point Tunneling Protocol (PPTP)
    IP Packet Filter Configurable filter rules

    If I set to routing channel, I don't need any PPPoE software, just like using a NAT Router.

    If I set to bridged channel, I need a PPPoE software.

    When I use routing channel, SG tell me MTU is 1452

    When I use set bridged channel, I use RASPPPOE. SG Tell me MTU is 1492.
    Last edited by jerryleo; 03-21-02 at 05:23 AM.

  20. #20

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •