PDA

View Full Version : Conflicting Tweaks on Speedguide and Navas Group



Moonshine
06-16-00, 12:00 PM
Whoops. Didn't even think to see if there were past threads.

Consider this thread closed.

Brent
06-16-00, 12:59 PM
Nah It's ok people need to know about this, all these newbies http://www.speedguide.net/ubb/biggrin.gif

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 (http://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

GasHuffer
06-16-00, 06:16 PM
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.

Moonshine
06-16-00, 11:45 PM
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/kb/articles/Q183/1/10.ASP

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

Anyway.

-M

Michfan
06-16-00, 11:47 PM
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.

id4rox
06-16-00, 11:48 PM
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,

Ron AKA
06-17-00, 11:40 PM
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

Ascension Of Darkness
06-18-00, 12:33 AM
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.

Bouncer
06-18-00, 02:05 AM
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!!!"

vegasbill
06-18-00, 05:01 AM
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.

John
06-18-00, 06:33 AM
Here is are comparison charts and an article regarding all these different tweaks:

Push here to learn. (http://www.speedcorp.net/guides/regtweaks.shtml)

Ron AKA
06-18-00, 09:13 AM
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

Recordlord
06-18-00, 09:25 AM
Navas is FULL OF ****!!

I AM THE KING OF TWEAK!!!!

Now who can prove me wrong?

Ron AKA
06-18-00, 09:28 AM
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

STRIKESLIP
06-18-00, 10:27 AM
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.

------------------
http://www.cgocable.net/~gillettj/q/s3.gif

Ron AKA
06-18-00, 12:28 PM
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 (http://www.dslreports.com/tweaks) 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

JumpStart
06-18-00, 03:58 PM
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 http://www.speedguide.net/ubb/smile.gif

Michfan
06-18-00, 04:38 PM
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
http://www.ageofkings.org/omega/michfan.gif

John
06-18-00, 04:59 PM
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.

------------------
http://www.speedcorp.net/images/hosted.gif

Bouncer
06-18-00, 06:01 PM
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/www/ipsec/ipsec-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).]

Bouncer
06-18-00, 06:47 PM
Strikeslip,

Be an interesting article, and I'd love to read it.

What I've noticed is this. Latency IS partially dependent on bandwidth, in two ways, one obvious, and one not so obvious.

One, the size of the pipe permits more traffic, which means routing ques are smaller. That's the obvious one.

The maybe-not-quite-as-obvious one is this.

Larger, newer pipes tend to have faster, newer routers and switches attached. This is important because depending on how busy the router is, a SINGLE router can impose upto a 70% delay on the packet, as it compares it to traffic filters, access-lists, and other internal modules, each of whom has to utilize CPU cycles to process each and every packet. Even if you have a large pipe, if you have an older, over used router running at 80% CPU utilization, you are going to see significant latency issues arise.

In addition, we are seeing a reversal of the core network design, especially from Cisco. Cisco is now advocating basically the reverse of the older network model they used to push, because of newer, faster switching technologies. Where Routers used to be the core of the network, cisco now emphasises core switching as the center technology, and encourages router relocation to the edges of the network.

From their perspective, it makes much more sense to have your multi-gigabit switches be at the center, and the slower WAN devices on the outside. I mention this, because it means that latency within the network can be very low, and yet latency to a WAN linked network can be many times higher. Again, dependent on the routers being used and the traffic shaping/filtering that is occuring.

Mind you, many ISPs already have their network topology in place, and simply redoing the entire network is pretty much out of the question. You may be travelling through one or more of these ISPs on your route from Host A to Host B.

Finally, the dynamic nature of the internet lends itself to latency issues, and is very much dependent on every link in the chain being optimized. A single link, can add significant delay issues. That's not a good thing, but remember, the design was not originally optimized for latency, but rather for slower, more robust links. Nuclear Survivable. It's kinda hard to get Ferrari like speeds out of a tank. http://www.speedguide.net/ubb/smile.gif

Just some stuff you may or may not have thought about.

Regards,
-Bouncer-

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

Just Mark
06-18-00, 11:01 PM
The problem I have with Navas is that he goes on the attack. Instead of offering advice and information, he attacks other sites that he sees as threatening. This by itself has made me disregard his information, whether correct or not. To boot, he has no concept of how to set up a web site so that it is visually pleasing and easy to navigate.

This site does offer good information and is willing to modify it when it finds out that things can be done better. It also offers links to sites that may have conflicting ideas on tweaks. This is my favorite sight to visit, but not the only sight I go to looking for information on broadband and networking. I believe that Phillip will continue to grow this site and not let it stagnate like so many sites do.

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

Ascension Of Darkness
06-19-00, 06:07 AM
i personally drive a ford but i dont condem chevrolet. get my point?

Lex Luthor
06-19-00, 07:14 AM
Everyone is correct in that sometimes one tweak is better than the other.

The problem though, is that Navas is extremely arrogant about his tweaks and everything else.

How can he possibly say nothing else matters other than RWIN when the data is clearly not showing that.

You ever read usenet and his posts? He thinks he has been crowned the moderator when in fact he is nothing close. Instead of answering questions, he puts a link to his site. If something is slightly OT, he lets you know that instead of just keeping quiet.

Lex

STRIKESLIP
06-19-00, 08:45 AM
Bouncer,

Thanks for all the great info. I'm going to have to bookmark this thread.

------------------
http://www.cgocable.net/~gillettj/q/s3.gif

Bouncer
06-19-00, 09:08 AM
(LOL) You're welcome, of course.

I just kinda figured everyone would see me start to go into "BouncerBabbleMode"(tm) and run for the hills. http://www.speedguide.net/ubb/smile.gif

The whole subject of network optimization is something I find fascinating on a couple of different levels. It's really amazing how many parts of the Internet AREN'T really optimized, which is innefficient on both economic and productivity levels. I have a strong suspicion that many places are simply happy that the damn thing runs at all! Much less trying to tighten it up a bit operationally. http://www.speedguide.net/ubb/smile.gif

I know of no other endevour by mankind that has so many conflicting parties making so many disparate technologies work as well as it does without some sort of authority in place to govern it all. It really is amazing.

Regards,
-Bouncer-

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

Juggalo18
06-19-00, 10:13 AM
Look im not the most intelligent when it comes to computers so when i stumbled upon this sight i was thrilled. I just got a cable modem last week and everything that i know about it i learned here. From the faqs to the discussion forums. I dont care whose tweaks are better, all i know is that i have yet to find a site with the same content of information. So as far as tweaks are concerned i plan on getting the speedguide tweak because for the past 3 weeks ive trusted what was said here and found 98% of what has been said here to be true.

Juggalo18
06-19-00, 10:14 AM
Look im not the most intelligent when it comes to computers so when i stumbled upon this sight i was thrilled. I just got a cable modem last week and everything that i know about it i learned here. From the faqs to the discussion forums. I dont care whose tweaks are better, all i know is that i have yet to find a site with the same content of information. So as far as tweaks are concerned i plan on getting the speedguide tweak because for the past 3 weeks ive trusted what was said here and found 98% of what has been said here to be true.

XorCist
06-19-00, 12:21 PM
whats the addy for navas's site?

Bouncer
06-19-00, 12:49 PM
It's the first link in the first post in this topic.

Regards,
-Bouncer-

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

Moonshine
06-19-00, 01:04 PM
Lex,

What newsgroups are you refering to?

-M

Lex Luthor
06-19-00, 01:17 PM
This guy is unbelievable...here are the news groups.

comp.dcom.xdsl
comp.dcom.cable.

Remember the problem about pausing during U/Ls that i posted here?

I posed it to the cable and dsl newsgroups. Now it's obvious it's a generic broadband question not particular to cable or dsl, but he sends me an email direcetly slamming me for an OT post! Did someone make him a moderator and I didn't know about it? as it turns out, I got some good responses from that group..still not fixed..but helpful.

Lex

Thorazine
06-19-00, 08:21 PM
Make sure everyone copies their respective comments into a text file for next month's Speedguide vs. Navas thread.

I'm such a sucker, I read this damn thread every month. You'd think I would have learned by now.

[This message has been edited by Thorazine (edited 06-19-2000).]

Just Mark
06-19-00, 08:59 PM
Navas and his type is the reason that I won't post in the Usnet groups. The last thing I need is a mailbox full of crap.

He spews forth in quite a few groups. I see him in the @home groups also.

Bouncer
06-19-00, 09:09 PM
(LOL) Something new in the Navas Vs Speedguide thread? (LOL)

Ahem. I'm sorry. Ahem. (cough cough snicker)

Okayokay..phew. Okay people, enough about Mr. Navas, let's get back to the tweaking.

(gently pushes unruly mob back somewhere near the topic)

Regards,
-Bouncer-

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

Ron AKA
06-19-00, 09:27 PM
Could someone point out where Navas has made a technical error in his assesment? For example with respect to the System.ini Issue (http://cable-dsl.home.att.net/#SysiniTweak) quoted below, which statement is incorrect and what factual basis is there for saying Navas has made a mistake?

"Why the System.ini Tweak Doesn't Work

The System.ini Network Card Tweak (http://www.speedguide.net/Cable_modems/cable_irq.shtml) has its origins in a discussion thread entitled "Slow cable issue????" (http://www.speedguide.net/ubb/Forum2/HTML/001515.html)
The claim is that the tweak (IRQn=4096) improves network performance by allocating 4 megabytes of memory as a buffer for the IRQ (n) used by your network adapter. However:

The setting has no effect on actual memory allocation.
The setting does not actually affect network performance in carefully controlled tests. (Anecdotal reports are mixed, and unreliable due to Internet and system variabilities, particularly the effects of caching.)
There is no apparent evidence that there even is any such setting in Microsoft documentation.
Windows does not allocate buffer memory for IRQ's. (Buffers are the responsibility of device drivers, which allocate them by device, not by IRQ. On the PCI bus, a single IRQ can be shared by multiple devices.)
While it doesn't help, the good news is that (like TTL) this setting doesn't hurt (assuming you don't screw up your SYSTEM.INI file) -- Windows just ignores settings that it doesn't recognize.

Note: This may have gotten its start as confusion over the real SYSTEM.INI settings COMnIrq and COMnBuffer, which are used to control serial port IRQ assignment and buffering (the latter of which can help serial port throughput). But these settings pertain only to the standard Microsoft serial port driver, not to network adapters."

It seems to me that if someone is to be discredited then valid reasons need to be given. If we assume for a second that his statements are correct, is he not doing all of us a service making the information available?

Ron

Bouncer
06-20-00, 01:31 AM
I've been looking at this for awhile now.

Searched deja news, google, and a whole boatload of other resources. read more sites than I care to think about. Microsoft themselves has nothing specific on this that I could find, but thats neither here nor there. Microsoft has quite a few "undocumented features" (mostly bugs, I know) that people can't find out about on their sites.

In any case, there's basically five things I've found so far.

1) It IS possible to set an input/output buffer on an IRQ line... in Unix flavors at least (FreeBSD, Linux, etc) http://www.speedguide.net/ubb/smile.gif

2) Users of Soundblaster cards report this solved "crackling" problems in audio, especially when using some sort of audio/visual sound representation.

Quote:
"The problem is in the chipset on the motherboard. It's allocating too much resources to the AGP slot, leaving very few time slices for other PCI cards to use. The harder you play the game, the more resources the card requires and the less time is left for the sound card. It's a design problem with some chipsets and they simply don't leave enough time for the other PCI devices.
Something that MAY work, is to increase the cache size for the sound card. Whatever IRQ the sound card is using, use that number here;"

Source: http://x52.deja.com/[ST_cam=search.yahoo.none.slot]/getdoc.xp?AN=614504872&CONTEXT=961477841.388956186&hitnum=425

3) Users of GeForce cards are also using this to solve similar stuttering problems, (except in video obviously)... at least that's the impression I get from the "OMG IT WORKED!!" type messages I was reading.

4) Found at least one person with 64megs of main memory who claimed it made a dramatic impact, significantly upping their download speeds. Point is that some people ARE reporting success with this. To them, it's obviously doing something. They put in the line, and their speeds go up. Pure and simple. So it's hard to simply discount it outright.

