# How to Double Firefox Speed



## jr_Cisn305 (Jul 25, 2008)

Firefox is in my opinion the best browser ever made until now. It includes: 
-improved tabbed browsing 
-pop up blocking 
-integrated Goggle search 
-enhanced privacy controls 
-built-in phishing protection 
-online spell checking 
-lots of themes, interfaces, and extensions/addons

Mozilla Firefox officially supports: 
-Microsoft Windows 
-Linux 
-Mac OS X

Unofficial Support: 
-Free BSD 
-OS/2 
-Solaris 
-SkyOS 
-BeOS 
-XP Professional x64 Edition

Now here are some Tips&Tricks that can help you double the speed of Firefox.

1. Type *about:config* in the address bar and then press Enter.

2. In the filter search bar type *network.http.pipelining*. Be sure the value field is set *true*,if not double-click to set true. HTTP is the application-layer protocol that most web pages are transferred with. In HTTP 1.1, multiple requests can be sent before any responses are received. This is known as pipelining. Pipelining reduces page loading times, but not all servers support it.

3. Go back to the filter search bar and type *network.http.pipelining.maxrequests*. Double-click this option and set its value to *8*.

4. In the filter search bar and type *network.http.proxy.pipelining*. Once opened doubleclick on it and set it to *true*.

5. In IPv6-capable DNS servers, an IPv4 address may be returned when an IPv6 address is requested. It is possible for Mozilla to recover from this misinformation, but a significant delay is introduced. 
Type *network.dns.disableIPv6* in the filter search bar and set this option to *true* by double clicking on it.

6. CONTENT INTERRUPT PARSING 
This preference controls if the application will interrupt parsing a page to respond to UI events. It does not exist by default. Right-click (Apple users ctrl-click) anywhere in the *about:config* window, select *New* and then *Boolean* from the pop-up menu. Then: 
A. Enter *content.interrupt.parsing* in the *New* boolean value pop-up window and click OK 
B. When prompted to choose the value for the new boolean, select *true* and click OK.

7. Rather than wait until a page has completely downloaded to display it to the user, Mozilla applications will regularly render what has been received to that point. This option controls the maximum amount of time the application will be unresponsive while rendering pages. Right-click (Apple users ctrl-click) anywhere in the *about:config* window, select *New *and then *Integer* from the pop-up menu. 
A. Enter *content.max.tokenizing.time* in the New integer value pop-up window and click OK 
B. You will be prompted to enter a value. Enter *2250000* and click OK.

8. CONTENT NOTIFY INTERVAL 
This option sets the minimum amount of time to wait between reflows. Right-click (Apple users ctrl-click) anywhere in the *about:config* window, select *New* and then* Integer *from the pop-up menu. 
A. Type *content.notify.interval* in the New integer value pop-up window and click OK. 
B. You will be prompted to enter a value. Enter *750000 *and click OK.

9. CONTENT NOTIFY ONTIMER 
A. This option sets if to reflow pages at an interval any higher than that specified by content.notify.interval. Right-click (Apple users ctrl-click) anywhere in the *about:config *window and select *New* and then *Boolean *from the pop-up menu. 
B. Type *content.notify.ontimer* in the New boolean value pop-up window and click OK. 
C. You will be prompted to choose the value for the new boolean. Select *true* and click OK.

10. Notify Backoffcount 
This option controls the maximum number of times the content will do timer-based reflows. After this number has been reached, the page will only reflow once it is finished downloading. Right-click (Apple users ctrl-click) anywhere in the *about:config* window and select *New* and then *Integer* from the pop-up menu. 
A. Enter content.notify.backoffcount in the New integer value pop-up window and click OK. 
B. You will be prompted to enter a value. Enter *5* and click OK.

11. CONTENT SWITCH THRESHOLD 
You can interact with a loading page when content.interrupt.parsing is set to true. When a page is loading, the application has two modes: a high frequency interrupt mode and a low frequency interrupt mode. The first one interrupts the parser more frequently to allow for greater UI responsiveness during page load. 
The low frequency interrupt mode interrupts the parser less frequently to allow for quicker page load. The application enters high frequency interrupt mode when you move the mouse or type on the keyboard and switch back to low frequency mode when you had no activity for a certain amount of time. This preference controls that amount of time. Right-click (Apple users ctrl-click) anywhere in the *about:config* window and select *New* and then *Integer* from the pop-up menu. 
A. Enter *content.switch.threshold* in the New integer value pop-up window and click OK. 
B. You will be prompted to enter a value. Enter *750000* and click OK.

12. NGLAYOUT INITIALPAINT DELAY 
Mozilla applications render web pages incrementally, they display whats been received 
of a page before the entire page has been downloaded. Since the start of a web page 
normally doesnt have much useful information to display, Mozilla applications will wait 
a short interval before first rendering a page. This preference controls that interval. Rightclick (Apple users ctrl-click) anywhere in the *about:config* window and select *New* and then *Integer *from the pop-up menu. 
A. Enter *nglayout.initialpaint.delay* in the *New* integer value pop-up window and click OK. 
B. You will be prompted to enter a value. Enter *0* and click OK.


----------



## EAFiedler (Apr 25, 2000)

Hi *jr_Cisn305*

Welcome to Tech Support Guy Forums!

We have a policy here at Tech Support Guy to not post entire articles of information.
Please *link* to your source, where the credit is due.

Thank you.


----------



## jr_Cisn305 (Jul 25, 2008)

Hi, where would I go to edit this post?


----------



## EAFiedler (Apr 25, 2000)

Click the orange Edit link to the right of your post.
You cannot delete it, only Edit it.


----------



## Chrismichael (Jul 27, 2008)

Umm I just did all of this,, does it work, or did I just make a big mistake?


----------



## Chrismichael (Jul 27, 2008)

Actually it does seem to be working!!!


----------



## pmorgan (Aug 7, 2008)

Thanks so much. This is absolutely incredible. Firefox now "screams" it's so fast. What a great suggestion.

Phil


----------



## jackstoner (May 13, 2008)

Definitely a noticeable difference


----------



## guitar (Jan 15, 2006)

works on firefox portable thanks


----------



## tomdkat (May 6, 2006)

Be careful when using HTTP pipelining.

Peace...


----------



## JohnWill (Oct 19, 2002)

Interesting that pipelining is the default setting if it's sometimes a problem.


----------



## tomdkat (May 6, 2006)

