Results 1 to 12 of 12

Thread: Are Advertised Speeds A Total Hoax? 4096 kbps does not equal 230 kbps!!!

  1. #1
    Junior Member
    Join Date
    Nov 2006
    Posts
    6

    Are Advertised Speeds A Total Hoax? 4096 kbps does not equal 230 kbps!!!

    First...a quick rant. How can ADSL providers like BellSouth and Telkom sell you upgrade packages for faster download and upload rates when THEY KNOW that the average consumer will never see anything close to those speeds. The people who visit this forum are familiar with things such as regedit, tcp/ip, MTU, etc... How about all of the people who just want a fast internet and are suckered into paying crazy rates for slower than advertised speeds!

    Ok...

    I have tried everything I can think of. I am on a business class ADSL line with PROMOTED rates of 4096/384 kbps (download/upload). The connection is a PPPoe LLC connection.

    Router is a Marconi WiFi (Telkom). Internal router settings are matching to the results and registry information... I have also tried other routers to check for problems and get the same results...

    For starters...I reinstalled TCP/IP to start with a fresh slate after using many different optimizers. Downloaded the TCP/IP Optimizer...followed it step by step:

    Here are the stats from your analyzer page:

    MTU = 1472
    MSS = 1432
    Default TCP Receive Window (RWIN) = 524288
    RWIN Scaling (RFC1323) = 2 bits (scale factor of 4)
    Unscaled TCP Receive Window = 32768
    MTU Discovery (RFC1191) = ON
    Time to live left = 57 hops
    TTL value is ok.
    Timestamps (RFC1323) = OFF
    Selective Acknowledgements (RFC2018) = ON
    IP type of service field (RFC1349) = 00000000 (0)

    OK...
    Here is also a screenshot of the other various settings within cablenut:


    Latency is average 372ms...with a Max of 461ms
    Largest non-fragmented packet is 1463...so MTU is set at 1492.

    Did many speed tests and took the median average:

    Download: 216 kbps
    Upload: 232 kbps

    Keep in mind that the rate should be:

    Download: 4096 kbps
    Upload: 384 kbps

    Needless to say, when you have to pay almost $200 for this kind of access in South Africa, you expect to get what you pay dearly for. By the way, Bandwidth restrictions are not an issue on this ADSL line...

    OS: Windows XP Pro (SP2)

    I would really appreciate any help that someone could give. Understanding that your time isn't free, I'll be glad to send the person who solves this issue $50 for figuring out what obscure setting is causing this pathetic performance. I know that isn't much, but it will at least reimburse you for some of your time.

    I am not looking for total perfection...but certainly I should be getting much better download rates than those above...90% of the advertised rate would be TOTALLY WONDERFUL....

    Thanks for the help in advance. I truly appreciate it.

    -Adam

    P.S. I tried to give all of the necessary info to aid in solving this dilemna...however, should you need ANY other info, I will get it to you as fast as is humanly possible!!!

  2. #2
    Elite Member trogers's Avatar
    Join Date
    Jan 2005
    Location
    Bangkok, Thailand
    Posts
    12,323
    Quote Originally Posted by Hoaxed
    MTU = 1472
    MSS = 1432

    Default TCP Receive Window (RWIN) = 524288
    RWIN Scaling (RFC1323) = 2 bits (scale factor of 4)
    Unscaled TCP Receive Window = 32768

    Latency is average 372ms...with a Max of 461ms
    Largest non-fragmented packet is 1463...so MTU is set at 1492.

    Download: 216 kbps
    Upload: 232 kbps

    Keep in mind that the rate should be:
    Download: 4096 kbps
    Upload: 384 kbps

    OS: Windows XP Pro (SP2)
    First and foremost, your RWIN is 524288. This is the same as your Cablenut setting for DefaultReceiveWindow, which is an AFD parameter.

    Your RWIN is not following the TCP parameters, GlobalMax and TcpReceiveWindow, as set in Cablenut.

    In XP SP2, the AFD parameter, DefaultReceiveWindow, takes overriding precedence in establishing the TCP handshake. In other OS, this is not the case.

    DefaultReceiveWindow in Cablenut was only intended as an internal buffer for running applications and not as a TCP buffer in an internet connection. This is why it is calculated based on data processing memory modules:

    Bandwidth x 1024 divided by 8 = 4096 x 1024 / 8 = 524288

    Your Global Max and TcpReceiveWindow of 204776 is calculated as a multiple of MSS (1432)

    204776 / 1432 = 143

    and it allows a max latency of only 400ms.

    RWIN x 8 / Bandwidth = 204776 x 8 / 4096 = 400ms

    Your MSS setting (TcpRecv/SendSegmentSize) in Cablenut is 1460 which is wrong. It should be 1432.

    Thus the critical values used in Cablenut are all wrong.

    The first step for you is to make DefaultReceiveWindow, GlobalMax and TcpReceiveWindow all follow the same RWIN. This RWIN should be 252032

    RWIN = 4096 * 480 / 8 = 245760

    Round it to an even multiple of MSS,

    245760/1432 = 171.6

    We recommend to round it to MSS x 176 = 252032

    Use 1432 in both TcpRecv/SendSegmentSize.

    After using these settings, test your speed.

    Next get into your router setup and see if you can increase your MTU to 1492. If it is possible to raise your MTU to 1492, then RWIN should be 255552 and packet size 1452.
    Last edited by trogers; 11-02-06 at 05:52 AM.

  3. #3
    Junior Member
    Join Date
    Nov 2006
    Posts
    6
    I appreciate your fast response to this thread.

    Thank you for pointing out the problems with the setup.

    I implemented all of the changes...

    The first step for you is to make DefaultReceiveWindow, GlobalMax and TcpReceiveWindow all follow the same RWIN. This RWIN should be 252032
    Did that...

    Use 1432 in both TcpRecv/SendSegmentSize.
    And that...

    I made no additional changes...applied to registry...and restarted the machine.

    I then ran 10 speed tests from the same server and took a median average.
    Download speed: 171 kbps
    Upload speed: 131 kbps

    Couldn't get to the analyzer for some reason...only showing the home page of the site now...

    To answer your question about the router:
    This is the strange thing....the router's default settings are:
    MRU 1492
    MTU 1492
    MSS 1432

    Those are also the current settings for the router. What I don't understand is why the analyzer tool is returning a value of MTU=1472????
    (The only thing I could figure is that 1432 + 40 = 1472...and since most systems are set at MSS=1452 then MTU=1452+40=1492 (for PPPoe + 8 bits equals 1500)...but certainly this isn't how this analyzer is calculating that number is it???)

    So in essense...I am not sure how MTU is being reported as 1472 if the router says it is 1492 and using TCP/IP Optimizer I also set the value to 1492...could this be part of the problem?

    Thanks again to all who have worked on this issue...looking forward to "closer to advertised" speeds!!!

  4. #4
    Elite Member trogers's Avatar
    Join Date
    Jan 2005
    Location
    Bangkok, Thailand
    Posts
    12,323
    I would assume you surf to the US often. Do the nitro test and check your present latency and other conditions of your line:

    http://nitro.ucsc.edu/

    The test report is a pop-up from the 'Statistics' button.

    You should test your speed at a server closest to you. Testing at a faraway site will always give you a low result due to high latency.

  5. #5
    Junior Member
    Join Date
    Nov 2006
    Posts
    6
    This is what I get when I attempt to run the test:

    TCP/Web100 Network Diagnostic Tool v5.4.11
    click START to begin
    Connected to: nitro.ucsc.edu -- Using IPv4 address
    Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
    checking for firewalls . . . . . . . . . . . . . . . . . . . Done
    running 10s outbound test (client-to-server [C2S]) . . . . . 278.0kb/s
    running 10s inbound test (server-to-client [S2C]) . . . . . . 10.27kb/s
    Protocol error!

    click START to re-test

  6. #6
    Elite Member trogers's Avatar
    Join Date
    Jan 2005
    Location
    Bangkok, Thailand
    Posts
    12,323
    This is just the Summary.

    After the nitro test has been completed. you have to click on the 'Statistics' button and the report will pop-up.

    For your info, one the international line through Africa is experiencing very high latency (>600ms) and packet losses:

    http://www.internettrafficreport.com/europe.htm

  7. #7
    Junior Member
    Join Date
    Nov 2006
    Posts
    6
    Thanks for the info...

    Did you notice this though?

    Protocol error!
    Therefore when you click on the statistics button you don't get any...

  8. #8
    Junior Member
    Join Date
    Nov 2006
    Posts
    6
    OK...

    I finally got it to work...Here is the Statistics Info:

    WEB100 Enabled Statistics:
    Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
    checking for firewalls . . . . . . . . . . . . . . . . . . . Done
    running 10s outbound test (client-to-server [C2S]) . . . . . 247.0kb/s
    running 10s inbound test (server-to-client [S2C]) . . . . . . 18.24kb/s

    ------ Client System Details ------
    OS data: Name = Windows XP, Architecture = x86, Version = 5.1
    Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_06

    ------ Web100 Detailed Analysis ------
    Cable modem/DSL/T1 link found.
    Link set to Full Duplex mode
    Information: throughput is limited by other network traffic.
    Good network cable(s) found
    Normal duplex operation found.

    Web100 reports the Round trip time = 435.0 msec; the Packet size = 1432 Bytes; and
    There were 6 packets retransmitted, 5 duplicate acks received, and 7 SACK blocks received
    The connection stalled 1 times due to packet loss
    The connection was idle 1.07 seconds (15.28%) of the time
    C2S throughput test: Excessive packet queuing detected: 19.61%
    S2C throughput test: Excessive packet queuing detected: 71.93%
    This connection is network limited 99.86% of the time.
    Excessive packet loss is impacting your performance, check the auto-negotiate function on your local PC and network switch

    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 'nitro.ucsc.edu' is not behind a firewall. [Connection to the ephemeral port was successful]
    Client is probably behind a firewall. [Connection to the ephemeral port failed]
    Information: Network Middlebox is modifying MSS variable
    Server IP addresses are preserved End-to-End
    Information: Network Address Translation (NAT) box is modifying the Client's IP address
    Server says [41.242.12.197] but Client says [10.0.0.5]

  9. #9
    Elite Member trogers's Avatar
    Join Date
    Jan 2005
    Location
    Bangkok, Thailand
    Posts
    12,323
    Quote Originally Posted by Hoaxed
    Web100 reports the Round trip time = 435.0 msec; the Packet size = 1432 Bytes; and
    There were 6 packets retransmitted, 5 duplicate acks received, and 7 SACK blocks received
    The connection stalled 1 times due to packet loss
    The connection was idle 1.07 seconds (15.28%) of the time
    C2S throughput test: Excessive packet queuing detected: 19.61%
    S2C throughput test: Excessive packet queuing detected: 71.93%
    This connection is network limited 99.86% of the time.
    Excessive packet loss is impacting your performance, check the auto-negotiate function on your local PC and network switch
    Your speed to the US is limited by network traffic (99.86% of the time).

    This may not be the fault of your ISP, but rather, may be due to an undersized international gateway shared by all ISPs in the region.

    To test if the congestion is in your ISP's network, do some speedtests at your ISP or some other site in South Africa. If your speed is near to 90%, then it is congestion at the international gateway that slows everyone down.

  10. #10
    Junior Member
    Join Date
    Nov 2006
    Posts
    6
    Thanks for that bit of info...

    I did a latency test in the nearest town....it came in at 46ms and 32ms for about 20 pings.

    I then did a speed test using the local provider's HTTP download specs. Took the median average and came up with:

    Download: 2315 kbps
    Upload: 300 kbps

    So obviously, what you are saying is a major factor in the connection speed. Here is a question then...If I go with satellite, can I get around the international gateway?

    Is there anything else I can do to improve the poor connection speed I am experiencing for any site outside of my country?

    Thanks!

  11. #11
    Elite Member trogers's Avatar
    Join Date
    Jan 2005
    Location
    Bangkok, Thailand
    Posts
    12,323
    Quote Originally Posted by Hoaxed
    If I go with satellite, can I get around the international gateway?

    Is there anything else I can do to improve the poor connection speed I am experiencing for any site outside of my country?
    All land lines within a country will have to pass signals through the country's international gateway. In many developing countries, an undersized international link (usually controlled by government monopoly) is a common problem and there is not much consumers can do except through constant complaints to the government.

    A pure satellite link (for both out and in signals) will not be subjected to congestion at the international gateway, provided the satellite station in the country transmits and receives directly from stations abroad.

    But latency range for satellite links are 700-900ms range. It is good for web surfing but poor for online gaming.

  12. #12

Similar Threads

  1. Help with Comcast poor download speeds!
    By kr00zn in forum General Broadband Forum
    Replies: 9
    Last Post: 02-28-08, 06:50 AM

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
  •