5) Found one decent hardware reference:

PCI to DRAM Buffer. Improves PCI to DRAM performance by allowing data to be stored if a destination is busy. Buffers are needed because the PCI bus is divorced from the CPU.

Source: http://burks.bton.ac.uk/burks/pcinfo/hardware/bios_sg/pcipnp.htm

But notice, it's a BIOS configuration issue.

I've also been reading quite a bit about how Windows will "step on" IRQ's in general, and on the CPU quite a bit. This leaves me wondering if the setting isn't creating a memory cache the device can dump to (and continue processing), instead of trying to fight for the attention of the CPU while Windows is stomping the CPU IRQ line, and or possibly other resources like AGP are hogging the CPU's attention. Sort of a: "If I can't get the CPU's attention I'll just put this info over here till he can get around to looking at it."

There's also the possibility (again, from my reading) that this is upping the cycles the IRQ slot will use. By that I mean it will wait 4096 cycles between transmits, which means that more of it's read/write buffer is ready to send to the CPU. Conversely, it may mean that the IRQ is cycling 4092 times, against the default (from what I've read) of 1024 times, thus trying to grab the attention of the CPU more often!

It's a mess. This is NOT an explanation, not even an attempt. Just sort of a progress report on what I've found so far.

The pet theory I'm developing favors the dumping ground, because it allows the device to continue processing info, as opposed to sitting there with a full buffer waiting for CPU attention.

Once it has the attention, it dumps the full buffer, but then has to bring in new info, process it, and wait for another chance to get the CPUs attention. With a larger buffer, it has already processed and sent the info to some small segment of main memory, from which the cpu can cull it.
Thus, the buffer is never completely empty, reducing or eliminating audio/video stutters.

Windows may not assign buffers directly to IRQ's, but that doesn't mean the PCI/BIOS chipset can't. How this would interrelate with a System.ini function is a stretch, but it's possible that Windows reads the line and *enables* this BIOS function. I'd point out that memory shadowing and memory reservation can be enabled in BIOS, or in Windows.

This is all pure hypothesis though, and I'm the first one to say it, okay?

Anyways, If I stumble across a magic explanation and the grand unification theory I'll post it. http://www.speedguide.net/ubb/smile.gif

Finally, I want to be very careful about this. To me, it doesn't really matter whether one person or groups of people believe it works or doesn't work. The thing I find REALLY interesting is that IN SPITE of Navas's opinion, other people have tried this and it HAS done something for them. You could argue that one or two people were mistaken, or some third factor was intervening. But we're seeing more than one or two people reporting success.

I'd like to find out why.

I'd also like to see his reasons for claiming this:
"It is not necessary to make the TCP receive window size an exact multiple of MTU or MSS (or any other value) to avoid performance degradation due to packet fragmentation, as is commonly claimed. That is just another urban myth."

I strongly disagree with that. And I've got Harvard University on my side. And Microsoft. And Cisco. And Nortel.

Again, you can easily check his "urban myth" by simply leaving your RWIN size at it's current state, and adjusting your MTU and MSS back to dial up PPP settings, and watch what happens to your throughput.

But that's another issue for another post.

Regards,
-Bouncer-

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

Xzaver
06-20-00, 01:51 AM
I Must Agree With RecordLord Here.

And Recordlord Man you are the king of all tweaks!!!

Navas Is Full of it!
And Very Very close Minded !

I Look At it this Way......

If you Fine Tune a tweak enough, in the end you will get it to work, And get it to work the way you want it to.!

Hence My Signiture
| |
| |
VV
| |
VV
| |
| |
VV long Live Speedguide!

------------------
Push Things to there limits.....and eat the results Like candy....You will either get a sweet tooth or a jaw breaker -X z a v e r

John
12-30-00, 12:38 AM
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-


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/www/ipsec/ipsec-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-

Strikeslip,
Be an interesting article, and I'd love to read it.

What I've noticed is this. Latency IS partially dependent on bandwidth, in two ways, one obvious, and one not so obvious.

One, the size of the pipe permits more traffic, which means routing ques are smaller. That's the obvious one.

The maybe-not-quite-as-obvious one is this.

Larger, newer pipes tend to have faster, newer routers and switches attached. This is important because depending on how busy the router is, a SINGLE router can impose upto a 70% delay on the packet, as it compares it to traffic filters, access-lists, and other internal modules, each of whom has to utilize CPU cycles to process each and every packet. Even if you have a large pipe, if you have an older, over used router running at 80% CPU utilization, you are going to see significant latency issues arise.

In addition, we are seeing a reversal of the core network design, especially from Cisco. Cisco is now advocating basically the reverse of the older network model they used to push, because of newer, faster switching technologies. Where Routers used to be the core of the network, cisco now emphasises core switching as the center technology, and encourages router relocation to the edges of the network.

From their perspective, it makes much more sense to have your multi-gigabit switches be at the center, and the slower WAN devices on the outside. I mention this, because it means that latency within the network can be very low, and yet latency to a WAN linked network can be many times higher. Again, dependent on the routers being used and the traffic shaping/filtering that is occuring.

Mind you, many ISPs already have their network topology in place, and simply redoing the entire network is pretty much out of the question. You may be travelling through one or more of these ISPs on your route from Host A to Host B.

Finally, the dynamic nature of the internet lends itself to latency issues, and is very much dependent on every link in the chain being optimized. A single link, can add significant delay issues. That's not a good thing, but remember, the design was not originally optimized for latency, but rather for slower, more robust links. Nuclear Survivable. It's kinda hard to get Ferrari like speeds out of a tank.

Just some stuff you may or may not have thought about.

Regards,
-Bouncer-

I've been looking at this for awhile now.
Searched deja news, google, and a whole boatload of other resources. read more sites than I care to think about. Microsoft themselves has nothing specific on this that I could find, but thats neither here nor there. Microsoft has quite a few "undocumented features" (mostly bugs, I know) that people can't find out about on their sites.

In any case, there's basically five things I've found so far.

1) It IS possible to set an input/output buffer on an IRQ line... in Unix flavors at least (FreeBSD, Linux, etc)