What I find even more interesting is the pipelining setting defaults to False in my stock Firefox 3.0.1 install on Ubuntu Linux and in a stock Firefox 2.0.0.16 installation on Windows XP Home Edition (I've got a PC running Windows around for testing). The interesting part is why we're getting different default settings. 

Peace...


----------



## SectorIT (Jan 1, 1970)

Great TIPS!!!


----------



## Chrismichael (Jul 27, 2008)

I still haven't found a reason to think this could make FF unstable but in my opinion the jury is still out,, so take Toms advice and be careful doing this.


----------



## tomdkat (May 6, 2006)

Chrismichael said:


> I still haven't found a reason to think this could make FF unstable but in my opinion the jury is still out,, so take Toms advice and be careful doing this.


I don't think Firefox's stability will be impacted by the setting but the sites you visit could behave differently which could result in sites not loading correctly for you.

I played with this once a year or so ago and went to a site that actually told me I had HTTP pipelining enabled and recommended I disable it to visit the site.  Unfortunately, I forget which site that was. 

Peace...


----------



## JohnWill (Oct 19, 2002)

tomdkat said:


> What I find even more interesting is the pipelining setting defaults to False in my stock Firefox 3.0.1 install on Ubuntu Linux and in a stock Firefox 2.0.0.16 installation on Windows XP Home Edition (I've got a PC running Windows around for testing). The interesting part is why we're getting different default settings.
> 
> Peace...


What can I say, see for yourself. The first one is when I leave it at the default, the second one is when I set it *false*. This is Windows XP-Pro SP3. Note the version I included in the second screen shot.


----------



## tomdkat (May 6, 2006)

JohnWill said:


> What can I say, see for yourself. The first one is when I leave it at the default, the second one is when I set it *false*. This is Windows XP-Pro SP3. Note the version I included in the second screen shot.


Now that's interesting since the PC running XP Home Edition I run Firefox 2.0.0.16 on also has SP3 on it. Your default settings look like the defaults for 'SwiftWeasel', which I also run on Linux.

Do you have the "FasterFox" extension installed, by chance?

Peace...


----------



## JohnWill (Oct 19, 2002)

Yes I do, didn't even think of plugins!


----------



## tomdkat (May 6, 2006)

Cool.  FasterFox provides an interface for setting HTTP pipelining so that explains it. 

Peace...


----------



## alex01 (Aug 9, 2008)

jr_Cisn305 said:


> Firefox is in my opinion the best browser ever made until now. It includes:
> -improved tabbed browsing
> -pop up blocking
> -integrated Goggle search
> ...


Hey,

These are really good tricks. I didn't know about these.

Thanks for sharing.

__________________
Alex Ruseell
Garage Doors York


----------



## patwardo (Aug 30, 2006)

This is a great tip


----------



## tomdkat (May 6, 2006)

Here are some sites for folks doing this to check out:

http://hubpages.com/hub/Firefox-pipelining-speed-tweak-may-actually-slow-down-your-browser

http://forums.mozillazine.org/viewtopic.php?f=38&t=807255&p=4220115#p4220115

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> Here are some sites for folks doing this to check out:
> 
> http://hubpages.com/hub/Firefox-pipelining-speed-tweak-may-actually-slow-down-your-browser
> 
> ...


http://hubpages.com/hub/Firefox-pipelining-speed-tweak-may-actually-slow-down-your-browser
excerpt>


> First, according to Mozilla's knowledge base, the number needs to be "any integer from 1 to 8 inclusive," which seems to imply that Firefox will only send a maximum of 8 HTTP requests at a time in any case. So setting it to anything larger than 8 isn't going to give any additional benefit.


Looks like a logical fallacy to me.



> New Tech Heroes Test Labs tried a number of settings for "maxrequests" in Firefox today, and discovered that values from 2 to 4 resulted in occasional disruption of web page loading, while settings from 5 to 8 resulted in the disruption every time we tested.


This is confusing.....I thought their point was to prove 8 or less was advantageous?



> With a "maxrequests" value of 2, no problems with the test Google search were observed in 25 tests.


No problems, but what was the comparison for time loading for values above 8?
I've used 32 for several years with no issues.



> We're uncertain whether the throttling of HTTP requests was being done by Google at its web server or perhaps by our ISP (Comcast).


No results were given of a comparative test to values over 8.

http://forums.mozillazine.org/viewtopic.php?f=38&t=807255&p=4220115#p4220115
excerpt>


> After some google work i found the about:config settings for only allowing x connection per server. I set the value on 2 and tested it a if i get banned, and yeah it happen again. I made 42 connection this time. My host did everything to help me but clearly its a problem of Firefox 3


Looks inconclusive to me.

BTW, I tried FF3 and experienced scrolling issues with pages that have numerous images against a background text.
The worst was http://www.topspeed.com/
It happened under winxp and a Linux Boot CD....Slax.
I've gone back to FF2.
From what I've read at the Mozilla site, there is not going to be a fix for that in the future with FF3.x


----------



## tomdkat (May 6, 2006)

Stoner said:


> Looks like a logical fallacy to me.


The author is addressing the advice that's commonly given to set max connections to something higher than 8. Firefox will use *no more* than 8 connections, so there's no point in setting that number to anything higher than 8. Some sites recommend setting max connections to 32 or more. I saw one post on a forum where someone set it to 100!



> This is confusing.....I thought their point was to prove 8 or less was advantageous?


I believe the point is to demonstrate if increasing the number connections helps or not vs testing to find the "optimal" number.



> No problems, but what was the comparison for time loading for values above 8?
> I've used 32 for several years with no issues.


This relates to your logical fallacy point above.  Even though you have 32 configured, no more than 8 are being used. I believe the idea is since Firefox will use no more than 8 connections, specifying a number larger than 8 won't increase the number of connections as you might think it does. In addition to that, their testing found increasing the number of connections to ANYTHING adversely impacted the browsing experience.



> No results were given of a comparative test to values over 8.


Again 8 is the "magic" number. I think it would be neat for someone to create a Firefox extension to show the connection activity so you can see all 8 connections being used even though you've got more than 8 configured.



> http://forums.mozillazine.org/viewtopic.php?f=38&t=807255&p=4220115#p4220115
> excerpt>
> (snip)
> Looks inconclusive to me.


In this case, the user reported being "banned" from a site when using Firefox. When they viewed the *same* site on the *same* machine using IE, they were able to access it just fine. From what I can gather, the user in that thread had HTTP pipelining enabled and they also had the AVG link scanner enabled. What isn't completely clear (yet) is whether the HTTP pipelining was the cause of their issue or the AVG link scanner scanning links. Unless the page they were viewing contained a bunch of links to the same site, I doubt the AVG link scanner would have been the culprit since it would have scanned links on other sites. For that particular user, something is different since they can't connect to the site they mention using Firefox 3 yet they could using Firefox 2 and IE.



> BTW, I tried FF3 and experienced scrolling issues with pages that have numerous images against a background text.
> The worst was http://www.topspeed.com/
> It happened under winxp and a Linux Boot CD....Slax.


What would happen?

Again, the point of my comments is not to say DON'T use this performance tuning technique but to understand it and use it appropriately since it can interfere with how the browser can interact with some websites. 

Peace...


----------



## dannyn (Nov 9, 2007)

I use fasterfox for mac, and firetune for pc.
They are good plugins, and very simple to operate.


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> The author is addressing the advice that's commonly given to set max connections to something higher than 8. Firefox will use *no more* than 8 connections, so there's no point in setting that number to anything higher than 8. Some sites recommend setting max connections to 32 or more. I saw one post on a forum where someone set it to 100!
> 
> I believe the point is to demonstrate if increasing the number connections helps or not vs testing to find the "optimal" number.
> 
> ...





> Firefox will use no more than 8 connections, so there's no point in setting that number to anything higher than 8.


I haven't seen an official Mozilla statement on that, posted yet.
Do you have linkage to that fact?



> Some sites recommend setting max connections to 32 or more. I saw one post on a forum where someone set it to 100!


And yet, I don't see any verification by testing to prove the point one way or the other.



> I believe the point is to demonstrate if increasing the number connections helps or not vs testing to find the "optimal" number.


Then the title is obviously misleading:


> Firefox pipelining speed tweak may actually slow down your browser


They provided no testing or evidence of that implied claim above the value 8.



> This relates to your logical fallacy point above. Even though you have 32 configured, no more than 8 are being used.


No, you missed the issue.
The protocol is a max of 8, nothing about any benefit of a higher value. Also, no negative influence, either.
The claim is based on an unsubstantiated 'if'. That was the fallacy.

The issue remains.....does more than 8 bring a benefit or a detraction?
I have no way of testing it myself and that web site did no tests, themselves.

I pointed out a logical fallacy. Logical fallacies can indeed wind up being correct, but the logic is not supportive of that correctness.



> I believe the idea is since Firefox will use no more than 8 connections, specifying a number larger than 8 won't increase the number of connections as you might think it does.


I have not seen anything yet that proves your belief.
Maybe, maybe not......but what you posted is not supportive of the issue.
Imagine someone using the TSG Civ Debate forum as an authoritative source 

Quote:


> Again 8 is the "magic" number.


Have I missed a link to a Mozilla FYI?
How about a link to Mozilla clarifying the issue and I don't mean the member forums.



> In this case, the user reported being "banned" from a site when using Firefox.


FF3 was banned, not FF2 ....configured the same way.
FF3 may indeed be different, I don't know. My experiences started with FF 0.7 and I currently use FF2 after scrolling issues with FF3. I didn't use FF3 more than several days, but the config did transfer and I experienced no issues or refusals beyond scrolling which is a different issue.
I don't use AVG.



> Again, the point of my comments is not to say DON'T use this performance tuning technique but to understand it and use it appropriately since it can interfere with how the browser can interact with some websites.


I understand.......I just don't think your links were helpful.
This issue will likely be clarified by someone actually measuring the number of connections versus the change in the speed of a web page loading.

I've spent the last 20 minutes changing my config back and forth and to be honest, I don't see a difference between pipeline max requests set at 2, 8, or 32.
I have numerous FF tweaks and am on a fast connection to start with (Road Runner).

The scrolling issues with FF3.
Some people have been having trouble scrolling web pages that have numerous images on a background of text. It seems the larger monitors have more or most issues.
This site was not usable http://www.topspeed.com/
Scrolling literally took ~30 seconds for one page while the images jerked up and down as the page scrolled. The worst was the text jumped up and down at a different rate 
It was unreadable.
There were some workarounds at the Mozilla site that helped some people, but not me nor the ones still complaining.
FF2 is still being updated for security. When that ends, I'll move onto another browser if Mozilla doesn't fix that bug in the next version.


----------



## Stoner (Oct 26, 2002)

dannyn said:


> I use fasterfox for mac, and firetune for pc.
> They are good plugins, and very simple to operate.


I think it was FasterFox that I used on a Dell P3 800 with win2k and FF 1.5.
Things have probably changed, but page loading was considerably slower than the tweaks I'd done.
It wouldn't revert to the config I had been using, so I just did a quick reinstall by way of a recent drive image.

Personally, I don't like any app that makes unknown tweaks that I'm not aware of in case I need to manually undo them.


----------



## tomdkat (May 6, 2006)

Stoner said:


> I haven't seen an official Mozilla statement on that, posted yet.
> Do you have linkage to that fact?


Sure do:

http://kb.mozillazine.org/Network.http.pipelining.maxrequests



> And yet, I don't see any verification by testing to prove the point one way or the other.


To prove the point that setting the maxrequests parameter to something greater than 8 has no impact? Since 8 is the documented max, I don't know how you would prove a setting higher than 8 makes a difference. I mean you could set the parameter to a larger number and it should perform the same as if you used the setting of 8.



> Then the title is obviously misleading:


I don't think so. You stated above you thought the "point" was to prove that a setting of 8 or less was advantageous. I'm saying the point of the article is to warn users that adjusting the pipelining settings _at all_ can be problematic. Here is a comment from a Mozilla community coordinator that further illustrates this.



> They provided no testing or evidence of that implied claim above the value 8.


I guess since the max of 8 is a documented max, they didn't feel the need to conduct such testing.



> No, you missed the issue.
> The protocol is a max of 8, nothing about any benefit of a higher value. Also, no negative influence, either.
> The claim is based on an unsubstantiated 'if'. That was the fallacy.


I believe I substantiated the "if" by providing the link to the MozillaZine documentation above.



> The issue remains.....does more than 8 bring a benefit or a detraction?
> I have no way of testing it myself and that web site did no tests, themselves.


From what I've been reading, a setting of larger than 8 is effectively ignored because 8 is the max supported.



> The scrolling issues with FF3.
> Some people have been having trouble scrolling web pages that have numerous images on a background of text. It seems the larger monitors have more or most issues.
> This site was not usable http://www.topspeed.com/
> Scrolling literally took ~30 seconds for one page while the images jerked up and down as the page scrolled. The worst was the text jumped up and down at a different rate
> It was unreadable.


Weird, I'm not seeing that behavior at all. Maybe my Internet connection is fast enough that all the content downloads quickly and doesn't impact the page rendering in a noticable fashion. Of course, I don't have any of these performance tweaks in place either.

Peace...


----------



## Chrismichael (Jul 27, 2008)

I tried http://www.topspeed.com/ using Vista with FF3 and the above configuration and found no problems. The only problem I have had at all with FF3 is when I immedietly log into Hotmail after a fresh boot up and hit a Tech Guy Forum Update link. This seems to crash (FF is not responding) everytime. This started after I changed to pipeling although I am not sophisticated ehough with FF to know what is causing it.


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> Sure do:
> 
> http://kb.mozillazine.org/Network.http.pipelining.maxrequests
> 
> ...





> Sure do:
> 
> http://kb.mozillazine.org/Network.http.pipelining.maxrequests
> 
> To prove the point that setting the maxrequests parameter to something greater than 8 has no impact? Since 8 is the documented max,


But the link you give does not claim the value 8 is the maximum recognized.
This is what is posted:


> Any integer from 1 to 8 inclusive determines the maximum number of requests to pipeline at once.


That statement may seem to imply that the value 8 is max, but that's not what is being said.
It says an integer from 1 to 8 sets the maximum number of requests.
Observe.....if set at 4, that then becomes the maximum, but that is not the maximum integer that is possible.
I've read the protocol for HTTP 1.1 is 8 for pipelineing max requests, but on a search, I find that Mozilla posts this:
http://www.mozilla.org/projects/netlib/http/pipelining-faq.html


> The HTTP/1.1 spec does not provide any guidelines on the ideal number of requests to pipeline. It does, however, suggest a limit of no more than 2 keep-alive connections per server.


I still have that setting at the value of 2.



> I don't think so. You stated above you thought the "point" was to prove that a setting of 8 or less was advantageous.


Their point was in conflict with the title.
The title was addressed to values over 8, the article restricted to discussion of requests of 8 and less.



> I'm saying the point of the article is to warn users that adjusting the pipelining settings at all can be problematic.


If you mean the blogger, that is exactly the failing of that article.......no testing above 8 to prove a point.



> Here ( http://weblogs.mozillazine.org/asa/archives/2007/05/a_better_explan.html )is a comment from a Mozilla community coordinator that further illustrates this.


And then that person uses another non Mozilla 'authority ' ( Link )to make this claim:


> Firefox only has the ability to send 8 requests at once, so altering this value to anything higher than 8 is pointless.


Do you see the issue?
A Mozilla 'person' has based 'fact' on an outside source.
I asked for a link to Mozilla, not egonitron.com ........essentially another blog site.



> I mean you could set the parameter to a larger number and it should perform the same as if you used the setting of 8.


I have seen nothing to confirm that.
It's based upon FF only recognizing 8 as a max.
This has not been established, yet.



> I guess since the max of 8 is a documented max, they didn't feel the need to conduct such testing.


It makes no difference how many times you present that claim, it doesn't carry validity till it can be documented that the value 8 is the largest recognized.
But the article you presented made the claim and did no testing against it. All they did was test the relative differences between 2 and 8....1 being turned off.



> I believe I substantiated the "if" by providing the link to the MozillaZine documentation above.


Nope 



> From what I've been reading, a setting of larger than 8 is effectively ignored because 8 is the max supported.


But none seem to lead directly back to Mozilla to validate their claims.
This is what I ask for. Info directly from the people that wrote the code. Not bloggers.

About FF3:


> Weird, I'm not seeing that behavior at all. Maybe my Internet connection is fast enough that all the content downloads quickly and doesn't impact the page rendering in a noticable fashion.


It's not a matter of downloading or speed of rendering.
No matter how long I waited, any scrolling of a page already rendered was the same.
I thought it weird also, but I could duplicate the effect in Windows XP and in a Linux distro...Slax, both using FF3. No issues with FF2.
(edit:...just another comment: FF3 on my windows platform carried many tweaks including the pipeline max requests, but FF3 unde Slax carried no tweaks at all beyond several extensions, No Script, Ad block +, and Flash block)
Complaints at Mozilla all had the same similarity of using large monitors. Mine was a 21" Sony CRT. I say 'was' because it recently burned out .
I'm currently back on a Dell 17" CRT, but intend to move to a large LCD in the near future.


----------



## Stoner (Oct 26, 2002)

Since this thread has become more than just tweaking....
here is a screen shot of FF2 about:config
I have a pointer at a button that brings up a menu that includes 'Restore Natural Order'.
What is it's purpose?

I didn't find anything on a quick google search and the help file in FF2 shows nothing.


----------



## tomdkat (May 6, 2006)

Stoner said:


> But the link you give does not claim the value 8 is the maximum recognized.


That Knowledge Base article includes links to the actual source code which clearly show the max of 8 being enforced. Scroll to the bottom of the Knowledge base article and you will find this link. Line 1016 of the source module references the constant which defines the max of 8 and you can see that constant yourself by clicking the link in the source module.



> That statement may seem to imply that the value 8 is max, but that's not what is being said.
> It says an integer from 1 to 8 sets the maximum number of requests.
> Observe.....if set at 4, that then becomes the maximum, but that is not the maximum integer that is possible.


Correct, 8 is the maximum number. What is NOT stated is what happens if you specify a number larger than 8 but that's covered in the links to the actual code in question, which IS provided in the knowledge base article.



> I've read the protocol for HTTP 1.1 is 8 for pipelineing max requests, but on a search, I find that Mozilla posts this:
> http://www.mozilla.org/projects/netlib/http/pipelining-faq.html
> 
> I still have that setting at the value of 2.


No one has said the Firefox max of 8 is anything more than a Mozilla browser restriction. The FAQ article above discusses what HTTP pipelining actually is, not how it is implemented in the browser. I'm not sure why you would look at a description of a protocol feature when seeking information on a browser's implementation of the feature.



> Their point was in conflict with the title.
> The title was addressed to values over 8, the article restricted to discussion of requests of 8 and less.


I don't see this. The title addressed use of the Firefox setting _at all_. The title says nothing about the max number Firefox supports. That comes out in the body of the number since people advising setting the value to anything greater than 8 don't realize Firefox won't use more than 8 (as is demonstrated in the source links provided above). The article title warned that using the feature could slow down the browser and their testing of the maxrequests setting show their experience using various values Firefox _will_ use if this feature is enabled. I don't see where you're getting the connection between the title and the max number Firefox will support.



> If you mean the blogger, that is exactly the failing of that article.......no testing above 8 to prove a point.


What point would be proved considering it's an established fact (based on the code links provided above) Firefox won't support more than 8? The point of the article that setting the maxrequests value "too large" can or will cause problems but that using the feature at all can cause problems. Their discussion was then limited to the values Firefox will actually support.



> And then that person uses another non Mozilla 'authority ' ( Link )to make this claim:
> 
> Do you see the issue?
> A Mozilla 'person' has based 'fact' on an outside source.
> I asked for a link to Mozilla, not egonitron.com ........essentially another blog site.


The link to the Knowledge base article satisfies your request. The Mozilla 'person' to whom I referred already understood what I've demonstrated in the links I've posted above (in this post). The blogger referred to understood this browser restriction as well.



> I have seen nothing to confirm that.
> It's based upon FF only recognizing 8 as a max.
> This has not been established, yet.


The information provided in the Knowledge base article clearly establishes this.



> It makes no difference how many times you present that claim, it doesn't carry validity till it can be documented that the value 8 is the largest recognized.


Done above. 



> But the article you presented made the claim and did no testing against it. All they did was test the relative differences between 2 and 8....1 being turned off.


Which makes sense since the point of the article isn't which particular value should be used. The point is that care should be taken when using the feature.



> Nope


Actually, yeah. The "details" of the implementation of the restriction are available from the article.



> But none seem to lead directly back to Mozilla to validate their claims.
> This is what I ask for. Info directly from the people that wrote the code. Not bloggers.


I've provided that in the link to the Knowledge base article. The article provides a link to the actual code. Did you not look at that info when you looked at the Knowledge base article?



> About FF3:
> 
> It's not a matter of downloading or speed of rendering.
> No matter how long I waited, any scrolling of a page already rendered was the same.
> ...


I've got a 19" LCD monitor at work that I use. I run at 1680x1050 resolution. Should that be sufficient to recreate the scrolling problem you encountered? I viewed the topspeed.com site on a 17" CRT monitor running at 1280x1024 and noticed no scrolling issues at all. Did you have "smooth scrolling" configured? I've viewed the home page of that site with smooth scrolling enabled and disabled and haven't seen what you've noticed. However, I did notice the scrolling was smoother in Opera 9.52 on the same system than in Firefox 3.0.1. In both cases, I didn't see the text misbehaving as you described. 

Peace...


----------



## tomdkat (May 6, 2006)

Stoner said:


> Since this thread has become more than just tweaking....
> here is a screen shot of FF2 about:config
> I have a pointer at a button that brings up a menu that includes 'Restore Natural Order'.
> What is it's purpose?
> ...


I had not noticed that before but a Google search for me found this page, which describes it.

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> That Knowledge Base article includes links to the actual source code which clearly show the max of 8 being enforced. Scroll to the bottom of the Knowledge base article and you will find this link. Line 1016 of the source module references the constant which defines the max of 8 and you can see that constant yourself by clicking the link in the source module.
> 
> (edited for brevity)
> 
> Peace...





> That Knowledge Base article includes links to the actual source code which clearly show the max of 8 being enforced. Scroll to the bottom of the Knowledge base article and you will find this link. Line 1016 of the source module references the constant which defines the max of 8 and you can see that constant yourself by clicking the link in the source module.


Thanks, I overlooked that.
However, it appears there is a means to run the browser out of spec by increasing the integer value above 8, even though it's coded to be the max allowable.
If there weren't, there would be no issues with some users, running out of spec, being banned from certain servers for too many requests.
So the issue hasn't really gone away.



> Correct, 8 is the maximum number. What is NOT stated is what happens if you specify a number larger than 8 but that's covered in the links to the actual code in question, which IS provided in the knowledge base article.


I'm not proficient in code.
I'm basing my thoughts on what is seen as results of using an integer greater than 8, and it's apparent that some servers refuse a number of requests of a greater magnitude.
Looks like a contradiction.



> I don't see this. The title addressed use of the Firefox setting at all.


Let's look at the title:


> Firefox pipelining speed tweak may actually slow down your browser


In this thread, and most tweak posts....the issue has been about setting pipeline max requests above 8.
So there are contextual considerations.
The article initially describes the ability to change the setting and the reason why it's offered.
Then it presents:
excerpt>


> The problem with the pipelining setting is that several articles and blogs have recommended changing the "maxrequests" setting to 30 or more simultaneous HTTP requests.


This is not tested in the article.
It is dismissed as I now know Mozilla didn't intend for a greater maximum number of requests.
But the article even goes so far as to contradict the max rule by stating:


> So setting the "maxrequests" to 30 would also be a selfish behavior, and could result in the server's owner implementing methods to restrict such excessive data requests in order to maintain overall server reliability.


There are reports of banning because of exactly this.
Logically, if 9 or more requests could not be made, there would be no issue.
That article then restricted the discussion to the concerns of the efficiency of 8 or less pipeline max requests.
It avoids discussion of 9 and more by merely stating it can't happen .
And yet some users report being banned from servers for setting a greater integer.

As I posted earlier, I can tell no differences between the settings 2,8,32.
I've also never been banned.
I haven't been convinced 32 is better or worse, or if it doesn't even work as a tweak.
I do know from the link you provided, Mozilla didn't intend a value above 8 to be used.



> What point would be proved considering it's an established fact (based on the code links provided above) Firefox won't support more than 8?


Back to the contradiction.
Yes, I see Mozilla intended the max value to be 8.
The contradiction is that it is reported there are servers seeing more than 8 requests and that blogger avoided addressing that issue by relying on the code not being able to run out of Mozilla's intention.
Consider........that's claiming it can't be done while admitting it happens.
The article is flawed 



> The point of the article that setting the maxrequests value "too large" can or will cause problems but that using the feature at all can cause problems.


Indeed.



> Their discussion was then limited to the values Firefox will actually support.


But it appears that FF will run out of spec.
Or those people that make the claim of being banned were banned for another reason.
No testing was done to show validity or performance of greater values.
The article was flawed. 



> The link to the Knowledge base article satisfies your request.


Thanks......it does satisfy my request for what Mozilla intended.



> The Mozilla 'person' to whom I referred already understood what I've demonstrated in the links I've posted above (in this post). The blogger referred to understood this browser restriction as well.


They certainly are aware of what the code implies.
But the issue remains.
Now it's an issue of FF running out of spec and that's not being addressed by testing.
If there were no reports of servers refusing too large a number of requests, I'd agree that time spent on a different endeavor would be more rewarding 



> Done above.


Not really.
The link to Mozilla was informative, but the issue remains of servers banning users that inserted an integer greater than 8. To do that, more than 8 requests are being made.



> Which makes sense since the point of the article isn't which particular value should be used.


Whoa...........you've also been using this argument in rebuttal of integers above 8.
from that blogger:


> The problem with the pipelining setting is that several articles and blogs have recommended changing the "maxrequests" setting to 30 or more simultaneous HTTP requests.


The problem is that there in anecdotal evidence of more than '8' being used and being rejected by some servers.
This issue is not addressed beyond showing Mozilla didn't intend for this to occur.
The article was flawed 



> Actually, yeah. The "details" of the implementation of the restriction are available from the article.


Actually, nope 
see above 



> I've provided that in the link to the Knowledge base article. The article provides a link to the actual code. Did you not look at that info when you looked at the Knowledge base article?


I missed that link.
To be honest, I'm not proficient in programming and wasn't able to follow and understand the links. I do accept that Mozilla intended the max integer recognized to be 8.
However, as I've mentioned, some servers seem to be refusing users that set the integer higher.
That's not being addressed. It shouldn't happen and the 'why' isn't addresses nor if there is , indeed, any advantage.

tomdkat .......I'm not arguing for the tweak in question, or against it.
I'm just not seeing enough information to clarify the issue of using a larger integer than 8.



> I've got a 19" LCD monitor at work that I use. I run at 1680x1050 resolution. Should that be sufficient to recreate the scrolling problem you encountered?


The issue I encountered was not common to all large monitors, the discussion at Mozilla inferred that the issue had a commonality of existing with large monitors and certain hardware configurations. Those hardware parameters weren't obvious to me, no one seemed to be posting their setups.
Obviously not many users are experiencing this issue or there would be a flood of complaints as Firefox 3 is becoming popular.
I'm using an Acer AST 180 and Win xp mce 2005.
I was using a Sony 21" Crt.
I'll boot into Slax, later in the day, to see if the issue occurs with my Dell 17" CRT.



> Did you have "smooth scrolling" configured?


I tried it both ways.

I've lost the original Mozilla link, but here's another one:
http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&forumId=1&comments_parentId=71205

Here's a google search link just to show the issue is out there and being discussed:
Google_Search


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> I had not noticed that before but a Google search for me found this page, which describes it.
> 
> Peace...


Thanks.....I don't press buttons I don't understand , nor do I do guinea pig for tweaks ( I've learned to watch to see if someone gets nuked first and then proceed with caution  )


----------



## Stoner (Oct 26, 2002)

Stoner said:


> ................
> I'll boot into Slax, later in the day, to see if the issue occurs with my Dell 17" CRT.
> 
> ...................


I just booted into Slax to try out FF3 on a smaller monitor.
The issue was still there but not as pronounced as on a 21" screen.
Obviously my issue in not generated by a large monitor, a large monitor merely intensifies the problem.


----------



## Stoner (Oct 26, 2002)

I've backed up my OS this morning as a drive image ( it was timely, anyway) and then installed FF3.0.1
http://www.topspeed.com/ still showed signs of scrolling issues on a 17" monitor, not as bad as the 21" but still unacceptable.
I did this hack: http://thenonhacker.deviantart.com/journal/18918994/
which did seem to help, somewhat.
The speed of scrolling seemed normal, but there was still minor choppiness.
With smooth scrolling and auto scrolling on, I could read a slowly scrolled page, but couldn't follow the text well if I used the mouse wheel or sped up the auto scroll. The text jerked and blurred out too much.
I think I'll keep FF3 for a while.
If the performance declines with a larger monitor....Firefox 3 will have to leave.

I haven't tried the IE extension.
I might check that out and give that a shot as a work around for sites like TS.


----------



## tomdkat (May 6, 2006)

Stoner said:


> Thanks, I overlooked that.
> However, it appears there is a means to run the browser out of spec by increasing the integer value above 8, even though it's coded to be the max allowable.
> If there weren't, there would be no issues with some users, running out of spec, being banned from certain servers for too many requests.
> So the issue hasn't really gone away.


The issue is one of misinformation. People are reading advice from others online recommending setting the option to values much greater than 8. You stated above you had it set to 32, at one point. The issue is, setting the value greater than 8 *does not* result in the behavior you might think it does. This is why people tried settings much larger than 32, like 100 or even 250 in one case I saw online somewhere. Since it's been established that the code enforces a max value of 8, a setting of 32, 100, 250, or 10,000 will result in Firefox using a max of 8 and the web server reacting to that however it does. Some won't care, others will. I don't know of a way to know this in advance other than trial and error. From what I've been reading in Mozilla articles on this, use of this feature is "at your risk". So, you're right in that the issue of misinformation being spread is still around because people are still recommending ineffective values with the idea being of "cranking up" the browser's performance.



> I'm not proficient in code.
> I'm basing my thoughts on what is seen as results of using an integer greater than 8, and it's apparent that some servers refuse a number of requests of a greater magnitude.
> Looks like a contradiction.


Nope, that's your misunderstanding. What I (and others) are saying is: *if* you enter a value greater than 8, Firefox will issue *no more* than 8 concurrent requests. You could have 500 entered as the number and Firefox will only issue 8. The server has *no information* about the actual setting in the browser and responds solely to the requests the browser makes.



> Let's look at the title:


Cool. I read that to mean, "if I enable HTTP pipelining in Firefox, the result might be slower performance instead of faster performance". Do you understand the title to mean something else?



> In this thread, and most tweak posts....the issue has been about setting pipeline max requests above 8.
> So there are contextual considerations.


I believe we're mixing apples and oranges. This thread and most tweak posts are not in the actual article so what gets discussed in threads like this doesn't influence the article itself.



> The article initially describes the ability to change the setting and the reason why it's offered.
> Then it presents:
> excerpt>


Yep, that quote addresses the misinformation that is being distributed all over the place.



> This is not tested in the article.
> It is dismissed as I now know Mozilla didn't intend for a greater maximum number of requests.


Actually, this is the next sentence (which you also cited above):


> First, according to Mozilla's knowledge base, the number needs to be "any integer from 1 to 8 inclusive," which seems to imply that Firefox will only send a maximum of 8 HTTP requests at a time in any case. So setting it to anything larger than 8 isn't going to give any additional benefit.


Apparently, you chose to either ignore this information about the Mozilla Knowledge base article mentioned (which I linked to above) or you didn't locate the article to read what it had to say about the values mentioned.



> But the article even goes so far as to contradict the max rule by stating:


Yes, the article does state that. However, in a different context than how Firefox treats the maxrequests setting. Here is that complete sentence:


> Second, consider that web servers have a limited ability to handle requests for data. Certainly it varies from server to server and network to network, but every server has a limit at which it can no longer handle data requests, and when that limit is approached or reached, the response time from that server degrades, not just for the user who reached the limit, but for all users currently trying to connect to it. So setting the "maxrequests" to 30 would also be a selfish behavior, and could result in the server's owner implementing methods to restrict such excessive data requests in order to maintain overall server reliability.


What I read to mean, "web servers can handle only so much traffic _anyway_, so trying to crank up the maxrequests setting to some huge number could result in the server administrator taking action to limit such requests to preserve the stability of the server". The author is making a separate point here.



> There are reports of banning because of exactly this.
> Logically, if 9 or more requests could not be made, there would be no issue.


I don't agree since that would depend on the server in question. There are two things at work here:

The number of requests the browser will make
The number of requests the server will reliably service or even permit



> That article then restricted the discussion to the concerns of the efficiency of 8 or less pipeline max requests.
> It avoids discussion of 9 and more by merely stating it can't happen .
> And yet some users report being banned from servers for setting a greater integer.


The article restricted the discussion to the value range documented to be supported by the browser. Some users report being banned from servers _supposedly_ for using a setting higher than 8 but _they_ do realize Firefox won't issue more than a max of 8. I believe the reason the article I linked to above and the other one mentioned by the Mozilla community coordinator exist to address the fact that people are recommending value settings they don't really understand.



> As I posted earlier, I can tell no differences between the settings 2,8,32.
> I've also never been banned.
> I haven't been convinced 32 is better or worse, or if it doesn't even work as a tweak.
> I do know from the link you provided, Mozilla didn't intend a value above 8 to be used.


I think people's experiences with this kind of setting will always vary. People just need to realize that using a setting of 32 won't actually generate 32 requests.



> Back to the contradiction.
> Yes, I see Mozilla intended the max value to be 8.
> The contradiction is that it is reported there are servers seeing more than 8 requests and that blogger avoided addressing that issue by relying on the code not being able to run out of Mozilla's intention.


Contradiction? Where? Reports from *others* about their personal experiences are external to the scope of this one article. In the cases of others reporting issues with servers being confronted with more than a server allowed or permitted number of requests, use of HTTP pipelining will be one factor to consider but it won't necessarily be the ONLY factor. I had HTTP pipelining enabled when I first installed the FasterFox extension (since FasterFox enabled it by default). I had an issue with one site that suggested I had FasterFox installed and recommended I disable it. Turning off HTTP pipelining solved that issue for me. I just forget which site that was since that was so long ago.



> Consider........that's claiming it can't be done while admitting it happens.
> The article is flawed


I won't consider the article to be perfect but I think you're mixing the points being made in the article together.



> But it appears that FF will run out of spec.
> Or those people that make the claim of being banned were banned for another reason.
> No testing was done to show validity or performance of greater values.
> The article was flawed.


It's not a question of Firefox not running when configured with a maxrequests setting of who-knows-what, it's a matter of what the browser will actually do with "out of spec" settings. In this case, Firefox will cap at 8 and move on. Please tell me why the article should test values outside of the scope of the *documented* range? The author posted the various results experienced using values _within_ the documented range. Since it was understood by the author Firefox would not use a value greater than 8, it seems pointless to test values greater than 8. I'm thinking because the actual source code is available in that Knowledge base article, inspection of it provides the evidence of the max of 8 being used when a setting greater than 8 is entered by the user. If we were discussing a closed source browser, say like Opera or IE, then testing of values greater than 8 would have to be performed since there would be no other way to independently verify the documented value range.



> They certainly are aware of what the code implies.


There is nothing being implied. It doesn't get any more real than the code.



> But the issue remains.
> Now it's an issue of FF running out of spec and that's not being addressed by testing.
> If there were no reports of servers refusing too large a number of requests, I'd agree that time spent on a different endeavor would be more rewarding


I agree the issue remains but I differ with you on what the issue actually is. The issue isn't what Firefox does with an arguably invalid value, the issue is incorrect understanding of how to use the feature combined with incorrect use of this feature inadvertently causing problems for the browser user who really doesn't understand what the feature does and simply wants to make the browser "run faster". Keep in mind, the article we're discussing isn't the only article presenting this kind of info. Are you wanting to expand this discussion to include other articles similar to this one as well as factor in individual experiences not directly addressed by any of the articles?



> Not really.
> The link to Mozilla was informative, but the issue remains of servers banning users that inserted an integer greater than 8. To do that, more than 8 requests are being made.


Really. The links I provided above definitively put the issue of 8 requests being the max to rest. The issue of servers banning users is outside the scope of this article and would require more information from the server admin as to why the user was actually banned. Incorrect use of HTTP pipelining can contribute but without knowing more about each individual server that is banning browsers (in the link I posted above, that person WAS able to use IE to view the site that Firefox was banned from accessing) and for which reasons, we can't attribute that solely to use of HTTP pipelining simply by virtue of using it. What we CAN consider is other affects of HTTP pipelining on the browsing experience. Issues with images not loading isn't the same as the server banning a browser but can be a side-effect of HTTP pipelining being used and not even with a max setting of 8.



> Whoa...........you've also been using this argument in rebuttal of integers above 8.
> from that blogger:


What I've been stating is the article isn't recommending the "optimal" setting for maxrequests. I've been stating that Firefox will max at 8 regardless of a user setting of greater than 8. I've been trying to convey that and only that. They article isn't "here's how to find the optimal maxrequests setting in Firefox" but "be careful in using HTTP pipelining and you've been given some bad information about it." You've been arguing no testing has been done for a setting larger than the documented max (documented in the Knowledge base article AND the code itself) which implies the belief (or a past belief) that the setting entered by the user was "blindly" used by Firefox.



> The problem is that there in anecdotal evidence of more than '8' being used and being rejected by some servers.


The problem with using that evidence in this particular discussion is lack of information from those other incidents or instances.



> This issue is not addressed beyond showing Mozilla didn't intend for this to occur.
> The article was flawed


The point of the article wasn't to address the "anecdotal evidence" stories you mention. The point was to discuss the use of the feature and what kinds of effects it could have. You keep mentioning they didn't test the "out of spec" values but they certainly DID report their experiences with "in spec" values and those experiences varied as the values changed and their experiences varied from other Firefox users who use the feature.



> Actually, nope
> see above


Actually yep, see above. 



> To be honest, I'm not proficient in programming and wasn't able to follow and understand the links. I do accept that Mozilla intended the max integer recognized to be 8.
> However, as I've mentioned, some servers seem to be refusing users that set the integer higher.
> That's not being addressed. It shouldn't happen and the 'why' isn't addresses nor if there is , indeed, any advantage.


That's cool, I don't expect every Firefox user to be a computer programmer or anything. I know nothing of how the Knowledge base articles are written or what the documentation standards are. I might have written that Knowledge base a little differently but that's just me. With regard to the server side of this issue, again that is not the main point of the article. If it was, it would have focused MORE on the server side of things and less on the browser side of things. In fact, the server side was briefly mentioned in a paragraph and that's it. The "why do servers reject some HTTP pipelining request" question should be answered in a different article since that will be the focus of that article.



> tomdkat .......I'm not arguing for the tweak in question, or against it.
> I'm just not seeing enough information to clarify the issue of using a larger integer than 8.


At this point it should be pretty clear: a value larger than 8 isn't used and 8 will be the max used.



> The issue I encountered was not common to all large monitors, the discussion at Mozilla inferred that the issue had a commonality of existing with large monitors and certain hardware configurations. Those hardware parameters weren't obvious to me, no one seemed to be posting their setups.
> Obviously not many users are experiencing this issue or there would be a flood of complaints as Firefox 3 is becoming popular.
> I'm using an Acer AST 180 and Win xp mce 2005.
> I was using a Sony 21" Crt.
> I'll boot into Slax, later in the day, to see if the issue occurs with my Dell 17" CRT.


Gotcha. Sounds like it might be related to video drivers or adapters, possibly? It's not a big deal. I was just curious about your experience, that's all. 

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> The issue is one of misinformation. People are reading advice from others online recommending setting the option to values much greater than 8. You stated above you had it set to 32, at one point. The issue is, setting the value greater than 8 *does not* result in the behavior you might think it does. This is why people tried settings much larger than 32, like 100 or even 250 in one case I saw online somewhere. Since it's been established that the code enforces a max value of 8, a setting of 32, 100, 250, or 10,000 will result in Firefox using a max of 8 and the web server reacting to that however it does. Some won't care, others will. I don't know of a way to know this in advance other than trial and error. From what I've been reading in Mozilla articles on this, use of this feature is "at your risk". So, you're right in that the issue of misinformation being spread is still around because people are still recommending ineffective values with the idea being of "cranking up" the browser's performance.
> 
> (edited for brevity)
> 
> Peace...





> The issue is one of misinformation.


Agreed.



> People are reading advice from others online recommending setting the option to values much greater than 8. You stated above you had it set to 32, at one point.


This is also correct.
I've been varying it under FF2 , from 2 to 5 to 7 ( of recent) to 8 and 32.
And I've posted I'm not seeing and differences or any issues with any of those setting.



> The issue is, setting the value greater than 8 does not result in the behavior you might think it does.


The issue is.........you haven't posted any source that has tested and reported on integers above 8.
I've explained the logic for the necessity to test as there is anecdotal evidence of greater integers having an effect even to the absurdity that your authoritative source even commented to the existence of that effect.



> This is why people tried settings much larger than 32, like 100 or even 250 in one case I saw online somewhere.


You are having a problem explaining why there are claims that some servers are seeing a greater number of requests than 8.
Focus.........how can this exist if there is an actual limitation to 8?
It's not unreasonable to ask why this is being observed or if it's being observed correctly.
Your blogger admitted to the issue and avoided testing by claiming it couldn't happen.

This is an issue of logic.

It's not being addressed.
The blogger's article may be correct as far as it went, but it's flawed because it didn't follow up with testing the issue it denied occurred and then inferred evidence of it occurring 



> Since it's been established that the code enforces a max value of 8, a setting of 32, 100, 250, or 10,000 will result in Firefox using a max of 8 and the web server reacting to that however it does.


And yet the same blogger actually refers to a contradiction of the certainty of that statement.


> So setting the "maxrequests" to 30 would also be a selfish behavior, and could result in the server's owner implementing methods to restrict such excessive data requests in order to maintain overall server reliability.


That's not an 'if', there are reports of individuals being denied access from excessive requests over 8.
Even more curious, why so few if the tweak is popular.



> So, you're right in that the issue of misinformation being spread is still around because people are still recommending ineffective values with the idea being of "cranking up" the browser's performance.


Misinformation is always an issue.
What's lacking in your links is an explanation for why it's being reported that some individuals are denied access over excessive requests.
That's not misinformation, that's a lack of information that's needed to clarify what is reportedly being observed.

I've observed no issues setting pipeline maxrequests at 2,5, 7, 8 and 32.
They all seem the same to me, in contradiction to the Blogger's article.
True, I have nothing to measure any differences but the 'feel ' of the machine.......but I'm not seeing any testing in that article ....of 9 and up.... because Mozilla says so.
Could you imagine Gates getting away with that? 



> Nope, that's your misunderstanding. What I (and others) are saying is: if you enter a value greater than 8, Firefox will issue no more than 8 concurrent requests.


Anecdotal evidence suggests otherwise and I'm seeing no effort to reason why it isn't considered if only to convince other users like myself that there is nothing to the claims. Test for 2 thru 8 but not one more integer to prove a point? .
The article was flawed 

I'm waiting on better evidence to convince me, one way or another.



> Cool. I read that to mean, "if I enable HTTP pipelining in Firefox, the result might be slower performance instead of faster performance". Do you understand the title to mean something else?


Like I keep posting, the article is flawed.
I see nothing that has changed that, tondkat.
All testing was done between 2 and 8.
That is not the issue of this thread.
The issue is about changing the values and there is a ? existing.
Why, because of comments of denial to servers related to too many requests by users configured greater than 8.
I'm not claiming this has happened to me.
It hasn't.
I'm not even experiencing a difference in page loading from one setting to another.
In truth, even the testing that was presented at that blog site was of no value to me because I couldn't see any advantage of one value over another.
The question then also becomes, of what value was the info posted ....for me?
Might as well have been a blank page.



> I believe we're mixing apples and oranges. This thread and most tweak posts are not in the actual article so what gets discussed in threads like this doesn't influence the article itself.


One specific consideration that crops up in most tweak threads is.......pipelining.maxrequests. That is the issue at hand, now.
I did look back and see the thread starter recommends a value of 8.
I have no issue with it or 32, or 2 or 5 or 7.

It still remains, nothing has been presented that has tested to check if 9 and above is advantageous or deleterious, or does nothing.
I wouldn't keep harping on this other than because of statements like this:


> So setting the "maxrequests" to 30 would also be a selfish behavior, and could result in the server's owner implementing methods to restrict such excessive data requests in order to maintain overall server reliability.


Even more amazing, logically, the next paragraph started out:


> And it appears that is happening.


But then continues the focus on values for 8 and less. 
Testing is done to prove and disprove points of contention.
The article was flawed.

consider:


> settings from 5 to 8 resulted in the disruption every time we tested. Specifically, images loaded very slowly or not at all on the Google Image page we chose as our test page.


I chose the google image results for 'Madonna' and every image appeared and the full page loaded in what appeared a similar time for the settings 2, 5, 7, 8 and 32.

I'm not seeing any advantage to any preference!
Completely the opposite from what the blog article claimed.
Am I just lucky, or their test influenced by factors that disqualify their testing?

Again......I'm not arguing for or against.....I'm arguing there isn't much of any value being posted as no one seems to have tested this mythical setting and the article at the blog site is not only flawed, it appears to me, now, that their results are of little value.



> Apparently, you chose to either ignore this information about the Mozilla Knowledge base article mentioned (which I linked to above) or you didn't locate the article to read what it had to say about the values mentioned.


I've already acknowledged I missed that link and acknowledge that Mozilla wrote the code with the intention of 8 being the greatest integer recognized.



> I don't agree since that would depend on the server in question. There are two things at work here:
> 
> 1. The number of requests the browser will make
> 2. The number of requests the server will reliably service or even permit


You can disagree, but those are issue that are going unanswered.
Mozilla has coded for 8 as a max, but there does seem the user complaining about being banned for a number of requests greater than 8.



> I think people's experiences with this kind of setting will always vary. People just need to realize that using a setting of 32 won't actually generate 32 requests.


Personally, I have no idea how many are generated at that setting.
My logic is if it isn't offering an advantage, why change it.
I'm not seeing any advantage to any of the settings I've posted.

But the question is till out there.......how many requests can be generated above 8?
Mozilla would be a decent response, if not for the anecdotal.

And no one tests for this.....what? ....quirk?



> Contradiction? Where? Reports from others about their personal experiences are external to the scope of this one article.


That would do it.
It brings to question a reason to inquire.



> It's not a question of Firefox not running when configured with a maxrequests setting of who-knows-what,


Correct. I wasn't aware someone was suggesting that.



> it's a matter of what the browser will actually do with "out of spec" settings.


Correct.
I've only asked what the results are of testing those conditions and in response, all I get is resistance to the concept of verifying the situation with the results from testing.



> Please tell me why the article should test values outside of the scope of the documented range?


Only to confirm that 8 is indeed the maximum and what performance gains or detractions are possible if so.
Since the article mentioned issue with 30, it's logical to test to see what the setting accomplishes. As the tests went as far as 8, why include one more integer, like 30, as a test? It would settle the issue once and for all.



> There is nothing being implied. It doesn't get any more real than the code.


Sure it does. If code is flawed there will be unexpected results.
Your link ( http://forums.mozillazine.org/viewtopic.php?f=38&t=807255&st=0&sk=t&sd=a&start=15 ) seems to show a flaw. Too many connections and the reason seems unknown in that example.
From too much tweaking by the user?
I really don't know.......I'm not a programmer, just a user .



> I agree the issue remains but I differ with you on what the issue actually is.


The issue is .....you've posted articles which aren't fully addressing the concerns and issues of the tweak being discussed, imo.
I noted that right from the beginning of our exchange.



> Are you wanting to expand this discussion to include other articles similar to this one as well as factor in individual experiences not directly addressed by any of the articles?


I'm interested in any profession presentation which confronts the issue at hand and brings finality to the question......is 8 really the max.
You certainly haven't provided that criteria and I really have no professional opinion.....only questions from observation that go unanswered.
It might be said, I'm looking for a second opinion .....or even a third 



> The links I provided above definitively put the issue of 8 requests being the max to rest.


Link
All I got out of that was confusion.

Link
All I saw at this link was testing within Mozilla's specified parameters.



> Issues with images not loading isn't the same as the server banning a browser but can be a side-effect of HTTP pipelining being used and not even with a max setting of 8.


Interesting..............But I have no issues at 2,5,7,8, and 32 with images loading. I don't even see a difference in page loading.
Why didn't that the test at that blog site test an integer greater than 8, if only out of curiosity since so many users are modifying in that manner?
Why not just test and dispel this myth for once and all?



> What I've been stating is the article isn't recommending the "optimal" setting for maxrequests.


sigh!
It was making an argument to test for the most optimal setting for the user............but it gave no tests to confirm that anything above that magic 8 was a waste of time.

Remember the superfetch and XP? You could do the tweak, but nothing happened.
How so?.......nothing happened, nothing was reported to happen, because XP didn't support superfetch at all. There was a compelling argument it was a waste of time.
I'm waiting for that compelling argument that an integer above 8 is a waste of time .
The Mozilla link seemed a strong argument, but why are there comments that show up periodically that someone got banned from a server for having pipeline.maxrequests set at a value out of spec?

I think you're just being ornery 



> I've been stating that Firefox will max at 8 regardless of a user setting of greater than 8. I've been trying to convey that and only that.


Well, your link to Mozilla about the gentleman that was booted off for having too many connections ........only brought confusion to your claim, tondkat.
Obviously your interest is limited to the 'spec sheet' and curiosity is not an element.

From this discussion, I've become even more curious.
Is it faith, or just sloppiness that articles appear in blog sites that attempt to dispel invalid mods and then limit testing ?
Why bother even commenting to the fact that users are changing values out of spec and then run tests only within the spec?
That article would have had a very strong message if just one test had been done out of spec...... no matter what it divulged.



> The problem with using that evidence in this particular discussion is lack of information from those other incidents or instances.


No, the problem is awareness that anecdotal evidence exists ....and it's being ignored while at the same time testing was being done that would have defined the value, or lack of value...... in making that change.

All I do is point out the tests were incomplete as presented at that blog site and presented in this forum.
Even with in it's scope, the tests are not confirmed by my experiences with altering the integer in question.

Crazy.........I don't even see any value to the different settings while in spec...or out and you argue testing above 9 is not valid.
I'm not even seeing any benefit of using one integer over another.

I think you keep forgetting, I'm not arguing there is a performance gain over 8, I'm curious as to what testing does present as there are those that seem to experience requests going out at a greater rate than spec.
Obviously you haven't been able to google up such tests, or you would have posted them.
If you do find testing that finalizes the issue, post it or PM me with a link.......I am curious.



> The point of the article wasn't to address the "anecdotal evidence" stories you mention.


Then perhaps it wasn't appropriate for posting in this thread?


> Firefox pipelining speed tweak may actually slow down your browser


No tests were done showing that an integer above 8 had an effect, one way or another or even verifying there was no effect.
Only that Mozilla coded with a limit that hasn't been verified and anecdotal evidence exists that the coded max may not the limit.



> Actually yep, see above.


Nope 



> At this point it should be pretty clear: a value larger than 8 isn't used and 8 will be the max used.


No, not for the user. And that's the base for Mozilla.
Explanations for users need to be of a different nature than programmers, imo.
Something more compelling that 'we' relate to. .
It's the anecdotal evidence that brings speculation and testing would have confirmed or denied certain associations.

Perhaps some other authoritative source has tested FF out of this spec?


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> ....................
> Gotcha. Sounds like it might be related to video drivers or adapters, possibly? It's not a big deal. I was just curious about your experience, that's all.
> 
> Peace...


Might be.
FF2 has no issues, though.
I've upgraded to FF3 and have it working to just an acceptable level for TopSpeed where I had intense scrolling issues before, on the 21" crt.
The hack I posted seemed to help a lot where as a different hack I tried several months ago did nothing.
All the other sites I regularly visit like TSG display with no issues.

FF3 seems a little snappier and renders a tick quicker at most of the sites I visit.


----------



## tomdkat (May 6, 2006)

Stoner said:


> And I've posted I'm not seeing and differences or any issues with any of those setting.


Yep and this kind of experience is common. Some claim to experience performance increases, others have not.



> The issue is.........you haven't posted any source that has tested and reported on integers above 8.
> I've explained the logic for the necessity to test as there is anecdotal evidence of greater integers having an effect even to the absurdity that your authoritative source even commented to the existence of that effect.


Yep, such anecdotal evidence exists and I've posted *concrete facts* that prove those providing said anecdotal evidence don't understand how Firefox uses the setting. I've posted definitive information from Mozilla regarding how Firefox treats this setting. You've seen the source code itself. You've seen the Mozilla Knowledge base article. You've seen comments from well-known members of the Mozilla community stating Firefox won't use more than 8 requests if maxrequests is set to a number larger than 8. I've provided links to this information in previous posts. Now, please provide ME with definitive information from Mozilla developers or resources that indicates anything to the contrary of what I posted. From where did you get the number '32' to use for maxrequests in your browser configuration? A blog? A forum? Did you get that number from a Mozilla developer or from a Mozilla Knowledge base article? What reason do you have to insist a setting greater than 8 has ANY impact on this other than comments from people who clearly don't understand how Firefox is using the maxrequests setting? The source code _itself_ shows the max of 8 being applied and now that you've seen that (even though you admitted you didn't understand the code since you're not a programmer), how can you continue to give merit to a value, which is CLEARLY no honored by the source code, such that you deem "testing" needs to be performed? Another way to ask the question is: now that you've seen the concrete information I've provided in this thread, why are you apparently placing greater value on anecdotal evidence provided by people who don't fully understand the setting(s) they are using?



> You are having a problem explaining why there are claims that some servers are seeing a greater number of requests than 8.


Yep, this is true and it's because you haven't provided enough information for me to analyze. A server could have issues with my accessing the site because I'm hammering it with requests that have nothing to do with HTTP pipelining. In other words, there's no directly one to one correlation between web server response to an "influx" of traffic from one particular user agent and HTTP pipelining. HTTP pipelining *can* be a factor but this doesn't mean it will be the *only* factor. It seems like you're not understanding this point. Is this the case?



> Focus.........how can this exist if there is an actual limitation to 8?


Because HTTP pipelining *might not be the only factor involved*. Are you focusing?  Look at the thread I posted the link to before. The user described the problem and HTTP pipelining was raised as a possible cause as was the AVG link scanner. I posted above I wouldn't think the AVG link scanner would be the culprit but I didn't completely rule it out as I haven't followed that particular incident very closely. There could be some combinations contributing to that one individuals issue and the HTTP pipelining configuration would simply be one of the things on the list to investigate.



> It's not unreasonable to ask why this is being observed or if it's being observed correctly.
> Your blogger admitted to the issue and avoided testing by claiming it couldn't happen.


Now you're confusing things even more.  It's not unreasonable to ask why some web servers have problems with browsers that implement this kind of feature. It's not unreasonable to ask why a web server administrator would think the server was receiving an unreasonable number of concurrent requests from a particular user agent and configure the server accordingly. The blogger *gave an example* of how abuse of this kind of feature can cause issues for some web servers. Firefox supports this feature. So does Opera and Safari. In the case of Firefox, a max of 8 requests will be made if the browser is configured to make more requests. I don't know what limitations or restrictions Opera or Safari have relating to this feature (HTTP pipelining) or even if they allow users to configure the related settings somehow. The same webservers could or would have problems with those browser just as they would or could with Firefox with this feature enabled. Now, explain to me why you think HTTP pipelining would be the *only* cause of a server rejecting connections from a user agent because it deems the user agent is "flooding" it with too many requests?



> This is an issue of logic.


I don't consider it an issue of logic because your logical analysis is based basically on "hearsay". Now, if you want to ignore the facts I've provided above and want to discuss this on a purely theoretical level, by all means say so and we can certainly do that but to suggest that it's "possible" for Firefox to behave in a manner I've demonstrated to not be possible based on a single instance of a server issue one person encountered without establishing their configuration as being sound such that HTTP pipelining *would* be the sole cause of that server issue is ludicrous (at least to me). Provide a better foundation and maybe I'll change my view.



> The blogger's article may be correct as far as it went, but it's flawed because it didn't follow up with testing the issue it denied occurred and then inferred evidence of it occurring


So it's flawed because the article didn't go beyond the scope of it's intention?  Ok.... I guess....  You might have to explain that to me since the article was NOT intended to find the optimal setting.



> And yet the same blogger actually refers to a contradiction of the certainty of that statement.


The blogger actually refers to a hypothetical situation to illustrate why care must be taken when using this kind of performance improvement technique. Are you considering the author's example of a "high" maxrequests setting to be some kind of fact or something?



> That's not an 'if', there are reports of individuals being denied access from excessive requests over 8.


That's an example used to support the author's point of care being taken when using the feature.



> Even more curious, why so few if the tweak is popular.


I think this is dependent on the specific sites being visited. This morning, I was reading some Firefox bug reports on this issue and how Firefox misbehaves when HTTP pipelining is enabled (forget the maxrequests setting for now). When the feature is disabled, those same sites worked just fine, as expected. One of the developers (at least I think he was one of the developers) posted comments about how some commercial e-commerce sites are using poorly configured or mis-configured web servers which complicate the issue for the browser developer since there's nothing in the HTTP protocol to let a web server identify whether or not it supports HTTP pipelining or not. Not every site out there will be like this. Not every site out there will block a user agent if it determines it's being flooded with too m any requests. I think people should review Firefox HTTP pipelining bug reports to get a much better idea of the kinds of problems people have had with this feature.



> Misinformation is always an issue.
> What's lacking in your links is an explanation for why it's being reported that some individuals are denied access over excessive requests.


I've posted ONE link to ONE case. Could you provide others for me to review?



> That's not misinformation, that's a lack of information that's needed to clarify what is reportedly being observed.


The misinformation is "set maxrequests to 32" as part of the HTTP pipelining configuration when the Mozilla documentation on the setting clearly lists valid values as being 1-8 inclusive.



> I've observed no issues setting pipeline maxrequests at 2,5, 7, 8 and 32.
> They all seem the same to me, in contradiction to the Blogger's article.


 You know, I've had no scrolling issues with the topspeed.com site in Firefox 3 that you've reported experiencing. Is my experience in contradiction to yours or is it simply a different experience? How many people who have actually enabled this feature have done objective tests to actually measure the performance increase, if any? Or is it a perceived improvement because they made the changes with the hope of increasing performance?



> True, I have nothing to measure any differences but the 'feel ' of the machine.......but I'm not seeing any testing in that article ....of 9 and up.... because Mozilla says so.


Not because "Mozilla says so" but because that's not the point of the article.



> Could you imagine Gates getting away with that?


Well, Microsoft IS very well know for spreading FUD and people buy into that simply because Microsoft "said so". 



> Anecdotal evidence suggests otherwise and I'm seeing no effort to reason why it isn't considered if only to convince other users like myself that there is nothing to the claims. Test for 2 thru 8 but not one more integer to prove a point? .
> The article was flawed


Yep, anecdotal evidence suggests otherwise and that evidence can also be flawed. For this point to stand, you will have to provide anecdotal evidence of a Firefox user that had HTTP pipelining set to a number larger than 8 that resulted in Firefox, specifically, being blocked from accessing the server for no other reason than HTTP pipelining being configured AND with a value larger than 8. Give me that and we can talk. 



> I'm waiting on better evidence to convince me, one way or another.


You seem to have a lot of faith in the anecdotal evidence which you have yet to prove is sound.



> Like I keep posting, the article is flawed.
> I see nothing that has changed that, tondkat.


That's fine, I just want you to answer the question. 



> All testing was done between 2 and 8.
> That is not the issue of this thread.


The reason I posted ANY of the cautionary posts about using this feature is because it is known to sometimes cause problems. Look at this[/ur] Knowledge base article. It's not specifically about HTTP pipelining at all and discusses an issue that is reasonable for people to encounter despite it not being a desirable issue to encounter. Look at the first steps of things to try as part of the problem resolution process.



> The issue is about changing the values and there is a ? existing.
> Why, because of comments of denial to servers related to too many requests by users configured greater than 8.


No, it's because of problems people have experienced when enabling this feature and not using it properly. The "denial [of access] to servers" issue is just one and certainly not the only and most definitely not "guaranteed" to happen to anyone.



> I'm not claiming this has happened to me.
> It hasn't.
> I'm not even experiencing a difference in page loading from one setting to another.
> In truth, even the testing that was presented at that blog site was of no value to me because I couldn't see any advantage of one value over another.
> ...


Well, I'm certainly glad you're not the only one reading this thread and reading the links to the other pages which provide the more accurate information. If I intended for you to be the only person reading this info, I would have sent a PM. 



> It still remains, nothing has been presented that has tested to check if 9 and above is advantageous or deleterious, or does nothing.


Actually, I disagree with this. One could argue that YOU have performed said test since you indicated you didn't see any difference in performance regardless of the settings you chose.  I'm not going to make that argument but I thought you would get a kick out my mentioning it. 

Since the Firefox source code shows the max of 8, I'm thinking that's why people aren't conducting serious tests using values larger than that. I haven't spoken with anyone conducting tests so I haven't had an opportunity to ask them why they haven't used larger values.



> I wouldn't keep harping on this other than because of statements like this:
> 
> Even more amazing, logically, the next paragraph started out:


I see a pattern of you not picking up on the change of context. The "_And it appears that is happening_," wasn't in reference to the setting of 30 but in reference to HTTP pipelining being used more often to get browser performance improvements.



> But then continues the focus on values for 8 and less.
> Testing is done to prove and disprove points of contention.


Testing was done to show problems they encountered using valid values, let alone invalid ones.



> consider:
> 
> I chose the google image results for 'Madonna' and every image appeared and the full page loaded in what appeared a similar time for the settings 2, 5, 7, 8 and 32.


My experience was similar except I used the "IBM Logo" search criteria they used. 



> I'm not seeing any advantage to any preference!
> Completely the opposite from what the blog article claimed.
> Am I just lucky, or their test influenced by factors that disqualify their testing?


I think the fact that not everyone sees performance improvements means there are other variables at play. I'm in the same boat as you in that on my Internet connection at home, I don't see the performance increase. What I find most interesting is I installed the [url=http://swiftweasel.tuxfamily.org/]SwiftWeasel browser on Linux and sometimes use the Epiphany browser on Linux. Both are native 64-bit browsers and SwiftWeasel is optimized for *maximum* performance on Linux. It's compiled with different compiler options and has HTTP pipelining enabled by default and has maxrequests set to 8, by default. This is with a stock SwiftWeasel installation. Epiphany does NOT have HTTP pipelining enabled at all. I did some casual testing the other night and found Epiphany AND SwiftWeasel both performed about the same and both were faster than the stock Firefox 3.0.1 browser I'm using now. SwiftWeasel, Firefox, and Epiphany all use the Gecko rendering engine but I think Epiphany uses an older version (a pre-Firefox 3 version).

I think your personal experience further illustrates the point that tweaking the browser settings just for the sake of it might not be worth the effort if the results are appreciable.



> Again......I'm not arguing for or against.....I'm arguing there isn't much of any value being posted as no one seems to have tested this mythical setting and the article at the blog site is not only flawed, it appears to me, now, that their results are of little value.


What "mythical" setting is that? One larger than 8? I wonder why such large values for maxrequests are so popular, since they haven't been demonstrated to _actually_ work by anyone.



> You can disagree, but those are issue that are going unanswered.
> Mozilla has coded for 8 as a max, but there does seem the user complaining about being banned for a number of requests greater than 8.


Ahhh, now we're getting somewhere.  That thread I posted a link to cited a particular case where Firefox, specifically, was "banned" from the site. IE on the same machine could access it just fine. (I've already posted all of this already, so this is redundant) In that user's case, HTTP pipelining was identified as a possible cause. The AVG link scanner was identified as a *possible cause*. I haven't followed the thread to see if they actually came up with the specific cause and last I checked, they had not. I didn't post a link to that thread as a way to say, "see, you shouldn't use HTTP pipelining" but to show the kinds of things that can result from the use of it. I wrote *can*, not *will*.



> Personally, I have no idea how many are generated at that setting.


I think that's the case for almost everyone using it. 



> My logic is if it isn't offering an advantage, why change it.
> I'm not seeing any advantage to any of the settings I've posted.


Leave it at 32 if you like, just as long as you understand you're not benefiting any more than if you had it set at 8. It's about understanding the configuration changes you're making (with "you" being used in a general sense).



> But the question is till out there.......how many requests can be generated above 8?
> Mozilla would be a decent response, if not for the anecdotal.


I think they give this answer: 0 The code caps the requests at 8 and the code is definitive. What would be awesome is an extension that showed the active requests somehow so you could see them "working". I think I might have mentioned that already.



> That would do it.
> It brings to question a reason to inquire.


I've got no issue with questioning the information and research concrete answers. However, above you stated it was a contradiction and that is different. So, how does the contradiction fit in again? 



> Correct. I wasn't aware someone was suggesting that.


Man, it's all over the web:

http://www.mydigitallife.info/2007/10/16/speed-up-your-firefox-by-adjusting-your-http-pipelining/


> Double click network.http.pipelining.maxrequests, change the integer value in the pop-up window to 30. By entering 30, this means it will make 30 requests at once to the responding server.


http://macosxcocktail.blogs.com/cocktail/2005/01/improve_firefox.html


> Double-click the network.http.pipelining.maxrequestsm, type 30 and click OK


http://lifehacker.com/software//speed-up-firefox-030871.php


> Set "network.http.pipelining.maxrequests" to some number like 30. This means it will make 30 requests at once.


http://www.askdavetaylor.com/are_there_some_tricks_to_speed_up_firefox.html


> If your Firefox is set up like mine, the first two will be set to "false". Change them to "true" and then enter a value like 20 for maxrequests.


http://www.freerepublic.com/focus/news/1299854/posts


> Set "network.http.pipelining.maxrequests" to some number like 30. This means it will make 30 requests at once.


Craziness! 



> I've only asked what the results are of testing those conditions and in response, all I get is resistance to the concept of verifying the situation with the results from testing.


The cause of the resistance is that we're talking about a known circumstance. You've seen the Firefox code. People would LOVE to see the Windows code to learn things that are a mystery today. In this case, the testing would be useless since we already know what the code actually instructs the browser to do. It's been my experience that people test things they don't know.



> Only to confirm that 8 is indeed the maximum and what performance gains or detractions are possible if so.
> Since the article mentioned issue with 30, it's logical to test to see what the setting accomplishes. As the tests went as far as 8, why include one more integer, like 30, as a test? It would settle the issue once and for all.


See, this is what I don't understand. You want the test conducted to confirm something that the code establishes as definitive fact. It's like you're ignoring the importance and relevance of the actual source code in question. Getting back to the article, the point of the article was NOT to find the "optimal" number. The optimal maxrequests setting is completely different from the maximum supported value. The optimal setting would require lots of testing be done to find the appropriate setting deemed optimal. Why? Because that setting isn't already known AND it will probably vary from user to user. When you set your Firefox to have a value of 32, did you question it before setting it? And if so, what information were you provided that convinced you that 32 would be a "good number" to use? This is information I would LOVE to see. 



> Sure it does. If code is flawed there will be unexpected results.


Wait a minute, I thought you admitted you didn't understand the code I provided the link to yet you're open to questioning it? That code has far more credibility than the anecdotal evidence you mention and I'm floored by this comment. I guess the only way to know for sure if that code segment is flawed is if there have been any bug reports opened against it. Anyway....



> Your link ( http://forums.mozillazine.org/viewtopic.php?f=38&t=807255&st=0&sk=t&sd=a&start=15 ) seems to show a flaw. Too many connections and the reason seems unknown in that example.
> From too much tweaking by the user?
> I really don't know.......I'm not a programmer, just a user .


That thread shows a flaw in SOMETHING and we don't know what it is yet. HTTP pipelining? Don't know. Something else they configured? Don't know. There isn't enough information to identify HTTP pipelining as _the_ cause and you really need that in order to use this case as a foundation of your argument.

(My post is too long, so this is part #1)


----------



## tomdkat (May 6, 2006)

(here is the rest)



> The issue is .....you've posted articles which aren't fully addressing the concerns and issues of the tweak being discussed, imo.
> I noted that right from the beginning of our exchange.


Where did I state the links I posted were to articles fully addressing the concerns of using HTTP pipelining? How many articles did you read that fully addressed the concerns of HTTP pipelining in Firefox before configuring the value of 32? The articles floating around (regardless of my posting links to them or not) are there to provide information to help people. Some articles provide information with the intent of improving the performance of the browser. Some articles post incorrect information despite the intent of helping to improve performance. I posted links to some potential "gotchas" that exist with the use of this feature. ALL of this information should be used to determine if mucking with this setting is worth it for the user. How many people will configure this setting, experience a problem, and then slam Firefox as "sucking" because it can't display images on some page right. If this behavior is caused by them configuring HTTP pipelining and incorrectly, they would have shot themselves in the foot and won't realize it until they start a thread on a forum like this one. If the info I post gives people more info to digest in the interest of providing a stable web browsing environment, I feel it's worth the effort to post that information.

You started our exchange by pointing out logical fallacies and expressing confusion about the nature of the article. 



> I'm interested in any profession presentation which confronts the issue at hand and brings finality to the question......is 8 really the max.


The code does this. Any professional asked to confirm this will ask to see the code and they will see the code you saw. The code is final.



> Link
> All I got out of that was confusion.


That's the nature of forums sometimes.  Still, it's interesting that HTTP pipelining, the feature we're discussing here, was identified as a possible culprit.



> Link
> All I saw at this link was testing within Mozilla's specified parameters.


That's not true. You also saw the results which identified issues and problems you didn't experience. Let's keep it real, ok? 



> Interesting..............But I have no issues at 2,5,7,8, and 32 with images loading. I don't even see a difference in page loading.
> Why didn't that the test at that blog site test an integer greater than 8, if only out of curiosity since so many users are modifying in that manner?
> Why not just test and dispel this myth for once and all?


It's interesting that I also have not experienced those problems and even more interesting that others have. Otherwise, there would be no anecdotal evidence for you to reference unless it's all your own evidence. Why didn't the article's author test more than 8 maxrequests? I haven't asked him personally but I imagine it's because of the information in the Knowledge base article I also link to above which you seemed to want to dismiss. If the author wanted to focus on the significant of Firefox capping maxrequests at 8, I'm sure he would have conducted appropriate tests to disprove that. Unfortunately, the author didn't write an article focusing on the significance of Firefox capping maxrequests at 8. Maybe you should send him an e-mail asking him to do so. 



> sigh!
> It was making an argument to test for the most optimal setting for the user............but it gave no tests to confirm that anything above that magic 8 was a waste of time.


No, it wasn't. It was making the point that use of HTTP pipelining can have a negative impact on Firefox's performance instead of the positive impacts everyone desires. At the end, they do suggest enabling the feature and suggest a range for people to try different settings to see which ones work best for them. You've proven your results differ from theirs and my results might have actually differed from yours even though we generally experienced the same or similar thing.



> Remember the superfetch and XP? You could do the tweak, but nothing happened.
> How so?.......nothing happened, nothing was reported to happen, because XP didn't support superfetch at all. There was a compelling argument it was a waste of time.
> I'm waiting for that compelling argument that an integer above 8 is a waste of time .
> The Mozilla link seemed a strong argument, but why are there comments that show up periodically that someone got banned from a server for having pipeline.maxrequests set at a value out of spec?


The Mozilla source code provides the MOST compelling fact about the nature of the value 8. Again, in the case of the server ban that is a single incident and one that has not been solely attributed to HTTP pipelining even though it was on the list of possible causes. Considering you admitted getting confused by reading that thread, I can now understand why you struggle with how HTTP pipelining relates to it.



> I think you're just being ornery


Wow, I was just thinking the same about you.  :up: Great minds...... 



> Well, your link to Mozilla about the gentleman that was booted off for having too many connections ........only brought confusion to your claim, tondkat.
> Obviously your interest is limited to the 'spec sheet' and curiosity is not an element.


My "claim"? What claim is that? In the case of the server ban/block, I'm definitely curious about that and I'm VERY curious to read the answers to the questions I posed above. 



> From this discussion, I've become even more curious.
> Is it faith, or just sloppiness that articles appear in blog sites that attempt to dispel invalid mods and then limit testing ?


Well, considering the code is available from the Knowledge base article, I don't know how much faith is involved. As for sloppiness, I think the testing done was relevant to the point of the article AND was in line with the Knowledge base documentation on the setting.

Is just sloppiness that articles appearing on blog sites that attempt to spread valid information frequently fail to do so?



> Why bother even commenting to the fact that users are changing values out of spec and then run tests only within the spec?


Because of the plethora of sites and blogs telling users to use "out of spec" values! The sites that attempt to correct this misinformation clearly state Firefox will use no more than 8 and that is intended to dispel the information being posted elsewhere.



> That article would have had a very strong message if just one test had been done out of spec...... no matter what it divulged.


You know, I don't think so. Let's assume that article contained the tests you as seeking. If they had actually posted that information, I would have immediately gone to the Mozilla community to seek verification. Only when the Mozilla community confirmed the findings, would I accept or believe them. If the article in question WOULD have had the results from the testing you believe is important, would you have simply accepted it?



> No, the problem is awareness that anecdotal evidence exists ....and it's being ignored while at the same time testing was being done that would have defined the value, or lack of value...... in making that change.


The specific anecdotal evidence you cite is weak, at best, in supporting your position. I mentioned it since it involved HTTP pipelining BUT I never stated pipelining was the sole cause of that person's issue, but you seem to be convinced it is or was. The issue I have with your "anecdotal evidence" is you appear to hold it to a certain standard that has yet to be proven. "Just because" someone reported a problem doesn't mean they got the report right or that what _they_ thought the problem was actually turned out to be the problem. A plethora of anecdotal evidence means there is definitely something going on that needs to be looked at but not much more than that. Then the developers confirm an actual bug or not.



> All I do is point out the tests were incomplete as presented at that blog site and presented in this forum.
> Even with in it's scope, the tests are not confirmed by my experiences with altering the integer in question.


Nor were the tests intended to demonstrate something outside the scope of the article. You seem to like having these tests conducted, so what testing results did you review before deciding to enable HTTP pipelining and choosing the value of 32? You've posted several times you haven't seen a change in performance yet you made the configuration change. Why? Does that seem logical? 



> Crazy.........I don't even see any value to the different settings while in spec...or out and you argue testing above 9 is not valid.
> I'm not even seeing any benefit of using one integer over another.


I argue testing above 8 is invalid since we've got access to the source code, which is a known entity. We've actually got all the info we need, you just don't realize it yet or don't want to accept it. 



> I think you keep forgetting, I'm not arguing there is a performance gain over 8, I'm curious as to what testing does present as there are those that seem to experience requests going out at a greater rate than spec.


Most _think_ they are sending out the number of requests they specify. The server "banned" case is appearing to be an isolated incident. I'm sure you'll post links to other incidents like that since there's plenty of anecdotal evidence to support that situation.



> Obviously you haven't been able to google up such tests, or you would have posted them.
> If you do find testing that finalizes the isue, post it or PM me with a link.......I am curious.


To be honest, I really haven't looked. I consider the issue finalized since we've seen the code.



> Then perhaps it wasn't appropriate for posting in this thread?


It sure was appropriate since this thread is about enabling HTTP pipelining in Firefox, not anecdotal evidence.



> Only that Mozilla coded with a limit that hasn't been verified and anecdotal evidence exists that the coded max may not the limit.


Hasn't been verified? Do you mean anecdotally? It would be interesting to see if there was a QA test case for this. Maybe one was written as part of the code check-in process.



> Nope


Yep. 



> No, not for the user. And that's the base for Mozilla.


Given the plethora of bad information regarding this being disseminated, I have to agree. People are simply "believing the blogs" they read and don't confirm with the Mozilla community.



> Explanations for users need to be of a different nature than programmers, imo.
> Something more compelling that 'we' relate to. .
> It's the anecdotal evidence that brings speculation and testing would have confirmed or denied certain associations.


I do agree the Knowledge base article could have been written better but I've already posted that above. The anecdotal evidence doesn't really bring much to the table as much as better written documentation would have.



> Perhaps some other authoritative source has tested FF out of this spec?


If anything, the QA group might have a test case that's publicly available. They would be the ones to delve in to this sort of thing vs end users.

Have a great weekend! 

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> Yep and this kind of experience is common. Some claim to experience performance increases, others have not.
> 
> (edited for brevity)
> 
> (My post is too long, so this is part #1)





> Yep, such anecdotal evidence exists and I've posted concrete facts that prove those providing said anecdotal evidence don't understand how Firefox uses the setting.


That's not the current issue.



> I've posted definitive information from Mozilla regarding how Firefox treats this setting. You've seen the source code itself. You've seen the Mozilla Knowledge base article. You've seen comments from well-known members of the Mozilla community stating Firefox won't use more than 8 requests if maxrequests is set to a number larger than 8.


That is very true.
However, you overlook the users view of anecdotal evidence being contradictory and don't relate to the user that is interested in seeing this issue settled in a positive manner.



> Now, please provide ME with definitive information from Mozilla developers or resources that indicates anything to the contrary of what I posted.


Why?
I'm not challenging the claim Mozilla coded for a max integer, my query is about tweaking overriding that max. because on anecdotal evidence.



> From where did you get the number '32' to use for maxrequests in your browser configuration? A blog? A forum?


A forum.



> Did you get that number from a Mozilla developer or from a Mozilla Knowledge base article?


Already answered. Just as MS tweaks abound from non MS sources, so do these Firefox tweaks.



> What reason do you have to insist a setting greater than 8 has ANY impact on this other than comments from people who clearly don't understand how Firefox is using the maxrequests setting?


Clearly begging the question.
The issue isn't one of understanding the how it's coded, the issue is explaining why anecdotal evidence popped up at all.
Tests would verify the issue positively.
You seem very negative on that concept.



> The source code itself shows the max of 8 being applied and now that you've seen that (even though you admitted you didn't understand the code since you're not a programmer), how can you continue to give merit to a value,


That's the issue.........I don't give value to an integer greater than 8, I question what is occurring above 8.

I should note, you are becoming disingenuous in this discussion.
I've made it clear in the past I see no improvement in using an integer greater than 8.



> which is CLEARLY no honored by the source code, such that you deem "testing" needs to be performed?


Yep, it would certainly settle the issue and clarify whether those anecdotal claims are worthy or not.



> Another way to ask the question is: now that you've seen the concrete information I've provided in this thread, why are you apparently placing greater value on anecdotal evidence provided by people who don't fully understand the setting(s) they are using?


Again, your tone is disingenuous.
Anecdotal evidence exists. It's not an issue of placing greater value on it, the point is it exists and tests would dispel any further confusion over that evidence.



> Yep, this is true and it's because you haven't provided enough information for me to analyze.


LOL!
Good one 
I'm the one asking the probing questions, you're the one claiming there are no bugs in Firefox. Updates, anyone 



> Because HTTP pipelining might not be the only factor involved.


Focus.......that's what testing might just bring to light 



> Now you're confusing things even more


That was you link, not mine 



> I don't consider it an issue of logic because your logical analysis is based basically on "hearsay"


But it is based on logic. The purpose to either verify or deny hearsay by way of testing.
Because these tweaks are largely spread by hearsay, the logical way to handle anecdotal comments is to prove by testing. This isn't unreasonable as the article you posted was underway in tests that would have been decisive....or maybe not as their results looked questionable.
Perhaps better testers ?



> Now, if you want to ignore the facts I've provided above and want to discuss this on a purely theoretical level,


]
Correction........an incomplete set of facts ....remember, you aren't into the concept of testing the range being discussed 



> I've demonstrated to not be possible based on a single instance of a server issue one person encountered without establishing their configuration as being sound such that HTTP pipelining would be the sole cause of that server issue is ludicrous (at least to me).


I think it's ludicrous to have argued this long when competent testing could have produced a compelling argument for me to review  



> Provide a better foundation and maybe I'll change my view.


So...it's about you, not about the user and the performance of his browser?
I was contemplating that with all the effort you've put into this to prove you are correct.
Perhaps you noticed, I have mentioned it several times......I'm looking for a compelling reason, mostly out of curiosity now as I've realized changing the values seems to have no effect on my computer, whether that magic 8 as you put it, has all the magic that's claimed because of anecdotal evidence.
I now think Mozilla intended for 8 to be the max. It's that anecdotal that I'm curious about and your method of discovery doesn't include discovery. 



> So it's flawed because the article didn't go beyond the scope of it's intention?


Your words, not the presentation of the blogger.
Really, this is just repetition, tomkadt.
It's been discussed, nothing's changed.



> The blogger actually refers to a hypothetical situation to illustrate.......


And that's where the anecdotal comes in and the testing limited.
The next paragraph enforced the contradiction and shallowness of the article.
Again....this is merely repetitious.



> I've posted ONE link to ONE case. Could you provide others for me to review?


Not really. I'm not interested in putting much more effort into this.
Anecdotal remarks have floated around since I first realized Firefox could be tweaked and that's been more than several years ago.
To be honest, I'm not expecting anything more from you other than repetition.
Really, there isn't much more to post about that's relevant other than finding someone that's actually tested these tweaks at above 8 in order to satisfy curiosity about anecdotal comments.



> You know, I've had no scrolling issues with the topspeed.com site in Firefox 3 that you've reported experiencing. Is my experience in contradiction to yours or is it simply a different experience?


Wrong question.
What's wrong with the Firefox3 code?
Bet it wasn't coded to do that 



> How many people who have actually enabled this feature have done objective tests to actually measure the performance increase, if any?


Performance increase in scrolling?
When I spoke of the scrolling performance, it was more in the context of visual quality, but the scrolling was unusually slow the first time I installed FF3. A good 20 seconds to maneuver from the top of the page to the bottom at TS. And I do mean pulling the slider all the way down and watching the screen play catch up.
Yeah....I'm doubtful the programmers intended that, but that's the way the code responded on my computer and the google link I posted was evidence that FF3 had a bug in it that was affecting considerably more than a handful of people.



> Not because "Mozilla says so" but because that's not the point of the article.


The point was inferred to be about settings that were of a negative nature, even mentioning setting beyond 8, but the tests were limited to 8 because Mozilla posted 8 was the max value recognized. M said so, thus it was true and the testing excluded issues that were also of contention.



> Yep, anecdotal evidence suggests otherwise and that evidence can also be flawed.


Yep....and testing would finalize the discussion 



> For this point to stand, you will have to provide anecdotal evidence of a Firefox user that had HTTP pipelining set to a number larger than 8 that resulted in Firefox, specifically, being blocked from accessing the server for no other reason than HTTP pipelining being configured AND with a value larger than 8. Give me that and we can talk.


Too much effort 
Anyway, you've already acknowledged that anecdotal comments exist, so I'd only be proving something you are aware of.
Nice try........in Civ Debate I call it inducing time wasting 



> You seem to have a lot of faith in the anecdotal evidence which you have yet to prove is sound.


I think you have comprehension issue 
It's those anecdotes that make me curious. It's your position on not testing under those circumstances I find quite interesting 



> That's fine, I just want you to answer the question.


Lots a luck, because most of what I have are questions.
I think testing would resolve them, but I'm not going to fret if they aren't answered.



> The reason I posted ANY of the cautionary posts about using this feature is because it is known to sometimes cause problems.


And the issue is compounded by setting the value out of spec.
It appears some people have problems with that. Others don't.
I'm just curious as to why.........and you aren't 



> No, it's because of problems people have experienced when enabling this feature and not using it properly. The "denial [of access] to servers" issue is just one and certainly not the only and most definitely not "guaranteed" to happen to anyone.


see above.



> Actually, I disagree with this. One could argue that YOU have performed said test since you indicated you didn't see any difference in performance regardless of the settings you chose.


Yes, I see no benefit in my situation.
But that was not a very scientific test by any means 
I don't think I proved much beyond showing that published results aren't always representative of the issue.



> Since the Firefox source code shows the max of 8, I'm thinking that's why people aren't conducting serious tests using values larger than that.


Probably.....but, even though I'm not a programmer, I do hit some sites like Ars where these issues are often discussed and I don't remember any members delving into the issue by testing. So, is accurate testing even a common event in FF tweaking?



> I see a pattern of you not picking up on the change of context. The "And it appears that is happening," wasn't in reference to the setting of 30 but in reference to HTTP pipelining being used more often to get browser performance improvements.


Perhaps the author needs a few courses in composition, because that's not the impression I got.



> Testing was done to show problems they encountered using valid values, let alone invalid ones.


Sad that. The article would have been so much more complete. 
But I might never even have tried out their tests and found their testing was not comparable to all configurations.



> My experience was similar except I used the "IBM Logo" search criteria they used


Madonna looks better 



> I think your personal experience further illustrates the point that tweaking the browser settings just for the sake of it might not be worth the effort if the results are appreciable.


I don't think that's an absolute.
I've had this current computer about 2 years and did the tweaks on initial setup.
But I did get to test a before and after on a Dell P3 800 when I was using 98se and FF 1.5 ( maybe even older)
There was a noticeable difference. The same tweaks I had up until this thread..... I had then on the Dell.
I did some of the tweaks in this thread on my current computer. Only a slight improvement......FF2 was already quick and there isn't much room for improvement as I suspect any bottlenecks are hardware or RoadRunner issues.

The biggest speed up I've seen, though, I think was upgrading XP with SP3.
That seemed to put a lot of snap into all my apps including FF2.
I think FF3 is a 'tad' faster, but not as much as many report.



> What "mythical" setting is that? One larger than 8? I wonder why such large values for maxrequests are so popular, since they haven't been demonstrated to actually work by anyone.


Yes. 
I have no idea. 
Usually I see tweaks in groups and when I first made then, I did it as a group and was satisfied with the results.... as most here at TSG also commented.



> Ahhh, now we're getting somewhere. That thread I posted a link to cited a particular case where Firefox, specifically, was "banned" from the site.


That was an example of excessive connections, not requests.
But it seemed that might have been tweaking that brought unexpected results.
This is the concept that interests me concerning pipeline maxrequests.
Are there tweaks that contradict causing more requests than coded for?



> Leave it at 32 if you like, just as long as you understand you're not benefiting any more than if you had it set at 8. It's about understanding the configuration changes you're making


I'm at 2 right now. I see no reason to change.



> However, above you stated it was a contradiction and that is different.


It's the imagery of a contradiction that brings curiosity, tomdkat.
Without the anecdotal, there is nothing to be curious about.
The anecdotal is a contradiction. Testing would prove whether it's a valid event, or just smoke.



> Man, it's all over the web:


These were your words I was responding to:


> It's not a question of Firefox not running when configured with a maxrequests setting of who-knows-what,


My response: *"Correct. I wasn't aware someone was suggesting that. " *
None of your links concern Firefox not running.
I hope you didn't put too much effort into a search.



> The cause of the resistance is that we're talking about a known circumstance.


It seems you pick and choose what known circumstances are.
I presented an anecdotal case of scrolling issues.
It appears to be a coding issue in Firefox3 as it doesn't appear in FF2 or IE.

Anecdotal evidence is what draws investigation.



> It's been my experience that people test things they don't know.


Science is much like that. It's how the knowledge base is expanded.



> You want the test conducted to confirm something that the code establishes as definitive fact


Whoops....you again forgot about anecdotal evidence.
From what I read, code is never perfect. There's always a bug waiting to be found.
I have one in the new FF3.......still. Scrolling. And there is anecdotal evidence all over the internet.
Do you claim it doesn't exist or need to be investigated just because it doesn't occur on your computer?



> Getting back to the article, the point of the article was NOT to find the "optimal" number. The optimal maxrequests setting is completely different from the maximum supported value. The optimal setting would require lots of testing be done to find the appropriate setting deemed optimal.


I suggest you reread your link.
Link
Comments about throttling performance were linked to the setting and testing was done to show the optimal settings versus the least ....for their specific configuration and internet connection. 
A flaw in the article is that comments were made to running out of spec, but never addressed in testing.



> Why? Because that setting isn't already known AND it will probably vary from user to user.


Your argument is confused.
see above.
It's pretty obvious their results didn't relate to all internet connections.
Nothing that I posted related to your response.



> When you set your Firefox to have a value of 32, did you question it before setting it?


You are repeating yourself in this thread.
I've already addressed that.



> And if so, what information were you provided that convinced you that 32 would be a "good number" to use? This is information I would LOVE to see.


At the time, that was the suggestion that was posted.
As explained, these tweaks are generally posted as groups and done en mass.
That I tweak outside the specs is not the issue.
The issue is..... what is occurring when I do it?
You have a pat answer, but it does avoid anecdotal comments.
Essentially, you fall back on 'the code is perfect' as a rationale not to question.
Us users are quite aware programmers aren't perfect 



> Wait a minute, I thought you admitted you didn't understand the code I provided the link to yet you're open to questioning it?


Non sequitur.
I don't have to know code to realize that code ( in general) is not perfect.



> That code has far more credibility than the anecdotal evidence you mention and I'm floored by this comment.


Well, you can get up off the floor at your discretion. 
Bugs happen.
Anecdotal comments happen.
Sometimes there's a connection.
You now deny bugs can happen...........interesting.



> I guess the only way to know for sure if that code segment is flawed is if there have been any bug reports opened against it.


Or test the issue, in this case......whoa!....can't do that, that would be an act of discovery and it's not in your play book..........



> That thread shows a flaw in SOMETHING and we don't know what it is yet. HTTP pipelining? Don't know. Something else they configured? Don't know. There isn't enough information to identify HTTP pipelining as the cause and you really need that in order to use this case as a foundation of your argument.


Essentially, you just don't know.
How do you think you can possibly resolve that problem without some form of testing/experimentation/rewriting of code/or configuration to see what is the cause of his problem?
Well, here I am as user that has seen people post issues from using a greater value of pipelining requests than spec and I listen to you tell me the code is perfect.
Trust me what I say I'm not impressed. Not with the code, With you estimation of perfection being a rule with out exception.
IMO....a test would be more compelling that your repetition of...... there are no errors as they are not possible according to Mozilla.
Well, Mozilla is a good browser. I like it better than IE. But perfect? Not from what I've seen.



> (My post is too long, so this is part #1)


I'll get to it eventually..............amazing, all because you posted a crappy article whose author may or may not have composition issues


----------



## tomdkat (May 6, 2006)

Stoner said:


> That's not the current issue.


But it's most definitely relevant to the discussion. You keep mentioning anecdotal evidence as if you assume it must be correct or accurate by virtue of mere existence.



> That is very true.
> However, you overlook the users view of anecdotal evidence being contradictory and don't relate to the user that is interested in seeing this issue settled in a positive manner.


From all the posts I've read on other forums about his very discussion we're having, you are the only person to raise ANY kind of issue with Firefox capping maxrequests at 8 if the user specified a larger value. I'm not seeing your kind of response anywhere else. From what you've posted thus far, your "anecdotal evidence" appears to be one incident from a thread I posted. Please provide additional anecdotal evidence to support your position. The users who have read the Knowledge base article and who have read other forums where the same information have been posted might or might not have already settled this issue in their mind. They might realize they got bad info from whatever source suggested the setting of 20 or 32 or whatever and modified their settings accordingly.



> Why?
> I'm not challenging the claim Mozilla coded for a max integer, my query is about tweaking overriding that max. because on anecdotal evidence.


The "claim"? What "claim"? Your question makes no sense.



> Already answered. Just as MS tweaks abound from non MS sources, so do these Firefox tweaks.


I see. What kind of testing inquiries did you make on the forum where you found info on this feature? Or did you just accept it at "face value"?



> Clearly begging the question.
> The issue isn't one of understanding the how it's coded, the issue is explaining why anecdotal evidence popped up at all.
> Tests would verify the issue positively.
> You seem very negative on that concept.


You're right, it's not an issue of understanding how it's coded, it's an issue of understanding how it is *used*. I don't understand why think a test would change anything considering the code itself gives all the answers. We're not talking about an unknown here, we're talking about a not understood.



> That's the issue.........I don't give value to an integer greater than 8, I question what is occurring above 8.


The code is telling you nothing is occurring but you're not listening to it.



> I should note, you are becoming disingenuous in this discussion.
> I've made it clear in the past I see no improvement in using an integer greater than 8.


That's to be expected. You've also stated you haven't seen any improvement in performance using any of the settings, like was described in the article. I almost got the impression you expected some kind of performance change of any kind simply because of what was contained in the article.



> Yep, it would certainly settle the issue and clarify whether those anecdotal claims are worthy or not.


I would consider having the relevant information in the anecdotal experiences to determine if the claims were even close to being worthy of consideration. "Just because" isn't good enough for me.



> Again, your tone is disingenuous.
> Anecdotal evidence exists. It's not an issue of placing greater value on it, the point is it exists and tests would dispel any further confusion over that evidence.


It most certainly IS an issue of you placing greater value on the anecdotal evidence, which you haven't provided other than a single instance AND an instance I introduced into the discussion. I've provided *fact* supporting my position and you're border line dismissing that fact in lieu of the presence of anecdotal evidence, which has amounted to a single incident thus far. I guess I'm looking for something of more substance to make the anecdotal evidence you continue to mention of greater value to this discussion for me. At the very least, post at least one other example of your anecdotal evidence.



> LOL!
> Good one
> 
> I'm the one asking the probing questions, you're the one claiming there are no bugs in Firefox. Updates, anyone


I would say you're asking questions but I would have to question whether they are "probing" or not.



> Focus.......that's what testing might just bring to light


That's the thing, the light is already shining brightly and it's so bright, I need to put on some shades. 



> That was you link, not mine


Yep, it's the link I provided but unfortunately, I can't control your understanding of the article.



> But it is based on logic. The purpose to either verify or deny hearsay by way of testing.


Testing? We've got the actual code to provide the answer!



> Because these tweaks are largely spread by hearsay, the logical way to handle anecdotal comments is to prove by testing.


Ok, on the forum where you initially got the value of 32 to use for maxrequests, did you ask them what kind of testing was performed to determine 32 was a "good" number to use? If so, could you post a link to that thread so I can see the questions you asked and how they were received?



> This isn't unreasonable as the article you posted was underway in tests that would have been decisive....or maybe not as their results looked questionable.
> Perhaps better testers ?


Perhaps but given the nature of the article, I don't think they tested insufficiently. Granted, we're not talking about scientific process being applied here or anything. I'm sure a different set of testers could do a more thorough job of testing something we already know to be fact and post much more thorough results for people to analyze and write an appropriate article to describe what they had done. That's a different article from this one.



> Correction........an incomplete set of facts ....remember, you aren't into the concept of testing the range being discussed


Correction, the facts are complete. The actual source code was provided as well as the Knowledge base documentation. I'm not into the concept of testing values outside of the *documented* accepted range to dispel some anecdotal evidence that appears to be lacking as this discussion progresses.



> I think it's ludicrous to have argued this long when competent testing could have produced a compelling argument for me to review


I also thinks it's ludicrous to have argued this long when tangible evidence has been provided already for you and everyone else to review.



> So...it's about you, not about the user and the performance of his browser?


Nope, it's about you providing a more concrete foundation for your position. I mean if you're basing your entire argument on a single incident, I don't think that is enough to counter the evidence I've provided of how the browser functions. From a different perspective, the information I posted actually can help the general user since it's providing them with more information to consider when they configure their browser.



> I was contemplating that with all the effort you've put into this to prove you are correct.
> Perhaps you noticed, I have mentioned it several times......I'm looking for a compelling reason, mostly out of curiosity now as I've realized changing the values seems to have no effect on my computer, whether that magic 8 as you put it, has all the magic that's claimed because of anecdotal evidence.


The "magic" comes into play through the misinformation being spread. Look at the links I posted above. I cited the relevant comment from the links. "set maxrequests to 32 and 32 connections will be made" The "magic" comes in since 8 will be the max if 32 is coded. I call it the "magic" number since I don't know the reasoning behind choosing that number as an upper limit, over 6 or 10. Sort of like how '42' is the answer to life.



> I now think Mozilla intended for 8 to be the max. It's that anecdotal that I'm curious about and your method of discovery doesn't include discovery.


Excellent!!!!!! Yes, my method of discovery didn't involve any discovery and simply looked at the source.



> Your words, not the presentation of the blogger.
> Really, this is just repetition, tomkadt.
> It's been discussed, nothing's changed.


Certainly nothing has changed and I don't think your understanding of the author's article is accurate or correct. That will never change, I imagine.



> And that's where the anecdotal comes in and the testing limited.
> The next paragraph enforced the contradiction and shallowness of the article.
> Again....this is merely repetitious.


That's not where the anecdotal evidence comes in. Why not? Because, if the anecdotal evidence you are referring to is single case of the server blocking that particular user's Firefox browser from connecting, that case *has yet* to be shown to identify HTTP pipelining as the actual cause of the server issue. It's the fact that people want to use "random" values for the maxrequests setting that is troublesome. Look again at the links I posted above. Most recommended 32 and one recommended 20. NONE stated why to use those numbers, just to use them. _That_ is a problem. Why? Because people are not taking into consideration how any given web server will deal with that kind of traffic. This might be part of the reason why the Firefox developers put a max on maxrequests in the first place.



> Not really. I'm not interested in putting much more effort into this.


Well, I'm somewhat disappointed your lack of interested in providing links. Oh well, c'est la vie.



> Wrong question.
> What's wrong with the Firefox3 code?
> Bet it wasn't coded to do that


You know, I really don't know and I would have to look into the issue to find out more. Actually, this is where reading bug reports is great since you can learn a LOT about what goes on behind the scenes as the developers hash out what the problems really are or are not.



> Performance increase in scrolling?


No, HTTP pipelining.



> The point was inferred to be about settings that were of a negative nature, even mentioning setting beyond 8, but the tests were limited to 8 because Mozilla posted 8 was the max value recognized. M said so, thus it was true and the testing excluded issues that were also of contention.


The point was inferred *by you*, which is the source of our disagreement. I don't know what others thought of the article or how they comprehended it.



> Yep....and testing would finalize the discussion


I honestly don't think so but it would probably make you happy.



> Too much effort
> Anyway, you've already acknowledged that anecdotal comments exist, so I'd only be proving something you are aware of.
> Nice try........in Civ Debate I call it inducing time wasting


Too much effort. Ok. So, I will take the position that your "anecdotal evidence" consists of one incident, which is an incident I initially provided, and is the sole basis of your "anecdotal evidence exists" argument. I think I can accept that.



> I think you have comprehension issue
> It's those anecdotes that make me curious. It's your position on not testing under those circumstances I find quite interesting


Your comments questioning the Mozilla provided information (including your sarcastic remark questioning the Firefox code) are far stronger than mere curiosity. However, maybe if you tell me the kinds of testing you inquired about when you first learned about the HTTP pipelining tweak I will better understand what "curiosity" means to you.



> Lots a luck, because most of what I have are questions.
> I think testing would resolve them, but I'm not going to fret if they aren't answered.


Well, it's good to know you won't fret if your questions aren't answered but I would appreciate that direct question answered.



> And the issue is compounded by setting the value out of spec.
> It appears some people have problems with that. Others don't.
> I'm just curious as to why.........and you aren't


I certainly am curious as to why the results are not consistent but I didn't expect that to be addressed in the article I linked to. I would expect to read another article that focused on finding the optimal setting and why that setting would be considered optimal. I actually DID find an article that went into this and showed graphs illustrating various ways to improve browser performance using HTTP pipelining and other methods. I believe that article also mentioned HTTP pipelining could slow things down a bit depending on how it was used. Now, the invalid maxrequests value setting is an issue of misinformation being disseminated. I do agree the HTTP pipelining issue is compounded by it and I would add this misinformation also confuses the issue to some degree.



> I don't think I proved much beyond showing that published results aren't always representative of the issue.


I agree with this across the board.



> Probably.....but, even though I'm not a programmer, I do hit some sites like Ars where these issues are often discussed and I don't remember any members delving into the issue by testing. So, is accurate testing even a common event in FF tweaking?


Good question. I believe there is some level of testing that goes on in the development arena as the code that implements features like this is checked in. I have no idea of what kinds of testing goes on when documentation is written (in any form) describing how to use said features to boost performance or to do whatever.



> Perhaps the author needs a few courses in composition, because that's not the impression I got.


Perhaps.



> Sad that. The article would have been so much more complete.


I think this is simply one of the things we have to keep in consideration when getting information online, as we do.



> But I might never even have tried out their tests and found their testing was not comparable to all configurations.


At least they did provide their test methodology for review.



> Madonna looks better


Ok, you got me there.



> I don't think that's an absolute.
> I've had this current computer about 2 years and did the tweaks on initial setup.
> But I did get to test a before and after on a Dell P3 800 when I was using 98se and FF 1.5 ( maybe even older)
> There was a noticeable difference. The same tweaks I had up until this thread..... I had then on the Dell.
> I did some of the tweaks in this thread on my current computer. Only a slight improvement......FF2 was already quick and there isn't much room for improvement as I suspect any bottlenecks are hardware or RoadRunner issues.


So much for anecdotal evidence.



> That was an example of excessive connections, not requests.
> But it was tweaking that brought unexpected results.
> This is the concept that interests me concerning pipeline maxrequests.
> Are there tweaks that contradict causing more requests than coded for?


Don't know.



> It's the imagery of a contradiction that brings curiosity, tomdkat.
> Without the anecdotal, there is nothing to be curious about.
> The anecdotal is a contradiction. Testing would prove whether it's a valid event, or just smoke.


I wholeheartedly disagree but that might be the "geek" in me. Leaving the misinformation out for a moment, questions I have regarding this feature are:
Why doesn't Firefox enable it by default when Opera does?
Why cap maxrequests at 8?
Why are there no settings in the Preferences/Options dialog to control this feature?
What are future plans for support of this feature?



> These were your words I was responding to:
> 
> My response: *"Correct. I wasn't aware someone was suggesting that. " *
> None of your links concern Firefox not running.
> I hope you didn't put too much effort into a search.


Ok, I misunderstood your response. My NEW response is, you were suggesting that. As for the search, those links came off the first page of my Google search so I didn't have to "hunt" for anything at all.



> It seems you pick and choose what known circumstances are.
> I presented an anecdotal case of scrolling issues.
> It appears to be a coding issue in Firefox3 as it doesn't appear in FF2 or IE.


I haven't questioned or challenged the scrolling issue other than getting more information on the nature of it. The scrolling issue isn't related to HTTP pipelining (from what little I understand about the issue) so that anecdotal evidence is irrelevant to the HTTP pipelining discussion we're having. The known circumstance is we know what the Firefox code has regarding the maxrequests setting and that is most definitely relevant to this HTTP pipelining discussion. You have yet to provide more than one case of anecdotal evidence relevant to our discussion of the article I posted the link to.



> Whoops....you again forgot about anecdotal evidence.


Whoops, you forgot to provide some anecdotal evidence AND you expressed a lack of interest in doing so above, so I consider that a lost cause.



> From what I read, code is never perfect. There's always a bug waiting to be found.


Yep, that is true. This also doesn't mean EVERY piece of code WILL have an issue that can or will be hit. I have no idea why you are questioning code in this discussion but whatever.



> Do you claim it doesn't exist or need to be investigated just because it doesn't occur on your computer?


I don't claim it doesn't exist BUT I DO believe each case does need to be checked out to make sure said claim is legit. I sometimes read the Opera forums and there are MANY threads about "memory leaks" people claim to find in Opera. If you did a search on "Opera memory leak" and found many references to these threads, you might conclude Opera has some serious memory leak issues (if the search results were large enough). Upon further investigation, you could find out the reported memory leak wasn't a leak at all but something else entirely. Once the erroneous reports have been filtered out, we can then focus on the legit reports and see how widespread the issue actually is. _That_ becomes a solid base of anecdotal evidence which forms a solid base for a problem to be identified and fixed.



> I suggest you reread your link.
> Link
> Comments about throttling performance were linked to the setting and testing was done to show the optimal settings versus the least ....for their specific configuration and internet connection.
> A flaw in the article is that comments were made to running out of spec, but never addressed in testing.


What are you talking about? Comments about throttling performance were made to identify possible causes of the issues they encountered when adjust the maxrequests setting. If the ISP was interfering, that would change the test results since the web server wouldn't necessarily have a "problem" with HTTP pipelining being used:


> We're uncertain whether the throttling of HTTP requests was being done by Google at its web server or perhaps by our ISP (Comcast). Certainly Comcast has been in the news in the past year for placing limits on excessive bandwidth use by its customers (using BitTorrent and similar peer-to-peer networking applications), but does have to maintain its network's reliability to all users and so may be filtering pipelining requests as well. Or Google may be limiting such excessive pipelining requests at the server level.


What is confusing about this?



> Your argument is confused.
> see above.
> It's pretty obvious their results didn't relate to all internet connections.
> Nothing that I posted related to your response.


Most certainly your comment to which I responded related to my comment. My argument isn't confused. I'm saying the article isn't searching for the "optimal" setting, which I've posted above repeatedly. The testing you described when I responded was testing geared toward finding the optimal setting, which is outside the scope of the article. But you know this already.



> You are repeating yourself in this thread.
> I've already addressed that.


I know, I'm just trying to get you to answer some of the questions I've been posing to you directly.



> At the time, that was the suggestion that was posted.
> As explained, these tweaks are generally posted as groups and done en mass.


I fully understand this. That's not what I'm asking. I'm asking did or do you take these tweak posts at face value or do you question them as you've been questioning the accruate information I've been posting? You're wanting to "confirm" the max of 8 is the actual max, but did you seek confirmation a setting of 32 _actually_ resulted in 32 requests being made?



> The issue is..... what is occurring when I do it?
> You have a pat answer, but it does avoid anecdotal comments.
> Essentially, you fall back on 'the code is perfect' as a rationale not to question.
> Us users are quite aware programmers aren't perfect


I don't fall back on "the code is perfect" but you have yet to 
Demonstrate why you want to question the code, which is as clear as it can get (to a programmer at least)
Provide anecdotal evidence (other than the single incident we've been discussing) that contradicts the information in the article we're discussing
You ask me "what is occurring when [you] do it?" and I ask you what was the response when you asked those who recommended that you use the setting of 32 "what is occurring when [you] do it?" Or did you simply not ask?



> Non sequitur.
> I don't have to know code to realize that code ( in general) is not perfect.


That is true, however this doesn't qualify you to question ALL code either.



> Well, you can get up off the floor at your discretion.
> Bugs happen.
> Anecdotal comments happen.
> Sometimes there's a connection.
> You now deny bugs can happen...........interesting.


Nope, this comment will keep me on the floor for a bit longer. Sometimes there is a connection and it would be nice if you made a connection in this thread. Otherwise, I have to conclude your position has no real basis.



> Or test the issue, in this case......whoa!....can't do that, that would be an act of discovery and it's not in your play book..........


It would discover what we (except you) already know. Now, what kind of testing did you inquire about when you first set the maxrequests value to 32? I know I've already asked the question but I'll keep asking until you answer.



> Essentially, you just don't know.
> How do you think you can possibly resolve that problem without some form of testing/experimentation/rewriting of code/or configuration to see what is the cause of his problem?


I guess you haven't paid much attention to my posts here in the web development, web&email and other forums. The problem in this case is misinformation plain and simple.



> Well, here I am as user that has seen people post issues from using a greater value of pipelining requests than spec and I listen to you tell me the code is perfect.


This surprises me since I didn't figure you were listening at all.



> Trust me what I say I'm not impressed. Not with the code, With you estimation of perfection being a rule with out exception.
> IMO....a test would be more compelling that your repetition of...... there are no errors as they are not possible according to Mozilla.


Of course, I'm not repeating any of that at all. Granted, you don't know me on a personal basis so I'm not surprised at all by your comments. Since we're disclosing this kind of information, I'm quite IMPRESSED with your ability to avoid answering most of my direct questions and your ability to make an argument without providing any kind of substance to support it.



> I'll get to it eventually..............amazing, all because you posted a crappy article with whose author may or may not have composition issues


I can't believe this has gone on this long either. If only you could understand the point of the article, I'm sure we wouldn't have gone on this long.

I've had to delete a number of my smilies since we've got too many in the thread.

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> (here is the rest)
> edited for brevity  .





> Where did I state the links I posted were to articles fully addressing the concerns of using HTTP pipelining?


Thanks.
Most debaters don't admit that their position is limited.
That was what I pointed out in the first two links you supplied.



> How many articles did you read that fully addressed the concerns of HTTP pipelining in Firefox before configuring the value of 32?


You asked that before.
Is it a theme 
Pretty obvious....none.
Like most that use these tweaks, I took it on a TSG member's recommendation.
But that question goes beyond the issue of how the tweak performs.



> The articles floating around (regardless of my posting links to them or not) are there to provide information to help people.


Thank you for presenting that concept.
That's exactly why I've commented that the first article was flawed.
It limited the scope of info after initiating comment about the value being changed out of spec with no followup. It assumed.



> Some articles provide information with the intent of improving the performance of the browser. Some articles post incorrect information despite the intent of helping to improve performance. I posted links to some potential "gotchas" that exist with the use of this feature.


Thanks, but.......
The 'gotchas' were lacking in scope.



> ALL of this information should be used to determine if mucking with this setting is worth it for the user.


You are contradicting your position.
I've pointed out the first article was limited.



> How many people will configure this setting, experience a problem, and then slam Firefox as "sucking" because it can't display images on some page right.


Exactly.
A good reason to have run one more test, out of spec, to prove a point so us user's .
Looks like 'they' missed an opportunity.
The article was flawed 



> If this behavior is caused by them configuring HTTP pipelining and incorrectly, they would have shot themselves in the foot and won't realize it until they start a thread on a forum like this one.


Like I keep pointing out, that article could have had more impact with one more test.



> If the info I post gives people more info to digest in the interest of providing a stable web browsing environment, I feel it's worth the effort to post that information.


Do you see me complaining that you brought a warning?
No.
I've merely commented the warning (article) could have been more explicit 



> You started our exchange by pointing out logical fallacies and expressing confusion about the nature of the article.


Yep.....I think the confusion has cleared, though........the article was flawed by being an incomplete assessment of the tweak as presented.



> The code does this. Any professional asked to confirm this will ask to see the code and they will see the code you saw. The code is final.


Updates, anyone?
The code seems to never be perfect.
Not MS, Apple, Mozilla or any of the apps I use.
If otherwise, I wouldn't be updating the apps I own.
Remember, my perspective is from being a user, not a programmer.
I'm not necessarily satisfied by the claim 'the code is perfect' I'm more impressed that it works as planned.
Just a thought..........why didn't Mozilla code so that an integer above 8 couldn't be saved?



> That's not true. You also saw the results which identified issues and problems you didn't experience. Let's keep it real, ok?


Let's keep it honest. The test was limited compared to the context of the discussion.
*All I saw at this link was testing within Mozilla's specified parameters. *
That's all the testing I saw.
That is a correct statement otherwise the test would have included the issue of an out of spec value as brought in to the discussion.
The article was flawed 



> It's interesting that I also have not experienced those problems and even more interesting that others have. Otherwise, there would be no anecdotal evidence for you to reference unless it's all your own evidence. Why didn't the article's author test more than 8 maxrequests? I haven't asked him personally but I imagine it's because of the information in the Knowledge base article I also link to above which you seemed to want to dismiss.


Let's be a bit more honest, please?
I have not denied or dismissed that Mozilla coded for a particular result.
Nor do I think Mozilla coded with the intention to create a scrolling issue.



> If the author wanted to focus on the significant of Firefox capping maxrequests at 8, I'm sure he would have conducted appropriate tests to disprove that.


Maybe you could offer it as a suggestion sine you infer you know him?
I'll bet it would receive a lot of attention.
And from a publishing standpoint, that's a good thing 



> Unfortunately, the author didn't write an article focusing on the significance of Firefox capping maxrequests at 8. Maybe you should send him an e-mail asking him to do so.


That's a consideration.



> It was making the point that use of HTTP pipelining can have a negative impact on Firefox's performance instead of the positive impacts everyone desires.


You are repeating your self.
Since comments in the article also inferred negative impacts above 8, the article certainly appeared lacking in coverage.
Maybe you should suggest to him he rewrite that article for clarity?



> The Mozilla source code provides the MOST compelling fact about the nature of the value 8.


And anecdotal comments bring a 'fog' to the issue.
You seem to accept they exist and deny they can occur at the same time.
To do that, they have to be shown to be baseless.
That hasn't occurred , yet.



> My "claim"? What claim is that?


The purpose for presenting it was not clear.
It's unresolved.



> As for sloppiness, I think the testing done was relevant to the point of the article AND was in line with the Knowledge base documentation on the setting.


I'd agree, except the issue of out of spec vales was commented on in the article and not addressed in the testing.
It looked like the article (text)was an afterthought.



> Is just sloppiness that articles appearing on blog sites that attempt to spread valid information frequently fail to do so?


Yes. It was incomplete.
Never get away with that in a chemistry lab or an auto repair shop.
Specs are specs, but what happens out of spec?
That's how science advances and cars are modified for improved performance.

*"Why bother even commenting to the fact that users are changing values out of spec and then run tests only within the spec? " *
response:
*" Because of the plethora of sites and blogs telling users to use "out of spec" values!" *
You might want to reflect on that. It made no sense 



> You know, I don't think so. Let's assume that article contained the tests you as seeking. If they had actually posted that information, I would have immediately gone to the Mozilla community to seek verification. Only when the Mozilla community confirmed the findings, would I accept or believe them.


As I commented to before......you are operating on faith alone.
As a user, my perception is not one generated by code, but by the results of that code.
The anecdotal comments are part of that view.
To impress me, address those anecdotal comments and make them go away 



> If the article in question WOULD have had the results from the testing you believe is important, would you have simply accepted it?


Unless there were conflicting reports, that would be logical.
My answer......yes, that along with the Mozilla code would give me confidence that the issue was fully addressed.



> The specific anecdotal evidence you cite is weak, at best, in supporting your position.


All anecdotal evidence is weak.
The issue is ...it can cloud decision making and that seems to be the real point of the tweak discussion, making decisions with clarity.



> I mentioned it since it involved HTTP pipelining BUT I never stated pipelining was the sole cause of that person's issue, but you seem to be convinced it is or was.


You've lost me. I posted early on that the link in question only brought confusion.
His issue was too many persistent connections, not too many requests. Tweaking something out of spec may be his problem, from what I gathered.



> The issue I have with your "anecdotal evidence" is you appear to hold it to a certain standard that has yet to be proven.


Then let me clarify.
The 'anecdotal evidence ' exists as an uncertainty.
To test that there is no increase of requests greater than the possible 8, dispels the validity of those anecdotes.
There is no need to search out and test the possible exceptions ( anecdotes), just demonstrate the possible exception has no validity thru testing the code.



> "Just because" someone reported a problem doesn't mean they got the report right or that what they thought the problem was actually turned out to be the problem.


And just because someone claims code is perfect, doesn't mean a bug won't have influence, imo.



> A plethora of anecdotal evidence means there is definitely something going on that needs to be looked at but not much more than that. Then the developers confirm an actual bug or not.


That's an issue of addressing a common problem.
This is an issue of proving a point while that point may not have much impact on users.



> Nor were the tests intended to demonstrate something outside the scope of the article.


Wrong logic. The article was written to accommodate tests within spec.....but brought the concept of out of spec usage into the discussion .
The article was flawed.



> You seem to like having these tests conducted, so what testing results did you review before deciding to enable HTTP pipelining and choosing the value of 32?


You asked that before.
Nothings changed.
A TSG member posted tweaks that were available to use.
I don't remember seeing any testing at any site associated with these tweaks.
What I do is not at issue.
The issue is..... how does what I tweak , actually perform?
Pretty well, thank, you 

But questioning me on why I tweaked does not satisfy my curiosity over the issue at hand.



> I'm sure you'll post links to other incidents like that since there's plenty of anecdotal evidence to support that situation.


No...I have no interest in searching them out posting their existence.
I think we both agree there has been reference to them over time.



> To be honest, I really haven't looked. I consider the issue finalized since we've seen the code.


I should point out, you've seen the code, I couldn't follow the links and understand what I was reading.
I do accept that Mozilla wrote code in a specific manner.
As a user, I'm still curious.



> It sure was appropriate since this thread is about enabling HTTP pipelining in Firefox, not anecdotal evidence.


How so?
The problem at that link hasn't been resolved and goes unknown.



> Hasn't been verified? Do you mean anecdotally?


No...by testing.



> Yep.


LOL!..............Nah!



> Given the plethora of bad information regarding this being disseminated, I have to agree. People are simply "believing the blogs" they read and don't confirm with the Mozilla community.


:up:
Please help us out and support a little more testing just to give us poor users a little confidence 



> Have a great weekend!


You too 

whoops....I see you posted more 

Have to break it off for now, back later


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> But it's most definitely relevant to the discussion. You keep mentioning anecdotal evidence as if you assume it must be correct or accurate by virtue of mere existence.
> 
> (edited for brevity)
> ................................





> But it's most definitely relevant to the discussion. You keep mentioning anecdotal evidence as if you assume it must be correct or accurate by virtue of mere existence.


I suggest you reread my comments on anecdotal evidence.
I assume nothing.
Actually, that's how our conversation has become so lengthy.



> From all the posts I've read on other forums about his very discussion we're having, you are the only person to raise ANY kind of issue with Firefox capping maxrequests at 8 if the user specified a larger value.


Focus (  ).............I'm not raising an issue, I'm inquiring out of curiosity. 



> I'm not seeing your kind of response anywhere else.


You need to hang out in Cic Debate more 
You'll learn to challenge everything you don't understand, till you understand or are satisfied.
You introduced a line of thought I'm following, not the other way round.



> From what you've posted thus far, your "anecdotal evidence" appears to be one incident from a thread I posted. Please provide additional anecdotal evidence to support your position


I have no position......just questions, tomdkat.
Anecdotal evidence is like a fog. Difficult to pin down and leaves questions.
That is what I have commented to.
cashed link for convenience:
Link
Link
Link
Those were from a simple search pipelining+banned
I realize you can argue each away, but that's why they are viewed as anecdotal.

anecdotal----based on personal experience or reported observations unverified by controlled experiments



> The users who have read the Knowledge base article and who have read other forums where the same information have been posted might or might not have already settled this issue in their mind. They might realize they got bad info from whatever source suggested the setting of 20 or 32 or whatever and modified their settings accordingly.


That's not the issue between us.
I made no claim that an integer above 8, worked or didn't work.
Testing was done and I pointed out that it was incomplete .
It seems to offend you that someone is curious about fully testing the issue.
Look back............am I claiming my browser loads quicker at 32?
No.
I'm claiming nothing beyond the tweak helps me at all. Actually, all settings tried seemed the same 



> The "claim"? What "claim"? Your question makes no sense.


see above.



> I see. What kind of testing inquiries did you make on the forum where you found info on this feature? Or did you just accept it at "face value"?


Asked and answered.
Also irrelevant to the discussion.



> I don't understand why think a test would change anything considering the code itself gives all the answers.


You are confused.
My position has been to clarify, not change.
Testing was referenced that did not completely address clarity.



> We're not talking about an unknown here, we're talking about a not understood.


Yes.
And if the group that ran the tests had just put in a relatively small extended effort, the issue would seem clearer to me.
Imagine getting away with that in any published scientific paper.



> The code is telling you nothing is occurring but you're not listening to it.


As I have mentioned, I'm viewing from the perspective of a user, not a programmer.
The code is 'law' to you, results are issue to me.
That's where anecdotal issues become a curiosity.
Especially after that second link you posted that goes unresolved.

*I should note, you are becoming disingenuous in this discussion. *
response:
*That's to be expected. *

Really? If you mean that, you have just projected your self as someone not to be trusted, in front of the forum.
Do you really want to do that?

There is much I do not understand posted on these forums, but I have no intention of fronting intentional misconceptions.
I suggest you clarify your intentions.



> You've also stated you haven't seen any improvement in performance using any of the settings, like was described in the article. I almost got the impression you expected some kind of performance change of any kind simply because of what was contained in the article.


I could not duplicate in any manner what the article/test was projecting.
Your point?



> I would consider having the relevant information in the anecdotal experiences to determine if the claims were even close to being worthy of consideration. "Just because" isn't good enough for me.


This isn't about you.
It's about demonstrating to the user why inappropriate settings are a disadvantage.
Personally, I don't care what you think or whether you are convinced of anything.
As you have noted, the article was focused to enlighten the user. You are a programmer. The article was not to sway your thoughts as a programmer, it was supposed to sway mine as a user.
The article was flawed 



> It most certainly IS an issue of you placing greater value on the anecdotal evidence


Focus.............I MAKE NO CLAIMS, other than the setting has no apparent advantage for me at any value.
Again, you are being disingenuous to prove a point.



> which you haven't provided other than a single instance AND an instance I introduced into the discussion.


Taken care of.
Anyway, you did not initially acknowledge anecdotal evidence as the link you provided and as you have marked yourself as untrustworthy in this discussion, I now have reason to believe you are aware of seeing comments in the past as I have.

Trust me, it's better to be upfront in these discussions......



> Yep, it's the link I provided but unfortunately, I can't control your understanding of the article.


Then you should be wondering how effective your choices are, because bringing a link into a discussion that goes unresolved does not bring clarity......only confusion.
Like the limited testing.
It went only as far as the spec, but the author introduced the issue of using out of spec values.
You only introduced confusion with those two links.
When you claim the code won't run out of spec and provide a link to testing only with in spec, when you provide a link to an unresolved problem............you do not add clarity or validity.
tomdkat...........you've only added confusion and tried to backpedal on the strengths of Mozilla.

And as you've now presented yourself...........you intend to be disingenuous on top of it.
( Looks bad to the forum, I suspect)



> Testing? We've got the actual code to provide the answer!



updates, anyone 



> Ok, on the forum where you initially got the value of 32 to use for maxrequests, did you ask them what kind of testing was performed to determine 32 was a "good" number to use?


Asked and answered.



> If so, could you post a link to that thread so I can see the questions you asked and how they were received?


Provide some testing results to satisfy my curiosity and I'll go look 



> Perhaps but given the nature of the article, I don't think they tested insufficiently.


I't's not what you thing as a programmer that's at issue, it's what I think as a user.
You forgot, the purpose of that article was to enlighten users.......



> Granted, we're not talking about scientific process being applied........


No joke 
You've finally noticed __
It was flawed 



> I'm sure a different set of testers could do a more thorough job of testing something we already know to be fact and post much more thorough results for people to analyze and write an appropriate article to describe what they had done.


That would be of interest and I can say .....satisfy my curiosity.



> That's a different article from this one.


I would hope so, because as it stands, it's flawed as presented by the blogger.



> Correction, the facts are complete.


I think that's been hashed over enough to show that the code hasn't been tested, at least from the link you provided, completely.



> I'm not into the concept of testing values outside of the documented accepted range to dispel some anecdotal evidence that appears to be lacking as this discussion progresses.


If you are indeed, posting for the purpose of enlightening the user, it matter not what your personal opinion is.........what matters is providing the user with knowledge to clarify, in his/her mind.......the issues...or any issue........that is in the user's domain.
tondkat...........you have been arguing in circles.
It's even called circular reasoning.........( ! )
You say it's so, because it's written...........ever hear that argument before?
I've seen you in Civ Debate. Enter into a discussion about the Bible and the inerrant word of God .....and get back to me _



> I also thinks it's ludicrous to have argued this long when tangible evidence has been provided already for you and everyone else to review.


Circular reasoning is all you provided 



> Nope, it's about you providing a more concrete foundation for your position.


I suggest you reread our exchange.
Or is this just another part of 'time wasting'?
My position---------> curiosity
All you have argued is circular reasoning. It may indeed be correct. Most likely, probably.
I'd even bet money it's being correct.
But you've proven nothing in regard to proving 'correctness' with incomplete testing and unknown problems.
As long as there is anecdotal evidence, as long as testing is limited.......as I am user that's supposed to be the target of enlightenment...........you are failing at making a point with circular reasoning.
It's illogical as a proof.
It's compelling to use as a guideline, but not to satisfy curiosity......and I have established long ago that is why I am responding in this fashion.
I've claimed nothing in regard to the validity of the code beyond pointing out that you haven't provided enough to satisfy curiosity.

Look back, seriously.

It's all circular reasoning.

Let's look at what you continue to post:



> > The "magic" comes into play through the misinformation being spread. Look at the links I posted above. I cited the relevant comment from the links. "set maxrequests to 32 and 32 connections will be made" The "magic" comes in since 8 will be the max if 32 is coded. I call it the "magic" number since I don't know the reasoning behind choosing that number as an upper limit, over 6 or 10. Sort of like how '42' is the answer to life.


What has this to do with satisfying MY curiosity?
Any testing results?



> Excellent!!!!!! Yes, my method of discovery didn't involve any discovery and simply looked at the source.


You mistook the comment.
I asked for linkage to the claim Mozilla coded for a max of 8 and it was eventually provided.
That was not discovery as in proving a point.
It was merely establishing circular reasoning in the face of anecdotal comments.



> Certainly nothing has changed and I don't think your understanding of the author's article is accurate or correct. That will never change, I imagine.


The issue is the article stopped short by referencing issues and presnting testing with out follow up on those issues.
It was flawed and nothing you've posted has changed that, tomdkat 



> That's not where the anecdotal evidence comes in. Why not? Because, if the anecdotal evidence you are referring to is single case of the server blocking that particular user's Firefox browser from connecting, that case has yet to be shown to identify HTTP pipelining as the actual cause of the server issue.


Just pointing out that there is absolutely no validity to any of that statement.
Your link is not the one I've been using as an example of an anecdote.
I have pointed out that the issue there is one of connections, not requests.
Are you confused ? or merely being disingenuous again?



> It's the fact that people want to use "random" values for the maxrequests setting that is troublesome. Look again at the links I posted above. Most recommended 32 and one recommended 20. NONE stated why to use those numbers, just to use them. *  That is a problem*. Why? Because people are not taking into consideration how any given web server will deal with that kind of traffic.


Note the bold. Notice.......you are introducing confusion.
Your position is Firefox has a limited max value of 8 for pipelining maxrequests and you blather on about concerns of *NONE stated why to use those numbers, just to use them.   That is a problem. Why? *
But you then go on to negate the problem.
See how you've just clouded the issue.

Your presence does not seem to be to enlighten the user, it to vindicate your position.
Fine. I'm curious------------>how about presenting some testing to clarify the mess you just wrote?



> This might be part of the reason why the Firefox developers put a max on maxrequests in the first place.


Indeed..........I agree that's why they coded that way.
But look at the structure of the whole comment.
And has that code been tested?
I don't know. Nothing you've provided has been responsive to that question.
What do I relate to that causes my curiosity to arouse?
Well, the fact that as a user, I don't always see the code act as intended.
Like the scrolling issues I've had. Mozilla certainly did not intend for that to happen.
It did, though.
And I have to do periodic updates because the code has bugs ( flaws) that need to be corrected.
So...........I see your circular reasoning as merely avoidance.

BTW.......I've reverted back to FF2. The scrolling issue turned out to have had enough influence on 'regular' pages as to cause a very slight wavering in the page as I scrolled and I wound up with a nasty headache yesterday from it. I'm on line a lot.
I'm feeling much better now 



> Well, I'm somewhat disappointed your lack of interested in providing links. Oh well, c'est la vie.


I put a couple up.
They prove/provide nothing beyond being anecdotal.......a waste of my time as I suspect you've read of them before ( it's the disingenuous trait you own that I speak to )



> The point was inferred by you, which is the source of our disagreement. I don't know what others thought of the article or how they comprehended it.


The point was made by me......of the article being flawed by it's shortcomings in presenting a test that didn't cover the the entirety of the article.
I really don't know what the forum thinks.
You really think anyone is following out dialog?
I'm doubtful.
Consider..........all that's been presented as proof is circular reasoning and most of what has been posted is sniping between the two of us.



> I honestly don't think so but it would probably make you happy.


Happy? 
Happiness is a whole 'nother ball park
But it would satisfy my curiosity and force you to break out of the illogic of circular reasoning

continued


----------



## Stoner (Oct 26, 2002)

continued



> Too much effort. Ok. So, I will take the position that your "anecdotal evidence" consists of one incident,


I suggest you don't.
You'll look foolish to those that may have seen as much as I did on a quick search or remembered comments from the past.
It's better not to assume.



> which is an incident I initially provided,


No....as explained more than once.
I saw right off that the link in question only confused issues.
I remember you admitting to anecdotal evidence. Perhaps you were referencing that link. As your exchange has become less than honest of late, I suspect you are well aware of other anecdotal comments and are merely attempting a debating tactic.
And as pointed out, your logic can become quite 'fuzzy' at times 



> I think I can accept that.


Looks like you've made another mistake, imo.



> Your comments questioning the Mozilla provided information (including your sarcastic remark questioning the Firefox code) are far stronger than mere curiosity.


Really?
If the code is so perfect, and this applies to all programs, why are there flaws in the code that need to be addressed?
What I see occurring is that you are taking my comments about a computer program, personally and transferring it into a personality conflict.
Works for me........but you still offer up nothing more than an example of proof that defines it is the only 'truth' by the nature of it existing and claiming it is the only 'truth'.
Maybe it is, indeed, perfect code. But you argue not to test it.
As a user, tomdkat, that looks weak as an argument.
You don't explain, you only repeat.



> However, maybe if you tell me the kinds of testing you inquired about when you first learned about the HTTP pipelining tweak I will better understand what "curiosity" means to you.


A dictionary definition is sufficient.
As a user, curiosity was trying the tweak to see if it worked.
As a user, curiosity is asking to see testing as anecdotal evidence exists.
Like I said, the dictionary definition works for me.
The problem is....you take that as a personal challenge of a programmer's abilities.
As good as you are, yo are human and as a human......you are not perfect and can not always write perfect code. My proof........every 'bug', 'glitch' every update.........all factor in coding that needs correction.
You seem to claim you are perfect.
Now that would be a claim to frame on the wall 



> Well, it's good to know you won't fret if your questions aren't answered but I would appreciate that direct question answered.


I remember the comment, but a search doesn't turn up what the question was.
Repeat it I you thought it important to the issue at hand ( not the personal conflict)



> I actually DID find an article that went into this and showed graphs illustrating various ways to improve browser performance using HTTP pipelining and other methods. I believe that article also mentioned HTTP pipelining could slow things down a bit depending on how it was used.


You really should post links like that.
Testing impresses the user more than you seem to accept, at least it does with me.



> Now, the invalid maxrequests value setting is an issue of misinformation being disseminated.


Shame that, but if the articles are focused only on the range of values Mozilla coded for and acknowledged as the only purpose for testing, I find that appropriate.
Not all all like the blogger article you keep referring to.



> I think this is simply one of the things we have to keep in consideration when getting information online, as we do.


Just a comment: From being in a debate forum at TSG, the experiences of accepting information from blog sites, in general, has been dicey to say the least.
Politically, it's not worth the effort as it's become so biased that most political blog sites seem arms of political action groups.
As far as computer info, some does seem shaky. I've seen reference to blogers of note with reputations that seem well established in the trade.

But when I google Tom Kephart, I find he's presenting an article for his blog with tests from a site he is an editor of, all with out acknowledging he may have had involvement.
Sure, some may follow the links and discover that, but as it sits, he's using tests from his New Tech Heroes site to validate the article he wrote in his blog with out disclosure.
He even writes as if his authoritative source makes a recommendation when in fact he is the editor of that authoritative source.
I'm not trying to disparage this person to discredit what he posted, but to a person like me that has had experience with authoritative bloggers, it runs up a red flag.

And if you look closely at the style of NTH.........it looks like a blog site, too.



> At least they did provide their test methodology for review.


I'm wondering just how valuable the results were after realizing the association of the blog site to the site the blogger was using as an authoritative source, with out full disclosure.



> So much for anecdotal evidence.


Yep.
All I can provide is what I experienced........not why.
I don't see why you deride me for being honest about this?



> I wholeheartedly disagree but that might be the "geek" in me. Leaving the misinformation out for a moment, questions I have regarding this feature are:
> 
> * Why doesn't Firefox enable it by default when Opera does?
> * Why cap maxrequests at 8?
> ...


These are all questions beyond the initial query.
You forget, my quest is for an answer out of curiosity and you are asking questions in response that lead away.
I'll leave them for others to answer. I have none, just curiosity as a user.



> My NEW response is, you were suggesting that.


And that leads back to your comprehension issues that I've remarked upon in the past 
Or was it of you embracing a disingenuous position? (  )
Curiosity again, shame on me--------> 



> As for the search, those links came off the first page of my Google search so I didn't have to "hunt" for anything at all.



Maybe you should?
Especially that blogger site that quotes his own different blog site as an autoratative source __ 
( bloggers-------:up: ------>  )



> I haven't questioned or challenged the scrolling issue other than getting more information on the nature of it. The scrolling issue isn't related to HTTP pipelining (from what little I understand about the issue) so that anecdotal evidence is irrelevant to the HTTP pipelining discussion we're having.


Logic again. If you claim code is perfect, you have to claim perfection.
I've given you anecdotal evidence that the code involving scrolling in FF3 has a flaw.
It's undisputable because of the large number of comments.
I have no curiosity in this issue. It's flawed.
But, as pointed out in the past, even though I no longer use a value above 8, I am still curious for reasons already expressed.
Circular reasoning as an argument is illogical, even if the code is indeed, perfect as Mozilla wrote it.



> You have yet to provide more than one case of anecdotal evidence relevant to our discussion of the article I posted the link to.


You now have several examples.
What do they prove? Nothing, other than they exist.



> Whoops, you forgot to provide some anecdotal evidence AND you expressed a lack of interest in doing so above, so I consider that a lost cause.


Clever debate tactic. I use it myself when someone can't........however, it's now posted.
And I suspect you've been aware of the existence of like comments.



> Yep, that is true. This also doesn't mean EVERY piece of code WILL have an issue that can or will be hit. I have no idea why you are questioning code in this discussion but whatever.


Kind'a hit an miss, eh? You write the code, you just don't test it LOL!.......I think I've bought cars in the past like that 
In other words, a circular argument is all you intend to offer up.



> I don't claim it doesn't exist BUT I DO believe each case does need to be checked out to make sure said claim is legit.


Not practical.
You might try posting at various forum to ask for personal incidents, get with the owners, list their hardware, ISPs, anything that may be of interest for a comprehensive test, assuming a banned user is still using the same setup ......but let's face it, expanding testing to include just one out of spec integer has more impact on a user with less effort.
Fine if you've got the time.
But if you prove each and every incident is false, all I'd see you as is a fool becaues of the effort spent.
Like I keep telling you, I'm not here to prove the validity of the anecdotes.......I'm just posting to clarifying the issue with other than circular reasoning.
I think you are making too big a deal about your 2 links being shown up as falling short of satisfying my curiosity.



> I sometimes read the Opera forums


Different issue.
Why confuse things as they are?



> What are you talking about? Comments about throttling performance were made to identify possible causes of the issues they encountered when adjust the maxrequests setting.


Other comments were added and not addressed in testing.
The article was flawed  ( a blogger using himself as an authoritative source  ---------> no wonder  )



> What is confusing about this?


Seriously, You didn't think * "We're uncertain "* was a tip off? 

Bloggers 



> Most certainly your comment to which I responded related to my comment. My argument isn't confused.


And circular 



> I know, I'm just trying to get you to answer some of the questions I've been posing to you directly.


I'll change my replies as I'm convinced.
I've seen no reason to present falsehoods.
I can be wrong.
I'd like to see you attempt a discussion with out circular reasoning......well....and without bloggers quoting themselves 
( That was pretty funny  )

continued


----------



## Stoner (Oct 26, 2002)

continued



> I fully understand this. That's not what I'm asking. I'm asking did or do you take these tweak posts at face value or do you question them as you've been questioning the accruate information I've been posting?


Asked and answered.
Yes, I did.
But you have not been presenting other than a circular argument.
I repeat......it's not about what I do, it's about what the tweaks actually do. Members test them out and post comments on their experiences.
Just like this thread.
If the tweak doesn't work, reset it.
I've even made comment to using tweakers that make tweaka blind to the user.
I see you use them.
My experience was negative and I posted to that effect so that other members might give it a second thought.
But I'm not here to tell you not to use one or even question why you do after posting my experiences.



> You're wanting to "confirm" the max of 8 is the actual max, but did you seek confirmation a setting of 32 actually resulted in 32 requests being made?


Asked and answered.
Many times.......nothing has changed in that regard.



> I don't fall back on "the code is perfect" but you have yet to
> 
> 1. Demonstrate why you want to question the code, which is as clear as it can get (to a programmer at least)
> 2. Provide anecdotal evidence (other than the single incident we've been discussing) that contradicts the information in the article we're discussing


You don't have to, but that's your argument.
As to 1......curiosity. Even more so since it's an issue with you 
2. Already done, but I suspect from you admitting to being disingenuous, you are already aware of similar comments. I can remember several times in the past, seeing someone comment to being banned for too great a value along with comments to the lists of tweaks presented.



> You ask me "what is occurring when [you] do it?"


Sorry for the context, not you, tomdkat, 'you' as in the context of a source to provide more clarity than you provide with circular reasoning.



> That is true, however this doesn't qualify you to question ALL code either.


A user doesn't see code as a line of script, tomdkat. I realize it is.
I see the results of code performing tasks.
This is something you seem incapable of understanding in your argument to not test.



> Sometimes there is a connection and it would be nice if you made a connection in this thread. Otherwise, I have to conclude your position has no real basis.


My curiosity?
Hmmm? I don't know how to prove that other than from past remarks of my inquisitiveness about testing.
Do you think I have an ulterior motive?
What could that possibly be?

I don't hate Firefox. I do prefer FF2 for good reasons. I've always posted FF was my preference as a browser. I like the security extensions. I was drawn to tabbed browsing as an advantage for me, right off the bat.
Perhaps you think this is personal?
Do I follow you around TSG and stalk you?
No, I don't. I think I've seen you in Civ Debate, but I don't remember any dialog with you.
Have I offended you?
Personally? to the point you would admit to this forum, to me, that you were being disingenuous?
Have I slighted you unfairly?

OK....let's get it out in the open.........what do you think my motive is for being here?



> It would discover what we (except you) already know.


It most likely would as there aren't many anecdotal comments out there on the issue, but do you realize, your whole argument is circular?
Focus..........I've posted nothing that is proof the code in question is, indeed, flawed.
Everything I've presented is from curiosity as a user.
What you claim may indeed be true, but your proof is circular reasoning.
That BTW, is a fallacy of logic.
http://ksuweb.kennesaw.edu/~shagin/logfal-pbc-circular.htm
*" Circular Reasoning  supporting a premise with the premise rather than a conclusion. " *
As I keep commenting.....testing would bring a conclusion whereas restating the code is perfect does not.

All this from being curious.........wow!
That's not quite correct. My curiosity was notched up from you using a blogger as an authoritative source that I find out quotes himself.
As much as you've asked me why I do things in regard to my computer,
Why didn't you check the blogger out closer when basing an argument on his reasoning?
And why link to any example of any unresolved problem as if it's pertinent to this discussion?

Curious
(whoops!.............. )



> Now, what kind of testing did you inquire about when you first set the maxrequests value to 32? I know I've already asked the question but I'll keep asking until you answer.


Asked and answered. And the above blogger you quoted?



> I guess you haven't paid much attention to my posts here in the web development, web&email and other forums


Are you using your participation as an argument of some sort?
Or my lack of participation in those forums?
And how does that apply to your circular argument?



> The problem in this case is misinformation plain and simple.


The problem is..............you avoid my curiosity.
And the fact that your circular argument doesn't bring the clarity that a slightly greater testing range would have accomplished, upsets you greatly.
To the point you even posted to using disingenuous tactics. For shame 

All because I'm curious? I'm doubtful of that, now.
Some thing else may be bugging you.
Desperation to prove a point?
Review--------> You use a blogger that quotes himself as an authoritative source, and link to a problem that goes unresolved.

I hope you don't think I'm desperate to fulfill my curiosity 
I just have too much free time right now 



> This surprises me since I didn't figure you were listening at all.


Oh....I've heard you. 
That may actually be the issue 
It's the same old argument....the code is perfect because Mozilla says so.......well....the blogger that quotes himself, too 



> Of course, I'm not repeating any of that at all.


That is all of your argument. You posted nothing else to the issue.
The code is perfect so it doesn't need to be tested.
Circular.



> Since we're disclosing this kind of information, I'm quite IMPRESSED with your ability to avoid answering most of my direct questions and your ability to make an argument without providing any kind of substance to support it.


What was to avoid?
All you present was a circular argument to the issue at hand.
The issue of whether the code runs out of spec has no relationship to why I chose to do a tweak.
All you presented was a diversionary tactic.
Repeatedly.

I've think I've seen you in Civ Debate. You'd never pull this off up there.
I've been there long enough to realize when an argument was weak, no matter how sound the concept was in actuality.
Your argument is not impressive, even though the code may indeed be perfect.

Summing it up:
You've presented the Mozilla code.
Thank you for clarifying that. I was not aware of the imposed limitation.
Your argument was circular. You need to consider that the next time something like this comes up.
Don't trust bloggers, blindly 

My curiosity still exists and it makes not one bit of difference to the internet or how it functions.
I'm happy even when curious 

I just hope your real name isn't Tom Kephart 



(BTW this post is so long, it's split and not proof read .....too much effort )


----------



## JohnWill (Oct 19, 2002)

You guys should write a book, the posts are getting so long and detailed that I doubt many people are taking the time to read them anymore.


----------



## Stoner (Oct 26, 2002)

JohnWill said:


> You guys should write a book, the posts are getting so long and detailed that I doubt many people are taking the time to read them anymore.




Titled: I am Curious Jack ---------->


----------



## guitar (Jan 15, 2006)

JohnWill said:


> You guys should write a book, the posts are getting so long and detailed that I doubt many people are taking the time to read them anymore.


excactly john
i tried this speed up didn't notice much difference [i'm on dialup]
turned off the security phishing tools that helped a bit
tried ashampoo internet accelerator 2 its free installed it, run it with automatic settings, restarted, uninstalled it, connected to the internet and its now quite a lot faster loading firefox and browsing


----------



## tomdkat (May 6, 2006)

Sorry for the delay but I had a busy weekend and was busy the last couple of days. Fortunately, I had a _great_ weekend and I hope you did as well. 

One thing I want to state up front: given the limit of 20 smilies per post, I will start removing some of yoursif the limit gets exhausted in my reply. I will limit my use of them as well. I'm NOT trying to change the tone of your comments in my responses to them by removing the smilies.



Stoner said:


> Thanks.
> Most debaters don't admit that their position is limited.
> That was what I pointed out in the first two links you supplied.


I didn't admit my _position_ was limited, I stated the article didn't have the scope you seem to want it to have. That's completely different, at least in my view.



> You asked that before.
> Is it a theme
> Pretty obvious....none.
> Like most that use these tweaks, I took it on a TSG member's recommendation.


Well, yeah I guess you could consider it a "theme" of sorts. Mostly, it's related to getting a direct answer from you when asked a direct question.



> Thank you for presenting that concept.
> That's exactly why I've commented that the first article was flawed.
> It limited the scope of info after initiating comment about the value being changed out of spec with no followup. It assumed.


You're welcome. The article isn't flawed for this reason. The article doesn't appear to be intended to demonstrate why the incorrect advice being presented is incorrect. It appears to be intended to demonstrate a possible negative impact use of the HTTP pipelining feature could have by being used. Of course, I've already stated this previously. I use the word "appears" because I haven't contacted the article's author to ask what the actual intention of the article is.



> Thanks, but.......
> The 'gotchas' were lacking in scope.


The 'gotchas' are lacking in scope? This doesn't make any sense. The 'gotcha' is use of HTTP pipelining screwing up the rendering of some webpage.



> You are contradicting your position.
> I've pointed out the first article was limited.


Not at all. My position has always been that people need to understand the configuration changes they make before making them. There is plenty of recommendations out there suggesting people use invalid values that people seem to use without question or understanding what it is they are actually doing. People should process the tweak given, what the tweak is actually tweaking, determine if said tweak will adversely affect them, and apply the tweak accordingly.



> Exactly.
> A good reason to have run one more test, out of spec, to prove a point so us user's .
> Looks like 'they' missed an opportunity.


I don't think so because the article would have delve more into what HTTP pipelining it is and how web servers and browsers interact when it's being used, which also wasn't the apparent intent of the article. The HTTP pipelining issue is far larger than enabling it in Firefox. The article addressed one facet and that's reasonable.



> Like I keep pointing out, that article could have had more impact with one more test.


I get the idea you think the single article in question is the only article that can ever exist on this issue. A different article focused on disproving the incorrect recommendations being posted all over the place probably needs to be written, if it doesn't exist already. The article I linked to doesn't appear to intend to be the article I just described.



> Updates, anyone?
> The code seems to never be perfect.
> Not MS, Apple, Mozilla or any of the apps I use.
> If otherwise, I wouldn't be updating the apps I own.
> ...


You misunderstood my point and I admit I didn't make it clearly enough. Clearly, "final" doesn't mean "static" as in "will never EVER be changed" in my comment but meant the "last word" or authoritative. As for _why_ they allow an invalid value to be entered in the first place, I have no idea and that's one of the questions I have. Another question is where did people get the number '32', in the first place? If values larger than 8 were simply not allowed to be set, the "clamp" code wouldn't be needed. If a standard user preference setting for this appears in a future Firefox release, that "clamp" code might be removed since it wouldn't be needed depending on how this user preference worked. By "standard user preference", I mean a setting in the user preferenece/options window.

[quopte]Let's keep it honest. The test was limited compared to the context of the discussion.
*All I saw at this link was testing within Mozilla's specified parameters. *
That's all the testing I saw.
That is a correct statement otherwise the test would have included the issue of an out of spec value as brought in to the discussion.
The article was flawed [/quote]So, I guess you don't consider the posted results, which indicated some misbehavior they experienced, as anything you saw? Ok.



> Let's be a bit more honest, please?
> I have not denied or dismissed that Mozilla coded for a particular result.


Ah, now I see you're qualifiying your remark. I believe you certainly have dismissed the information from Mozilla I posted through various comments you make throughout your argument.



> Maybe you could offer it as a suggestion sine you infer you know him?
> I'll bet it would receive a lot of attention.
> And from a publishing standpoint, that's a good thing


No inference of knowledge, just giving the benefit of the doubt. If I ever do meet the author, I will be sure to ask why he didn't write an article to address the issue of the incorrect information being distributed about the Firefox tweak.



> You are repeating your self.
> Since comments in the article also inferred negative impacts above 8, the article certainly appeared lacking in coverage.
> Maybe you should suggest to him he rewrite that article for clarity?


Of course I'm repeating myself, you're not getting it. LOL Why should I suggest he rewrite the article for clarity when you're the one having problems getting the point of it?



> And anecdotal comments bring a 'fog' to the issue.
> You seem to accept they exist and deny they can occur at the same time.
> To do that, they have to be shown to be baseless.
> That hasn't occurred , yet.


I do accept they exist and I accept they don't _necessarily_ mean anything by virue of existing. If you feel they have to be shown to be baseless, that implies you believe they are accurate or based on some kind of fact or something tangible. Basically, taking the info at "face value". Is this correct? I feel inspection of the code, in this case, is the most indisputable proof that exists but you feel otherwise.



> The purpose for presenting it was not clear.
> It's unresolved.


I haven't made any "claims" other than deeming the Mozilla source code is a trustworthy source of evidence.



> I'd agree, except the issue of out of spec vales was commented on in the article and not addressed in the testing.
> It looked like the article (text)was an afterthought.


I disagree since the comment about the invalid value is relevant because that's the nature of the invalid information being posted online. Whether the rest of the article was an afterthought, I don't know. Maybe he tried using various Mozilla documented values and ran into problems or maybe he set out to investigate how effective HTTP pipelining in Firefox actually is based on the plethora of online resources recommending using it.



> Yes. It was incomplete.
> Never get away with that in a chemistry lab or an auto repair shop.
> Specs are specs, but what happens out of spec?


Chemistry lab? I would probably agree with this if we were discussing a Mozilla article on the invalid value being recommended. The thing is, the articles online that recommend the value '32' don't even mention any of the 'specs' or even discuss how the value '32' was generated and you seem to be ok with that.



> *"Why bother even commenting to the fact that users are changing values out of spec and then run tests only within the spec? " *
> response:
> *" Because of the plethora of sites and blogs telling users to use "out of spec" values!" *
> You might want to reflect on that. It made no sense


Probably not to you. In this article, the author references setting the value to 30 to make a different, but related, point. I don't think I've run into a site or page that recommends enabling HTTP pipelining in Firefox and didn't state which values to use or give the process of doing so. They might exist but I haven't seen any and if they do exist, they are definitely in the minority. So, if the majority of sites recommending enabling the HTTP pipelining feature do so and then give invalid information to do it, it makes sense to mention the kind of information people might or probably have read in a discussion on side effects of enabling the feature at all.



> As I commented to before......you are operating on faith alone.
> As a user, my perception is not one generated by code, but by the results of that code.
> The anecdotal comments are part of that view.
> To impress me, address those anecdotal comments and make them go away


We *both* are, then. If you configured your Firefox browser to enable this feature based on an online resource, you took the information in that source "on faith". In my case, the faith I'm placing is in the Mozilla developers whom I consider to be competent and capable. I don't consider it my "job" or "duty" to make the anedoctal evidence go away. It will always be there by virtue of people thinking they are experiencing something they aren't in reality. I can only do so much to encourage people to take the time to learn more about this kind of stuff so they can use their browsers more efficiently and effectively.



> Then let me clarify.
> The 'anecdotal evidence ' exists as an uncertainty.
> To test that there is no increase of requests greater than the possible 8, dispels the validity of those anecdotes.
> There is no need to search out and test the possible exceptions ( anecdotes), just demonstrate the possible exception has no validity thru testing the code.


The problem with this is, people don't take into consideration the uncertainty of the anecdotal evidence and just "run with it". I believe the Mozilla QA team would have conducted the testing you mention in response to that coding having been checked in. I don't know if the QA test suite is publicly available.



> And just because someone claims code is perfect, doesn't mean a bug won't have influence, imo.


Fair enough.



> That's an issue of addressing a common problem.
> This is an issue of proving a point while that point may not have much impact on users.


I don't consider this an issue of proving a point but certainly do consider it an issue of identifying and clarifying invalid information. The specifics of proving whether Firefox actually supports more than 8 requests is simply part of the larger issue, which is the issue I'm more interested in and concerned about.



> Wrong logic. The article was written to accommodate tests within spec.....but brought the concept of out of spec usage into the discussion .


Only because the majority of information posted on enabling the feture involved the invalid value.



> No...I have no interest in searching them out posting their existence.
> I think we both agree there has been reference to them over time.


I'll concede this on the issue of people enabling HTTP pipelining and claiming to see significant performance improvements.



> I should point out, you've seen the code, I couldn't follow the links and understand what I was reading.
> I do accept that Mozilla wrote code in a specific manner.
> As a user, I'm still curious.


Are you saying the links didn't work for you (clicking them didn't take you to the appropriate site) or the links did work but you couldn't understand what was on the pages?



> How so?
> The problem at that link hasn't been resolved and goes unknown.


To demonstrate how HTTP pipelinining is associated with that kind of misbehavior people can experience in their browser. Of ALL the features Firefox supports, both hidden and exposed, HTTP pipelining was mentioned as an option to investigate which demonstrates how HTTP pipelining can be associated with that kind of strange behavior.



> LOL!..............Nah!


Yeah....



> Have to break it off for now, back later


Man, after taking a break from this thread for a few days, I almost cringe when looking at it now. 

I didn't respond to each of your comments above but focused on the ones I felt I should respond to.

I've gotta jet now and will be back later.

Peace...


----------



## tomdkat (May 6, 2006)

JohnWill said:


> You guys should write a book, the posts are getting so long and detailed that I doubt many people are taking the time to read them anymore.





Stoner said:


> Titled: I am Curious Jack ---------->


Sounds like a plan to me! :up:

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> Sorry for the delay ..........
> 
> edited for brevity)
> 
> ........





> I didn't respond to each of your comments above but focused on the ones I felt I should respond to.


I shall do the same



> One thing I want to state up front: given the limit of 20 smilies per post, I will start removing some of yoursif the limit gets exhausted in my reply. I will limit my use of them as well. I'm NOT trying to change the tone of your comments in my responses to them by removing the smilies.


No problem. I've done the same.



> I didn't admit my position was limited, I stated the article didn't have the scope you seem to want it to have. That's completely different, at least in my view.


Of course your position is limited, or you wouldn't be arguing against the testing I mention.
Code is law to you.



> Mostly, it's related to getting a direct answer from you when asked a direct question.


What isn't direct when I say I inquire out of curiosity because of a poorly written article?



> The article isn't flawed for this reason. The article doesn't appear to be intended to demonstrate why the incorrect advice being presented is incorrect.




The article is flawed because it's incomplete.
Nothing has changed in that argument.
It becomes even more suspect to expertise , when considering how it was represented.
A blogger using his own testing as if was an outside authoritative source 



> My position has always been that people need to understand the configuration changes they make before making them.


Then look back at the example you gave, because it did not fully address, with testing, comments made in that article.
The article was flawed.



> Mostly, it's related to getting a direct answer from you when asked a direct question.


I don't owe you any answers.
Nada......zip......all your questions are positioned to question why I do something......and I've addressed them anyway.



> I don't think so because ...........


It's not about what you think, It's about the impression that's left, especially after learning it was a blogger quoting his own work from another site :rolleyes essentially quoting himself as an outside authority 



> I get the idea you think the single article in question is the only article that can ever exist on this issue.


I suggested there might be a better source, but you seem to argue there isn't.
As I've mentioned, the article was flawed and I do think you could have and should have picked a better example, at least exhibiting a bit more professionalism.



> * The article I linked to doesn't appear to intend to be the article I just described.*


It's the one you posted....
It's the one I read.....
*LOL! * 



> That's all the testing I saw.
> That is a correct statement otherwise the test would have included the issue of an out of spec value as brought in to the discussion.


Hey....that's my point 
The article was flawed for being incomplete as the article brought the issue into context to start with.
It's all your fault for picking a poorly written article 
It's flawed 



> So, I guess you don't consider the posted results, which indicated some misbehavior they experienced, as anything you saw?


You appear confused.
That's merely a secondary issue I commented to and I believe they addressed it when they posted something of the nature of uncertainty in their results.



> Ah, now I see you're qualifiying your remark. I believe you certainly have dismissed the information from Mozilla I posted through various comments you make throughout your argument.


Nope.
And I challenge you to quote me.

Your shoddy article that you now claim was the wrong link ( rolleyes: ) was what triggered my response.



> Of course I'm repeating myself,



Over and over and over.
Your aim seems to be one of disqualifying my curiosity with circular reasoning.



> I do accept they exist and I accept they don't necessarily mean anything by virue of existing


So, were you lying to me when you said you were unaware of them, before I posted several?
Or just confused?
Or forgetful, even?
Like I posted earlier....it's better to be upfront in these discussion.



> I haven't made any "claims" other than deeming the Mozilla source code is a trustworthy source of evidence.


You have, indeed. You have claimed a value above 8 will not result in more than 8 requests.
Again, you are not being honest in this conversation.

Seems a pattern there. 



> I disagree since the comment about the invalid value is relevant because that's the nature of the invalid information being posted online.


All I see in that statement is more confusion.



> Whether the rest of the article was an afterthought, I don't know.


Do you expect me to know?
I didn't post that link, you did.
I suggest you defend it as it's the basis of your initial argument .
The article was flawed. Pick your choice if you want.
Incomplete or an afterthought.
(Perhaps both  )
Either way, it was flawed 



> I would probably agree with this if we were discussing a Mozilla article on the invalid value being recommended. The thing is, the articles online that recommend the value '32' don't even mention any of the 'specs' or even discuss how the value '32' was generated and you seem to be ok with that.


Irrelevant to the discussion.
The article was flawed as I've shown.



> We both are, then.


DO you understand the concept of 'faith?
It's an unquestioning belief something is true.
This is one trait you have built upon with circular reasoning.
I, on the other hand, have brought questions from reading a shoddy article that was..............Flawed (  ) by a blogger that quotes himself as an authority in the article he wrote ..........MEH! 



> I don't consider it my "job" or "duty" to make the anedoctal evidence go away.


If you set out to prove a point....it is and the article you posted referred to a situation for which anecdotal evidence exists.
The article was flawed 



> The problem with this is.......


Your argument is circular and you are desperately trying to divert the focus to why I chose to do the tweak.



> I don't consider this an issue of proving a point but certainly do consider it an issue of identifying and clarifying invalid information.


And I've pointed out repeatedly, just one more test would have more impact that the circular argument you entertain.
The article was flawed 



> Only because the majority of information posted on enabling the feture involved the invalid value.


Indeed. A very good reason for the testers to have demonstrated a fallacy.
The article was flawed 



> I'll concede this on the issue of people enabling HTTP pipelining and claiming to see significant performance improvements.


Just concede the article was flawed and I'll let you go home 



> Are you saying the links didn't work for you (clicking them didn't take you to the appropriate site) or the links did work but you couldn't understand what was on the pages?


No.


> I couldn't follow the links and understand what I was reading.


I mean exactly what I posted.
I got to this link Link, line 310 referred me to this page Link

At that point I stopped as there were links to pick with out being intuitive to me.
So I accepted the claim from the statement on the first link *" nsHttpHandler.cpp source file where the value is clamped to 8" *

But my inability to read the code is irrelevant.



> To demonstrate how HTTP pipelinining is associated with that kind of misbehavior people can experience in their browser. Of ALL the features Firefox supports, both hidden and exposed, HTTP pipelining was mentioned as an option to investigate which demonstrates how HTTP pipelining can be associated with that kind of strange behavior.


As I posted, all you did was add confusion.
Nothing had been determined as a cause.



> I didn't respond to each of your comments above but focused on the ones I felt I should respond to.


I suggest you focus on providing better links for us users to read


----------



## tomdkat (May 6, 2006)

Wow, this thread has certainly taken an interesting turn, to say the least. 

I've been busy, which is why I haven't posted in the past few days. I hope you, Stoner, and everyone else had a great holiday weekend. 

So, upon reading your posts, Stoner, after I last posted in this thread I see that I've apparently _admitted_ to being disingenious and I've claimed the code is "perfect". Oh yeah, I've also "presented [myself] as someone not to be trusted, in front of the forum." (Can't forget that)

First, I've now seen the links to the supposed anecdotal evidence you posted and I thank you for posting the links.

Second, the forum members will form their own opinions of whether I'm trustworthy or not. If they deem me not trustworthy, I would hope they would put me on their ignore list or otherwise not read my posts. I don't see how I've presented myself in a non-trustworthy manner in this thread or on this forum but you're certainly entitled to your perspective and opinion. I don't recall posting "the code is perfect" anywhere or making that claim in this thread. I had concluded you were being sarcastic with that kind of commentary but perhaps I was mistaken. I have referenced the code as being an authoritative source to address the specific issue of Firefox restricting the maxrequests value to 8 if it was set to a value greater than 8 and nothing more. I've asked the question (a few times) of why this isn't "good enough" for you and you've responded because Firefox isn't a perfectly developed application. Firefox has bugs just as many other applications have bugs and of course I willingly acknowledge this (I mean I must since it's fact) but I consider the broader view of Firefox's development to be irrelevant to this particular discussion.

Third, I think a lot of the confusion generated in this thread stems from your attempt to apply "pure logic" to the article I originally linked to which advised that enabling HTTP pipelining in Firefox could actually slow its performance. If this were true, it would contradict the generally believed idea that enabling HTTP pipelining in Firefox would actually increase its performance. I think your arguments confuse some of the comments made in the article. I fully realize the article isn't a perfectly written article and there are some changes I would make in way the content of the article is presented. Here is how I read the article:



> HTTP pipelining is an aspect of the HTTP protocol that can be used to increase web page loading performance. Enabling HTTP pipelining in Firefox can therefore make Firefox performance faster.
> 
> Chances are you've read various sites and blogs incorrectly recommending using values like '32' for the maxrequests value of the HTTP pipelining setting. These recommendations are wrong because:
> 
> ...


The above isn't meant to be anything but my interpretation of the article. Your application of "pure logic" to the article appears to introduce some confusion that I don't see present in the article. Is the article intended to be definitive? I don't think so. Did I post the article in this thread, representing it as being definitive? I don't think I did.

The article simply provided more information supporting my advice that people be careful if they choose to use HTTP pipelining. If I can find the URL of the site I found that did the more thorough analysis, I'll be sure to post it in this thread. Keep in mind, that article didn't focus on Firefox, specifically, but on ways to improve web page loading speed.

Now, I will certainly admit that you caught me completely off guard with your approach since I wouldn't have expected that outside of the Civ. Debate forum. It might have been more appropriate for us to have started a thread in Civ. Deb. instead of effectively hijacking this thread. 

Regarding your curiosity, maybe I'm just not familiar with your posting style but I certainly got the impression you were more interested in "debunking" the article I linked to rather than getting answers to questions you had. Here is a link to your post in this thread that kicked off our debate. It's post #23 on page #2. That doesn't read with much "curiosity" to me, but that might just be me. In that post, you stated you had the maxrequests setting at 32 for years and didn't encounter any problems so I assumed your "feathers got ruffled" when I posted a link to an article stating 8 was the max, etc.

My comments in this thread weren't about me "proving a point" or about spreading yet more incorrect information. My comments in this debate were in response to my sincere belief you were misunderstanding what was presented in the article but now I'm not sure what to think about what transpired.

At this point, I think this horse and two of its re-incarnations are dead. I'll be sure to be on the lookout for you in Civ. Deb. and maybe we can do this again there. 

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> Wow, this thread has certainly taken an interesting turn, to say the least.
> ............
> 
> edited for brevity..............
> ...





> I hope you, Stoner, and everyone else had a great holiday weekend.



Yes, I did. Hope all went well at your end.



> So, upon reading your posts, Stoner, after I last posted in this thread I see that I've apparently admitted to being disingenious


It surprised me, also.



> and I've claimed the code is "perfect".


Yes, I did get that notion 



> Oh yeah, I've also "presented [myself] as someone not to be trusted, in front of the forum." (Can't forget that)


Shocking, that.
But that sometimes happens in debate when it goes off course.



> First, I've now seen the links to the supposed anecdotal evidence you posted and I thank you for posting the links.


Certainly. Not that they carry any validity on their own merits, but they exist.



> Second, the forum members will form their own opinions of whether I'm trustworthy or not.


That's up to them, certainly.
Personally, IMMHO, I think your ego got the better of you 



> I don't see how I've presented myself in a non-trustworthy manner in this thread .....


Well, certainly by misrepresenting my position in this matter and trying to equate that to some sort of validation of your choice of links.



> I don't recall posting "the code is perfect" anywhere or making that claim in this thread.


You seem to be disingenuous on that point. Of course your position is the 'code' is perfect..............you used an argument based on that to refute full testing. You even gave a link to the code that 'won't allow more than 8 pimeline maxrequests' all the while arguing not to test it because of the way it was written.



> I have referenced the code as being an authoritative source to address the specific issue of Firefox restricting the maxrequests value to 8 if it was set to a value greater than 8 and nothing more.


See how you are doing it again 
To claim an authority and argue no testing ......is to claim it's perfect.  



> I've asked the question (a few times) of why this isn't "good enough" for you and you've responded because Firefox isn't a perfectly developed application.


Why what isn't 'good enough'?
The flawed testing?
It was flawed testing and the tester is now looking a bit dubious as a pro to me 
BTW, he didn't even bother to establish a base line with pipelining turned off.



> Third, I think a lot of the confusion generated in this thread stems from your attempt to apply "pure logic" to the article I originally linked to which advised that enabling HTTP pipelining in Firefox could actually slow its performance.


Not for me......mostly it the flawed testing article that brought up my curiosity.



> The above isn't meant to be anything but my interpretation of the article.


If there had just been a little more effort on the author's part to do a test of all mentioned considerations, I would agree.
Let's face it, what bothers you most is I pointed out the article was flawed.....and you posted it.



> Is the article intended to be definitive? I don't think so.


Well, why did you post it for the forum to read? 



> Did I post the article in this thread, representing it as being definitive?


Backpedal much? 



> The article simply provided more information supporting my advice that people be careful if they choose to use HTTP pipelining.



It was simply flawed 
And remember? I just pointed out there was no baseline testing?



> Now, I will certainly admit that you caught me completely off guard with your approach since I wouldn't have expected that outside of the Civ. Debate forum.


LOL!

Funniest part was eventually linking the author and the tester.
Amusing how the author referred to NTH as 'guys' (plural) when it was most likely just him ( as in singular)? 



> It might have been more appropriate for us to have started a thread in Civ. Deb. instead of effectively hijacking this thread.


Tech threads that are unusually combative get transferred to Civ Debate where they die because few there really care much past their keyboards and monitors 



> Regarding your curiosity, maybe I'm just not familiar with your posting style but I certainly got the impression you were more interested in "debunking" the article I linked to rather than getting answers to questions you had. Here is a link to your post in this thread that kicked off our debate.


You did post those links for the purpose of educating us users. 
I am an aggressive poster, but look closer at that post. I asked about what I didn't understand and pointed out that the article was flawed and couldn't understand why you posted that second link.
I was up front the whole time about my own experiences, never claiming there were more than 8 requests happening, just pointing out the article was short sighted in bringing clarity through testing.



> In that post, you stated you had the maxrequests setting at 32 for years and didn't encounter any problems so I assumed your "feathers got ruffled" when I posted a link to an article stating 8 was the max, etc.


Bet you won't make that assumption again _



> My comments in this debate were in response to my sincere belief you were misunderstanding what was presented in the article but now I'm not sure what to think about what transpired.


Don't lose any sleep over it, I haven't.
That article/test just wasn't up to my expectations of what I thought I'd see in this forum.



> At this point, I think this horse and two of its incarnations are dead.


............a long time ago 



> I'll be sure to be on the lookout for you in Civ. Deb. and maybe we can do this again there


Maybe 
To be honest, Civ Debate has become a bore lately as just about every topic imaginable now has a political slant ......with the elections approaching.

'Battling' with you has actually been more interesting of late 

Jack Stone.


----------



## tomdkat (May 6, 2006)

Stoner said:


> See how you are doing it again
> To claim an authority and argue no testing ......is to claim it's perfect.


Actually, I'm not and this is the perfect example of how we are disconnecting. In fact, I find this kind of assertion to frankly be an attempt to put words in my mouth. How so? Because in later arguments, you will extend the scope of "the code" to more than the part I referenced as the authority and I find that clearly disingenuous. I think you should change your handle from "Stoner" to "Twister". 

Furthermore, you have yet to provide any legitimate reason to dispute the objective evidence I provided. Of course, you will argue your curiosity is a legitimate reason but I'm not buying that. 



> Why what isn't 'good enough'?
> The flawed testing?


Um, no. The code I mentioned in the previous sentence. How you could not understand that baffles me even more. 



> If there had just been a little more effort on the author's part to do a test of all mentioned considerations, I would agree.


You would agree with what? With the posting of my interpretation of the article, as I posted above? Or did your interpretation differ significantly from mine? Your response above doesn't make any sense in the limited context you quoted. I would love to read your interpretation of the article.



> Let's face it, what bothers you most is I pointed out the article was flawed.....and you posted it.


Actually, the article being "flawed" doesn't bother me at all. It's your attempts to prove the flaws that I have issue with. It's like you call it flawed and demonstrate an apparent confusion, on your part. It's like you were miffed that the author didn't write the article you would have wanted him to write and proceeded to criticize it from that perspective. 



> Well, why did you post it for the forum to read?


Because it provided useful and relevant information for people to digest. Does it need to be definitive to serve this purpose? Where are you getting these standards you seem to apply and where can I read them to get the details? 



> Backpedal much?


Not as much as you dance. 



> Tech threads that are unusually combative get transferred to Civ Debate where they die because few there really care much past their keyboards and monitors


Ah, I wasn't aware of that. I guess this thread didn't really get "combative" as much as long winded.



> You did post those links for the purpose of educating us users.
> I am an aggressive poster, but look closer at that post. I asked about what I didn't understand and pointed out that the article was flawed and couldn't understand why you posted that second link.


Your first question in that post told me you didn't understand that point of the article.



> Bet you won't make that assumption again _


Nope, I certainly won't. I know they got ruffled. 



> That article/test just wasn't up to my expectations of what I thought I'd see in this forum.


That's cool. I'm not sure I've seen many threads on this forum that uphold an apparent standard you've applied to the article I linked to but I can accept this comment.



> To be honest, Civ Debate has become a bore lately as just about every topic imaginable now has a political slant ......with the elections approaching.
> 
> 'Battling' with you has actually been more interesting of late


Ah, the truth comes out.  :up:

Peace...


----------



## Stoner (Oct 26, 2002)

tomdkat said:


> Actually, I'm not
> 
> edited for brevity...............


Sure you are....I've pointed it out, logically more than once 



> I find this kind of assertion to frankly be an attempt to put words in my mouth.


Perhaps if you use different words with different meanings your intentions will be better served.



> I think you should change your handle from "Stoner" to "Twister".






> Furthermore, you have yet to provide any legitimate reason to dispute the objective evidence I provided.


So?
I brought questions and curiosity ......all from a flawed article you (  ) posted.



> Of course, you will argue your curiosity is a legitimate reason


Yep.



> Um, no. The code I mentioned in the previous sentence. How you could not understand that baffles me even more.


Because it made no sense.
How would I, a user with no programming skills be a judge of how to consider the 'good enough' qualities of code beyond experiencing the execution of that code?
It made no sense because you know I have no ability to read code and judge it.



> You would agree with what?


With out rereading my post this was generated from.......I would have agreed the article and test was more objective with the appearance of credibility. But I will comment that if I had then found out the author was quoting himself ( as tester) as an outside authoritative source, I again would have then wondered about the validity of the article.
So.....the article was more than just flawed 



> With the posting of my interpretation of the article.......


That was less an interpretation and more attempted rationalization on your part.
It doesn't work to present a flawed article and then argue to ignore the flaws, especially as they address the topic in this thread.



> Actually, the article being "flawed" doesn't bother me at all.


...............and it doesn't seem to bother you to present it as a learning tool, either.



> It's your attempts to prove the flaws that I have issue with.


Life can be cruel.



> It's like you call it flawed and demonstrate an apparent confusion, on your part


So?
The article was flawed.
The author even admitted not understanding issues in the test.



> It's like you were miffed that the author didn't write the article you would have wanted him to write and proceeded to criticize it from that perspective.


It did seem like a waste of much of my time. And just look at how much has been posted over that flawed article. More waste of time, imo.



> Because it provided useful and relevant information for people to digest.


\
But it was incomplete----------> flawed  
(Not very scientific, either)



> Ah, I wasn't aware of that. I guess this thread didn't really get "combative" as much as long winded.


Yep. If it had been combative, a mod would have closed it quickly.



> Your first question in that post told me you didn't understand that point of the article.


I'm not afraid to ask or question.



> Nope, I certainly won't. I know they got ruffled.


Then work with it and see where it gets you 



> Ah, the truth comes out. :up:


Yep .......see you in Civ Debate.


----------



## Super-D-38 (Apr 25, 2002)

Do I need to do all of the tweaks?
As I only did the http pipeline ones.. 
Some pages do load very fast now, but seems ebay has an issue with it. 
Refreshing the page will fix it, but initial load comes up goofed.
Maybe the new delay settings will help. 

 still new to tweaking.


----------



## guitar (Jan 15, 2006)

1- Open Firefox, type about:config in your Firefox browser.

2- Right click anywhere on the page, then from the menu select &#8220;New&#8221; then &#8220;Integer&#8221;.

3- When the dialog box appears, enter the following string:-

browser.cache.memory.capacity

4- It will open another dialog box, enter: 16384

p/s: 16384 is the exact number that represents 16MBs of RAM.

5- Lastly, close Firefox and restart.


----------



## JohnWill (Oct 19, 2002)

Why not use the setting *browser.cache.memory.capacity = -1*, which defaults to a value based on the amount of memory installed?

When I check mine on this machine, it's at 64k with 2gig of memory installed.


----------



## guitar (Jan 15, 2006)

that works well john unless i'm running a few programs then i get a system resources to low but i only use this old p3 800 with 384mb ram comp for browsing so i pushed it running a few progs i'm sticking with the -1 thanks


----------



## guitar (Jan 15, 2006)

had to revert back caused to many stalls i'll try on a faster comp


----------



## cstrikehero777 (Sep 13, 2008)

HOLY CRAP>> ITS SO FAST!!!.. k its not that much but page loading is definatly noticeable..


----------



## JohnWill (Oct 19, 2002)

I mis-spoke, it's really 64mb. 

browser.cache.memory.capacity: 65536


----------

