Jump to content

Jodokast96

Members
  • Posts

    38
  • Joined

  • Last visited

  • Speed Test

    My Results

Posts posted by Jodokast96

  1. First, I'm only working with one of the Win2k machines.  The 98SE box is for the g/f, so anything over dial-up is fine.  The other Win2k is pretty much just a file server.  Just mentioned them because they are showing the same results.  As to the css file:  I wasn't really looking for ways to improve it (even though that would be great, I think its as improved as it's going to get);  it was just to give you a reference as to what is working best for me, and how it is not "the norm".  I'm on Verizon DSL, 3/768.

    As for posting results to a speed test, this is what I'm talking about.  BTW, I'm in NJ.  I can give you one right now from Speakeasy NY, which are usually considered pretty good, and it will say about 2800.  The Testmy.net (TX, I believe) will probably give me about 1900, about the same as Speakeasy Dal.  And a couple of different ftp downloads will run at about 2600.  But if you want, I can get almost 2800 from Testmy.net (or Speakeasy Dal) by upping my TcpWindowSize or DefaultReceiverWindow, but it will definitely cripple the Speakeasy Ny results, and I believe, but not 100% positive, the ftp downloads.  The same will apply to speeds for different mirrors of that nitro.ucsc.edu test.  I can get any result you want, up to my top speed of about 2800, for any speed test you give me.  I just need to know where it's at so I can set the values accordingly.  Crazy, huh?

    Here are the stats for the link you provided:

    WEB100 Enabled Statistics:

    Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done

    running 10s outbound test (client to server) . . . . . 773.32Kb/s

    running 10s inbound test (server to client) . . . . . . 1.04Mb/s

    ------  Client System Details  ------

    OS data: Name = Windows 2000, Architecture = x86, Version = 5.0

    Java data: Vendor = Sun Microsystems Inc., Version = 1.4.2_06

    ------  Web100 Detailed Analysis  ------

    Cable modem/DSL/T1 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 = 100.33 msec; the Packet size = 1452 Bytes; and

    No packet loss was observed.

    This connection is receiver limited 97.00% of the time.

      Increasing the the client's receive buffer (12.0 KB) will improve performance

    This connection is network limited 2.97% 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: OFF

    Information: Network Middlebox is modifying MSS variable

    Server IP addresses are preserved End-to-End

    estimate = 110.41 based on packet size = 11Kbits, RTT = 100.33msec, and loss = 1.0E-6

    The theoretical network limit is 110.41 Mbps

    The NDT server has a 101.0 KByte buffer which limits the throughput to 7.86 Mbps

    Your PC/Workstation has a 12.0 KByte buffer which limits the throughput to 0.99 Mbps

    The network based flow control limits the throughput to 1.10 Mbps

    Client Data reports link is 'T1', Client Acks report link is 'T1'

    Server Data reports link is 'Ethernet', Server Acks report link is 'Ethernet'

    Here's the results for a mirror in VA:

    WEB100 Enabled Statistics:

    Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done

    running 10s outbound test (client to server) . . . . . 788.02Kb/s

    running 10s inbound test (server to client) . . . . . . 2.89Mb/s

    ------  Client System Details  ------

    OS data: Name = Windows 2000, Architecture = x86, Version = 5.0

    Java data: Vendor = Sun Microsystems Inc., Version = 1.4.2_06

    ------  Web100 Detailed Analysis  ------

    Cable modem/DSL/T1 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 = 36.32 msec; the Packet size = 1452 Bytes; and

    No packet loss - but packets arrived out-of-order 0.04% of the time

    This connection is receiver limited 99.33% of the time.

      Increasing the current receive buffer (12.0 KB) will improve performance

    This connection is network limited 0.64% 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: OFF

    Information: Network Middlebox is modifying MSS variable

    Server IP addresses are preserved End-to-End

    bw = 304.97 based on packet size = 11Kbits, RTT = 36.32msec, and loss = 1.0E-6

    The theoretical network limit is 304.97 Mbps

    The transmit buffer (105.0 KByte) limits the application to 22.58 Mbps

    Your receive buffer (12.0 KByte) limits the application to 2.74 Mbps

    The network based flow control limits the application to 3.04 Mbps

    Client Data reports link is 'T1', Client Acks report link is 'T1'

    Server Data reports link is 'Ethernet', Server Acks report link is 'Ethernet'

    From what I gather, both of them say increasing the Receive buffer (DefaultRecieveWindow, right?), will improve performance, but it doesn't.  If I do, I start getting lots of packets retransmitted according to them.  Like I said in my last post, I really don't know about any of this stuff, just what I'm experiencing, so maybe all of this is just normal.  It just doesn't seem like it.  And up until two months ago, your typical VB tweak would work for me, but now they kill me.  And 4 different modems have been used, so it's not a factor.  I know I'm being more anal retentive than a whole convent of nuns, and should just accept what is, but they why is really bugging me.  I don't know why, but it is.

  2. I think I understand what you guys are saying...however none of it seems to apply to me.  At this point, I believe I've found the settings that work best for me, and will stick with them, but they seem so totally opposite of what they should be, and I'm really just trying to learn why.  I'm just so bugged by the fact that what you are saying used to apply exactly, and now it doesn't. 

    Trogers, take a look again at my settings and the affects they have.  If what you say about a high Rwin not affecting speed to local sites really applied to me, when I set a high Rwin with a low TcpWindow size, it shouldn't behave that way, right?  Which is also the same effect (maybe for different reasons, I don't know) as having a high TcpWindow size.  As far as latency, for near sites, I'm talking less than 30ms, and far as about 100ms.  I haven't messed with anything over 100ms as of yet.  Is it making sense to you?  I know I don't understand how all of this comes together, but something just seems abnormal.  The other part about all of this, and I understand that they can't be totally relied on, is that I can practically guarantee great results (or lousy ones) from any speed test site, just by adjusting these values.  I understand thats what they are there for, but what I mean is, should I be able to set myself up to get good results from one area (or latency range, however you want to look at it) while screwing all the others?  Why am I able to get good results from an area farther away (higher latency) than from closer to me (lower latency), and then flip things around and get the opposite?  Is this how all of this is supposed to work?

    Sorry for being such a pain in the ***.  Just trying to find the why, if it even exists.  BTW I'm attaching my CableNut settings just in case your curious and want to check them out.  I know they would kill anyone elses connection, but it's what is needed on all 3 of my pc's (2 win2k, 1 98SE)

  3. Thanks, I guess it's all just a little beyond me at this point.  So far, it seems to me that they do the same thing, as in a particular value set for one, will have the same exact effect when that value is set in the other.  For example:

    If I set TcpWindowSize to 13068 (don't know why I need it so low) and leave DefaultReceiveWindow blank, I get decent speeds to local sites, poor speeds to distant ones.

    If I set TcpWindowSize to 63888 and leave DefaultReceiveWindow blank, my speeds drop to local sites, but rise for distant ones.

    If I set TcpWindowSize to 13068 and set DefaultReceiveWindow to 63888, I get the same results as setting TcpWindowSize to 63888 and leaving DefaultReceiveWindow blank.

    I haven't yet tried TcpWindowSize set to 63888 and DefaultReceiveWindow set to 13068.

    Is that the way it should work?  Not being able to, all of a sudden, use any of your tweaks has me trying to learn what all this stuff actually does so I can come up with my own.

  4. also CABLE NUT IS A PEICE OF GARBAGE mark my words..... www.broadbandreports.com/tweaks is a very good tweaker i used that and it upped my speed 20 Kbps

    ok buddy but i had messed up internet for a LOONG time until verizon found out they were messing my internet up i had 70Kbps and increased it to 90 now i have 180Kbps

    programs dosent mess up internet, the ppl that using em wrong does.. 

    cablenut is not garbage just beqause you didnt know how to use it

    I agree that its harder to use then most other tweakprograms, but its also the most advanced and offer options to tweak upload aswell 

    VanBuren

    Just my 2 cents here:  I used CableNut sometime back for all 3 of my systems, and it gave me a slight improvement on all of them, using some of VanBuren's custom settings.  Something changed somewhere recently, I'm guessing something Verizon related since all 3 of my systems were affected.  Speeds got horrible.  After a month, I'm not fixed totally, but found that lowering my RWIN lower than either CableNut, TweakTester, or even the Windows default, has helped, at least to nearby test sites.  High RWIN's give me good results only to distant sites.  The point is, every setup is different.  That I have to set my RWIN so low is something that none of these tweaking programs probably never consider because it really doesn't make sense.  None of them have a preconfigured setting with an RWIN of 13068, which is what I need right now.  Why?  Because 99% of the time it would probably cripple a broadband connection.  Anyone with any real experience playing around with computers should know that there are always those situations that leave even the experts scratching their heads trying to come up with an answer that really isn't there.  Some things are just the way they are, just because that's the way they are.

    Anyway, to say the program is junk, is wrong.  It does what it is supposed to do: it allows you to easily change various registry settings that relate to broadband connections.  It never crashes, and never screws up your computer.  The values you enter screw up your computer.  If those values don't help, you have every option to remove them, and find and enter ones that do.

  5. DSL is limited by your distance to the CO or RT.  I belive the maximum distance is about 25,000 feet (don't quote me) of wire length, not physical distance.  Line resistance can also "add" to your distance.  Depending on where you live, there's a chance you will see FIOS deployed there before DSL.  That doesn't mean it will be soon.  Sometimes the website isn't accurate, so try calling them and see what they say.  Or just move, lol.

  6. New here, so Hi to everyone.  Here are the problems I've been having.  Rather than typing it all out (again), here's a link to my current situation.  http://www.dslreports.com/forum/remark,15258334  I believe I've covered everything from the "Before you post" sticky.  ZA has been uninstalled, but there is no difference.  Results on the following tests show about the same pattern as those from my link.  Can anyone help me out here?

    I have MTU set to 1492, not 1484.  DSLReports TweakTest shows Max packet sent (MTU) as 1484 and Max packet recd (MTU) as 1492.

    TCP options string = 020405a401010402

    MTU = 1484

    MTU is somewhat optimized for broadband. If you're not on a PPPoE DSL connection that limits packet size, consider increasing your MTU to 1500 for optimal throughput.

    MSS = 1444

    Maximum useful data in each packet = 1444, which equals MSS.

    Default Receive Window (RWIN) = 13068

    RWIN Scaling (RFC1323) = 0 bits

    Unscaled Receive Window = 13068

    For optimum performance, consider changing RWIN to a multiple of MSS.

    Other values for RWIN that might work well with your current MTU/MSS:

    508288 (MSS x 44 * scale factor of 8)

    254144 (MSS x 44 * scale factor of 4)

    127072 (MSS x 44 * scale factor of 2)

    63536 (MSS x 44) 

    bandwidth * delay product (Note this is not a speed test):

    Your RcvWindow limits you to: 522.72 kbps (65.34 KBytes/s) @ 200ms

    Your RcvWindow limits you to: 209.088 kbps (26.136 KBytes/s) @ 500ms

    Consider increasing your RWIN value to optimize TCP/IP for broadband.

    MTU Discovery (RFC1191) = ON

    Time to live left = 123 hops

    TTL value is ok.

    Timestamps (RFC1323) = OFF

    Selective Acknowledgements (RFC2018) = ON

    IP type of service field (RFC1349) = 00000000 (0)

    UCSC TEST:

    TCP/Web100 Network Diagnostic Tool v5.3.3d

    click START to begin

    Another client is currently being served, your test will begin within 45 seconds

    Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done

    running 10s outbound test (client to server) . . . . . 704.47Kb/s

    running 10s inbound test (server to client) . . . . . . 938.27kb/s

    Your PC is connected to a Cable/DSL modem

    Information: The receive buffer should be 41.31 Kbytes to maximize throughput

    Testmy.net SmartTest:

    :::.. Download Stats ..:::

    Connection is:: 1711 Kbps about 1.7 Mbps (tested with 2992 kB)

    Download Speed is:: 209 kB/s

    Tested From:: https://testmy.net (server2)

    Test Time:: Wed Jan 18 06:28:17 EST 2006

    Bottom Line:: 31X faster than 56K 1MB download in 4.9 sec

    Diagnosis: May need help : running at only 36.31 % of your hosts average (verizon.net)

    Validation Link:: https://testmy.net/stats/id-FQZTHNXDB

    Testmy.net NY server:

    :::.. Download Stats ..:::

    Connection is:: 2713 Kbps about 2.7 Mbps (tested with 3151 kB)

    Download Speed is:: 331 kB/s

    Tested From:: http://www.bafserv.com

    Test Time:: 

    Bottom Line:: 48X faster than 56K 1MB download in 3.09 sec

    Diagnosis: May need help : running at only 57.58 % of your hosts average (verizon.net)

    Validation Link:: https://testmy.net/stats/id-AK6HXQ5TO

    Ping and Tracert Results:

    The current date is: Wed 01/18/2006

    The current time is:  6:22:41.43

    Microsoft Windows 2000 [Version 5.00.2195]

    Pinging testmy.net [67.18.179.85] with 32 bytes of data:

    Reply from 67.18.179.85: bytes=32 time=49ms TTL=50

    Reply from 67.18.179.85: bytes=32 time=50ms TTL=50

    Reply from 67.18.179.85: bytes=32 time=50ms TTL=50

    Reply from 67.18.179.85: bytes=32 time=49ms TTL=50

    Ping statistics for 67.18.179.85:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 49ms, Maximum =  50ms, Average =  49ms

    Ping Complete.

    Tracing route to testmy.net [67.18.179.85]over a maximum of 30 hops:

      1   <10 ms   <10 ms   <10 ms  192.168.0.1

      2     7 ms     7 ms     7 ms  10.5.40.1

      3     6 ms     6 ms     6 ms  130.81.35.176

      4    11 ms    11 ms    18 ms  so-6-0-0-0.PEER-RTR1.NWK80.verizon-gni.net [130.81.17.157]

      5    11 ms    11 ms    11 ms  so-9-1.car2.Newark1.Level3.net [4.79.236.33]

      6    11 ms    11 ms    11 ms  ae-1-56.bbr2.Newark1.Level3.net [4.68.99.161]

      7    52 ms    51 ms    51 ms  as-0-0.bbr2.Dallas1.Level3.net [64.159.0.137]

      8    52 ms    51 ms    51 ms  ae-13-55.car3.Dallas1.Level3.net [4.68.122.143]

      9    49 ms    49 ms    48 ms  4.78.221.146

    10    49 ms    49 ms    49 ms  vl32.dsr02.dllstx3.theplanet.com [70.85.127.62]

    11    49 ms    49 ms    49 ms  vl42.dsr02.dllstx4.theplanet.com [70.85.127.91]

    12    50 ms    49 ms    49 ms  gi1-0-2.car17.dllstx4.theplanet.com [67.18.116.85]

    13    49 ms    50 ms    49 ms  85.67-18-179.reverse.theplanet.com [67.18.179.85]

    Trace complete.

×
×
  • Create New...