2) Users of Soundblaster cards report this solved "crackling" problems in audio, especially when using some sort of audio/visual sound representation.

Quote:
"The problem is in the chipset on the motherboard. It's allocating too much resources to the AGP slot, leaving very few time slices for other PCI cards to use. The harder you play the game, the more resources the card requires and the less time is left for the sound card. It's a design problem with some chipsets and they simply don't leave enough time for the other PCI devices.
Something that MAY work, is to increase the cache size for the sound card. Whatever IRQ the sound card is using, use that number here;"

Source: http://x52.deja.com/[ST_cam=search.yahoo.none.slot]/getdoc.xp?AN=614504872&CONTEXT=961477841.388956186&hitnum=425

3) Users of GeForce cards are also using this to solve similar stuttering problems, (except in video obviously)... at least that's the impression I get from the "OMG IT WORKED!!" type messages I was reading.

4) Found at least one person with 64megs of main memory who claimed it made a dramatic impact, significantly upping their download speeds. Point is that some people ARE reporting success with this. To them, it's obviously doing something. They put in the line, and their speeds go up. Pure and simple. So it's hard to simply discount it outright.

5) Found one decent hardware reference:

PCI to DRAM Buffer. Improves PCI to DRAM performance by allowing data to be stored if a destination is busy. Buffers are needed because the PCI bus is divorced from the CPU.

