Page 1 of 3 123 LastLast
Results 1 to 20 of 47

Thread: Conflicting Tweaks on Speedguide and Navas Group

  1. #1
    Moonshine
    Guest

    Post

    Whoops. Didn't even think to see if there were past threads.

    Consider this thread closed.

  2. #2
    Certified SG Addict Brent's Avatar
    Join Date
    Oct 1999
    Posts
    42,161

    Exclamation

    Nah It's ok people need to know about this, all these newbies

    Basically it's like this:

    Navas and Philip had an argument about the tweaks. Out of this Argument Navas made is own website to show his views and opionions. Nothings wrong about that at all. BUT Navas is very CLOSED minded, anything he does not understand he dismisses as Not Important.

    The Fact is with the other tweaks speedguide has in it's reg patch give you the "Potential" (note i said potential) Potential to effect your speeds in more ways then JUST the defaultrcv window.

    It may make it slower, it may be faster. But that's where manual tweakng comes in, you have to tweak your system for optimal performance for yOU cause everyone's pc is different.

    So there you have it, basically Navas is Close Minded about alot of things, and very defensive about it.

    ------------------
    a.k.a Borg Drone
    Owner/Webmaster
    Core Meltdown www.coremeltdown.com

    Forum: http://www.coremeltdown.com/cgi-bin/ubbcgi/Ultimate.cgi

    Out the 100TX, through the linksys router/switch, down the cable modem, over the Tap, off the bridge, past the node, straight up the gateway, past the head end office....nothing but Net

  3. #3
    GasHuffer
    Guest

    Post

    If you go to http://www.dslreports.com/tweaks and then go to the Tweaks Matrix from the pull-down menu you will see that DSL Reports seems to share some of the same suggestions as Navas. For Windows 98 it seems as though receive window and MTU may be the only advantageous tweaks as opposed to the 4 or 5 that are on the Speedguide page. The only thing I've tried since getting DSL about a week ago is increasing the default receive window which brought my speeds up to optimal performance for a 1Mb/s connection, my speed is maxing out at about ~110KB/s down and ~40KB/s up. Don't know if those other tweaks will really do anything or not...my guess is not.

  4. #4
    Moonshine
    Guest

    Post Conflicting Tweaks on Speedguide and Navas Group

    I recently came across the following web page:
    http://cable-dsl.home.att.net

    The author also has several suggestions for tweaking Cable/DSL performance. He also contends that several common tweaks (ie. editing System.ini IRQ for 4096) does nothing.

    In fact, according to the author there is really only one or two tweaks that will improve your cable/dsl performance.

    Several of the points he makes are valid, especially the one i mentioned above. But, I'm curious if anyone else has any comments about the discrepancies in the two guides.

    I also noticed the MS does have KB article about tweaking:
    http://support.microsoft.com/support.../Q183/1/10.ASP

    but it's only the one that deals with making multiple connections to the same web page.

    Anyway.

    -M

  5. #5
    Michfan
    Guest

    Post

    actualy the system.ini tweak u mention does help to keep the speeds more constant and prevent them from falling off by allocation a constant 4mb of ram to the card.

  6. #6
    id4rox
    Guest

    Post

    oh boy, here we go agian, every few months a rave about speedguide vs navas starts up and lasts for 2 weeks, most people seem to like speedguide better, the admins here say nava disregards anything that doesnt work for HIM or something, i dunno, its a load of crap his site,

  7. #7
    Ron AKA
    Guest

    Thumbs up

    GasHuffer you are wise for the number of posts you've made. I agree 100%, the Navas site and the DSL Reports are quite consistant and make a lot of sense. For example the urban myth of adjusting TTL is very well explained. In comparison the SpeedGuide site "blows a lot of smoke". However, it does have a good discussion forum and a lot of very knowlegable contributors.

    I suspect that 90% of users, just try a tweak and never actually test it in any kind of controlled manner. There are no general purpose magical tweaks, and if you want to really improve things on your machine, you have to tune the tweak to your needs. If you want to go cure-all general purpose, you are probably best to just keep the Windows defaults!

    Ron

  8. #8
    Ascension Of Darkness
    Guest

    Talking

    navas tweak works best for me. win98, 806mhz, asus p3bf, especially on dl's and page loads. the speedguide seems to take a sec then loads the pages and on dl's my spees will go up and down. with the navas tweak its steady and higher. ive tried both plus the others out there and the navas works best for me. good luck.

  9. #9
    Moderator Bouncer's Avatar
    Join Date
    Oct 1999
    Location
    OCONUS
    Posts
    4,834

    Post

    Ron,

    Thanks for insulting the work we put into the tweaks, and the site in general. It's appreciated, especially since you paid so much for them and for access to the site.

    They may not work for you. But saying they don't work at all is to ignore the fundamental fact that there are potentially tens of thousands of hardware combinations out there. Any particular tweak may or may not have a positive or negative affect on your system. We've never claimed otherwise. Among other tweaks, I have noticed that dedicating some memory to the NIC does help my system. Most likely, because it gives the NIC a a larger buffered space to store data pending conversion up or down the stack.

    Apparently, Sony Corporation also agrees that it has some use.

    "i talked with sony extensively and found out that while recording you can have NO other usb appliances connected - unplug all - and use msconfig.exe to boot with minimal start up options and set computer file system as network server and add this line to win.ini under enh386 "irq(n)=4096" this will give your spressa 4 megs of memory (n) being the irq assigned to usb hub"

    Source: http://www.usb.org/forums/retail/messages/1295.html

    This site, tries to provide a broad base of basic tweaks, with more customizeable solutions for power users. If you choose to utilize the one or two tweaks available from Navas, then fine. If, at some later point, you'd like to investigate other potential ways of speeding up your system, would you rather know about them, or not? If you subscribe to the Navas site view, you wouldn't even have the OPTION of trying the various other tweaks. He's decided they don't work. You don't get the option. That's the core difference.

    This site was not, is not, and WILL NOT be in any competition with any other site. Period. We've been over this before.

    Fundamentally, if the Navas site tweaks work better for your system then the ones here do, then great! If the ones here give you 1500 fps in Quake, then great! The point is STILL that you found a way to optimize your system, and that's what it's all about.

    With all the possible combinations of hardware and software, it is just not possible for any one RWIN adjustment to make an across the board improvement for all people. It simply does not work that way.

    Two people on the same connection might have vastly different results because of different hardware or software components. That's why you want as wide a variety of options as possible.

    There are certain things that I disagree with Navas about, but that's my view.
    Your mileage may vary. He is a knowledgeable individual. But there are quite a few knowledgeable people here as well. With his site, you get HIS opinion and views. With this site, you get a variety. Personally, I think this site is stronger for that diversity of experience and knowledge. But since I am a moderator here, you can probably reasonably assume a tiny bit of bias.

    In the end, *there is no one tweak*. If we can all get our heads around that idea, then
    we can discuss other sites and ideas without turning it into some sort of bizarro competition.

    Regards,
    -Bouncer-


    ------------------
    "Yeah Baby, YEAH!!!"


  10. #10
    vegasbill
    Guest

    Post

    I truly feel there is a lot of good information to be gained from a great many sources. You must find what works for you or what does not. This does not make anyone wrong or right. I stop by here everyday to read the posts and really enjoy you guys. Fresh and new insight everyday and it is free!
    I do not use any tweaks or need them. This in no way makes the information I read wrong. I enjoy reading it and that is all that matters to me.
    My speed is always around 98% of what I am paying for and I see no need to fix what is not broke.
    Bottom line, I do feel this site is more open in their ideas then others.

  11. #11
    John
    Guest

    Thumbs up

    Here is are comparison charts and an article regarding all these different tweaks:

    Push here to learn.

  12. #12
    Ron AKA
    Guest

    Post

    Bouncer and John perhaps you could point me to a location in this site which explains the theory of each tweak, how it works, when it helps, and when it does not? Perhaps it is here somewhere, and I have just not been able to find it. I base my decisions on facts and testing, and am very open to any new kind of information that you could point me to.

    Trust but verify!

    Ron

  13. #13
    Recordlord
    Guest

    Post

    Navas is FULL OF ****!!

    I AM THE KING OF TWEAK!!!!

    Now who can prove me wrong?

  14. #14
    Ron AKA
    Guest

    Post

    John, I had read your link before, but re-read it again as I'm interested in all factual information available. I agree fully with the conclusion of the article below:

    "Tweaking guides generally tout nine different registry settings as effective:

    DefaultRcvWindow
    PMTUDiscovery
    PMTUBlackHoleDetect
    SackOpts
    MaxDupAcks
    MaxMTU
    MaxMSS
    TTL.
    Tcp1323Opts
    (See end for definitions)

    The one and only setting which seems to have any noticeable effect is the DefaultRcvWindow, also known as RWIN."

    No issue there. What the article seems to have glossed over is the issue of latency. If the latency of each site tested to had been given then I think it would have been possible to draw a better conclusion to the testing.

    Ron


  15. #15
    STRIKESLIP
    Guest

    Lightbulb

    Ron,

    I wrote the article you're talking about, thanks for taking a look at it. The differences and dependancies of bandwidth versus latency are something I think are VERY interesting, and your point is WELL taken. I think what you touched on is a fantastic topic for an entire article in itself. I have a sticky-note on my monitor with another topic already, but I'm going to add this one.

    Thanks for the great idea! This will also be a good article for online gamers.

    As for the reason I glossed over the issue of latency, consider a high bandwidth satellite connection versus a high bandwidth wired connection. They could both be of equal bandwidth, yet the latency of the satellite connection could be many times that of the ground connection.

    It's my current contention that bandwidth and latency are independant at higher bandwidths, and only become more dependant on lower bandwidth connections, where the lines are more stressed. I don't know how I'll test this, as I only have access to cable & dial-up. Maybe I'll manage to prove myself wrong.

    ------------------

  16. #16
    Ron AKA
    Guest

    Post

    All sites have their strengths. The Navas site has some good basic info on what works and what does not with reasons (yes it could be a little harsh). I don't agree with Navas suggestion that you have to do your testing on a local fast server. In fact you need a server with your typical latency. The DSL Reports site does a good job of explaining the way to set up the optimum size of the receive window. This Speedguide site has a good forum with knowlegeable contributers.

    STRIKESLIP,

    I think the other wildcard in this performance puzzle is the effect of the ISP cap. I have not seen this discussed. If you test locally, the download speed will probably be determined by the ISP cap. My experience is that I get a very constant download right at the cap setting and almost never goes to zero during the test when I use a local (not busy) server. However, in more distant (higher latancy, busy) test sites, the download rate during the duration of the test goes in fits and starts with much higher peak rates, and frequent periods of no activity. Obviously I'm only getting slices of time instead of having it all to myself. To optimize download rate in this situation requires making the best of things when you've got your turn. This is where the ISP cap comes in. If it is set up so that you can exceed the nominal cap rate for short periods of time (it allows the average to be the cap, not the peak), then the optimum tweak will be for a higher download rate than your nominal or capped rate. The limited testing I have done suggests this is the case at least with my ISP. I wonder if the ISP's all use the same strategy to cap rates, or if the period they average over varies?

    Ron

  17. #17
    JumpStart
    Guest

    Post

    Ron is correct I believe; ONLY two real tweak for a network, the Registry settings, and number of web sessions. And that IRQx=4096 is ******** too, if you have a good fast PCI NIC, it'll slow it DOWN! That tweak should be used for older PCI and ISA nics. a 3com 905b will choke with that setting

  18. #18
    Michfan
    Guest

    Post

    actualy jumpstart, i have the intel pro managment adapter, and with the irq setting i dl my test file at an average of 325KB/sec, without it an average of 315KB/sec. What it does it help to prevent sudden drop offs in speed because the pc is doing something else. I have 256 ram so the setting is worth it

    ------------------
    "The greatest trick the devil ever pulled was convincing the world he didnt exist"-Verbal Kint

  19. #19
    John
    Guest

    Post

    The DSL Reports site does a good job of explaining the way to set up the optimum size of the receive window.
    Yes, after the article was written, Justin from dslreports got in touch with us and confirmed what strike had said in the article.

    ------------------

  20. #20
    Moderator Bouncer's Avatar
    Join Date
    Oct 1999
    Location
    OCONUS
    Posts
    4,834

    Post

    Guys, a couple of points for your consideration.

    1) I'd sincerely suggest you revisit the importance of MaxMTU and MaxMSS sizing.
    You can easily test this by simply keeping your RWIN at it's current setting, and taking your MAXMTU and MAXMSS back to dial up PPP settings (576 and 536 respectively). Watch the effect on your throughput.

    From the fine folks at Harvard:

    "The packet size used by TCP, often called Maximum Transmission Unit (MTU), effects efficiency in at least two conflicting ways. The host interfaces interrupt on each packet, and a good deal of TCP processing time is per packet (not per byte), so the hosts can send and receive faster with larger packets. On the other hand, TCP works best if it can keep a window of at least four packets in flight, since it detects a dropped packet by noting acknowledgments prompted by the rest of the packets in the window."

    Source: http://www.eecs.harvard.edu/~rtm/tcp-atm/mtu.html

    Failure to adjust these accordingly will lead to fragmentation or unnecessary padding. In addition, in certain environments such as an encrypted session, a mis-setting of the MTU may cause encryption to fail, primarily because of the overhead imposed by the encryption itself, thus causing fragmentation and packet authentication failure. Drastically reducing throughput.

    To quote:
    "When IPSec is enabled end to end, the IPSec implementation on the host should decrease the MTU that the network layer advertises to the transport layer for a particular connection. This value depends on the length and on the kind of IPSec processing afforded to the packet. The various parameters that affect the length are the IPSec protocols afforded to the connection, the transforms (different algorithms produce headers of different length), and the modes (tunnel mode adds an extra IP header)."

    Who says that? Microsoft, Cisco, And Nortel say that. MTUSize, DOES matter.

    Source: http://www.microsoft.com/technet/security/ipsecimp.asp

    2) I'd also reccomend you take another look at the PMTUdiscovery setting, because once again, dynamically altering packet size for each hop link size is an important consideration in IPSec settings and in general. This is *not* as important if you have fast links between you and the site. However, if you go across a slower link, say, an ISDN link for instance, then the ability to auto-resize the packet can help avoid packet fragmentation. In fact, PMTUdiscovery is part of IPv6.

    From the fine folks over at the Navy:

    "For those unfamiliar with IPv6, it might be worthwhile to note that there is no
    intermediate fragmentation in IPv6 because Path MTU Discovery is
    always used, but end-to-end fragmentation can still occur (e.g. due to
    naive UDP applications)."

    Source: http://www.cs.arizona.edu/xkernel/ww...psec-mail.html

    3) As to bursting, you are generally limited to the burst cap set on the router or switch (in some cases) plus an additional physical cap imposed by the physical port send buffer. You can't burst more than the buffer on the port will allow you to. The burst rate itself is very configurable, (on cisco routers) allowing for percentage bursting, full bursting, and configurable periods of time between burst sessions among other things.

    This differs at the differing types of connections you use, frame-relay, and ATM among others.

    I can ref you to white papers and cisco implementation documents on this if you'd like, but it'd help if you could be more specific, since differing technologies apply bursting in different ways.

    Regards,
    -Bouncer-

    ------------------
    "Yeah Baby, YEAH!!!"



    [This message has been edited by Bouncer (edited 06-18-2000).]

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
  •