Source: http://burks.bton.ac.uk/burks/pcinfo/hardware/bios_sg/pcipnp.htm

But notice, it's a BIOS configuration issue.

I've also been reading quite a bit about how Windows will "step on" IRQ's in general, and on the CPU quite a bit. This leaves me wondering if the setting isn't creating a memory cache the device can dump to (and continue processing), instead of trying to fight for the attention of the CPU while Windows is stomping the CPU IRQ line, and or possibly other resources like AGP are hogging the CPU's attention. Sort of a: "If I can't get the CPU's attention I'll just put this info over here till he can get around to looking at it."

There's also the possibility (again, from my reading) that this is upping the cycles the IRQ slot will use. By that I mean it will wait 4096 cycles between transmits, which means that more of it's read/write buffer is ready to send to the CPU. Conversely, it may mean that the IRQ is cycling 4092 times, against the default (from what I've read) of 1024 times, thus trying to grab the attention of the CPU more often!

It's a mess. This is NOT an explanation, not even an attempt. Just sort of a progress report on what I've found so far.

The pet theory I'm developing favors the dumping ground, because it allows the device to continue processing info, as opposed to sitting there with a full buffer waiting for CPU attention.

Once it has the attention, it dumps the full buffer, but then has to bring in new info, process it, and wait for another chance to get the CPUs attention. With a larger buffer, it has already processed and sent the info to some small segment of main memory, from which the cpu can cull it.
Thus, the buffer is never completely empty, reducing or eliminating audio/video stutters.

Windows may not assign buffers directly to IRQ's, but that doesn't mean the PCI/BIOS chipset can't. How this would interrelate with a System.ini function is a stretch, but it's possible that Windows reads the line and *enables* this BIOS function. I'd point out that memory shadowing and memory reservation can be enabled in BIOS, or in Windows.

This is all pure hypothesis though, and I'm the first one to say it, okay?

Anyways, If I stumble across a magic explanation and the grand unification theory I'll post it.

Finally, I want to be very careful about this. To me, it doesn't really matter whether one person or groups of people believe it works or doesn't work. The thing I find REALLY interesting is that IN SPITE of Navas's opinion, other people have tried this and it HAS done something for them. You could argue that one or two people were mistaken, or some third factor was intervening. But we're seeing more than one or two people reporting success.

I'd like to find out why.

I'd also like to see his reasons for claiming this:
"It is not necessary to make the TCP receive window size an exact multiple of MTU or MSS (or any other value) to avoid performance degradation due to packet fragmentation, as is commonly claimed. That is just another urban myth."

I strongly disagree with that. And I've got Harvard University on my side. And Microsoft. And Cisco. And Nortel.

Again, you can easily check his "urban myth" by simply leaving your RWIN size at it's current state, and adjusting your MTU and MSS back to dial up PPP settings, and watch what happens to your throughput.

But that's another issue for another post.

Regards,
-Bouncer-



Bouncer probably writes the longest replies in the history of Speedguide, or on any UBB for that matter. He is my hero.

cablenut
12-30-00, 12:54 AM
"In fact, according to the author there is really only one or two tweaks that will improve your cable/dsl performance."

* wonders if kip was the author of this site *

------------------
Head webcheese and geek guru @ http://www.cablenut.com

donald_k
12-30-00, 02:19 AM
Would not be very surprised cablenut. But we must give Kip a chance to defend himself http://www.speedguide.net/ubb/biggrin.gif

rmrucker
12-30-00, 09:21 AM
Hmmm... I didn't realize Kip was considered such a contrarian! I shall have to spend a lot more time SUPPORTING his opinions!

That's what it is all about. Discussing the issues no matter what your opinion is. I think Navas is right about some things, but he is closed-minded and definitely revengeful -- take a peak at his recent attack on GRC!

Kip, despite our differences, consider me an ally for now on! Cheers! http://www.speedguide.net/ubb/smile.gif

Brent
12-30-00, 09:58 AM
wow, this is another old post....

Navas vs. Speedguide

haven't heard that one in a while....

ah, the good ole times....

------------------
Striking Fear in the Heart of Newbies Because I am BRENT JUSTICE: Man of Action Defender of Good and Destroyer of Evil

My site www.coremeltdown.com (http://www.coremeltdown.com)

Kip Patterson
12-30-00, 10:58 AM
I really don't know how my name gets involved here. No, I am not the author of any tweaks anywhere. I am only interested in tweaks from the perspective of understanding how the Internet works and what the implications are for the future. Yes, I am interested in understanding how things happen. No, I do not accept measurements that are not backed up with some sort of explanation of how the results were obtained that is consistent with what is known and published.

cablenut
12-30-00, 11:08 PM
just don't lose your 'papers' again kip lol

------------------
Head webcheese and geek guru @ http://www.cablenut.com

Kip Patterson
12-30-00, 11:14 PM
What papers?

Kip

cablenut
12-30-00, 11:21 PM
*sigh* kip try to relax once and while will ya http://www.speedguide.net/ubb/smile.gif

------------------
Head webcheese and geek guru @ http://www.cablenut.com