NIS causes high DPC latency when browsing

Norton Security | Norton Internet Security
1

NIS Intrusion Prevension causes high DPC latency when browsing, especially on pages with a lot of images. Confirmed on both latest NIS 2012 (19.8 version) and latest NIS 2013 (20.1.1.2). High DPC latency results in microfreezes in browser and audio dropouts when listening to music during browsing. You can check DPC latency using this tool: DPC Latency Checker

 

Is it possible to get a fix for this from Symantec?

 

Here is my system information: Windows 7 SP1 x64, NIS 20.1.1.2, NIC: Intel 82579LM, latest generic Intel driver.

High DPC Latency occurs in both Firefox and Chrome, doesn't matter which version. First I checked to see if it was specific driver that was causing this, by turning off various drivers until I could pinpoint the problem to Intel 82579LM. I tried installing different versions of this driver, but the problem remained in all versions.

 

I found the situation in which high latency occurs: when NIS Intrusion Prevention is enabled and when browsing pages with a lot of content. If I disable NIS IP, that latency is always within normal range (not greater that 270 microseconds) and system responds as fast as it should. But, with NIS IP enabled it can go up as high as 100000 microseconds.

 

High DPC also dissapears when NIS IP is enabled but Windows Base Filtering Engine service is off. From its description "The Base Filtering Engine (BFE) is a service that manages firewall and Internet Protocol security (IPsec) policies and implements user mode filtering. Stopping or disabling the BFE service will significantly reduce the security of the system. It will also result in unpredictable behavior in IPsec management and firewall applications.".

 

So am I correct that it's better not to disable BFE service even if NIS IP and firewall are on? Does NIS IP and firewall depend on this service?

 

Still, it would be better to get a fix for this that doesn't require disabling Windows services.

2

Hi Bro,

 

Congratulations for your post, I'm experiencing this issue with my older XP Pro 32-bit  laptop and IE8. (Intel single core @2.00 GHz and 1.5 GB DDR2 RAM).

The problem started after NIS 19 version and never before, with version 18.

My current NIS version is 19.0.0.9.

I'm trying for a very long time to resolve this but I didn't know about DPC latency.

However, with my 2 newer laptops running W7 Home Premium 64-bit and IE9, no problems, probably because of much better CPU and RAM.

It would be great if someone from Symantec or a member of the community could help us find a solution or a workaround.

 

Best,

3

Hi Apostolos, thanks for replying. 

 

I found older thread about this issue: BUG high latency and audio dropouts when doing backup through network NIS 2012 Intrusion Prevention but there is no solution to the problem.

 

Even on new CPUs high DPC can be noticeable sometimes, for example, on my Core i7-2630qm powered laptop, browser seems to freeze for a moment and its UI feels slowed down when loading content-heavy pages. Sometimes Windows even displays Firefox window in a "this program stopped responding" state. At first I thought it was a bug or poor design of FF, since processor load was no higher that 5-7% max in these situations. Then I discovered that only happens when there is a high DPC latency. And that is caused by NIS IP.

 

If I turn off NIS IP, then FF runs very smooth without these glitches and freezes on the same pages where I encountered high DPC. I turn it on, and it slows down when loading them again. In both cases browser cache was cleared so that page and its content will be downloaded again. I have tried it multiple times, so it is very reproducible, and not random occurring situation.

YouTube, for example, is one of the sites that gives consistent high DPC latency when loading pages from it.

 

Since NIS is being advertised as "Blazingly fast performance delivers fast browsing and file scanning", I'd say that this issue deserves to be fixed by Symantec. But without impacting protection, of course.

4

Hi,

 

I agree that the issue needs to be fixed.

I do not use FF but with IE8 I see the problem almost every day.

I do not have particular problems with Youtube, but when I use Flickr.com, IE8 momentarily freezes quite often, especially when the "back" button is used, and sometimes it also happens when I visit Smugmug.com.

After 2 or 3 seconds, the browser recovers by itself without any message warning but it's very annoying.

Let's hope to receive a reply from Symantec in the next few days.

 

5
Apostolos wrote:

Hi,

 

I agree that the issue needs to be fixed.

I do not use FF but with IE8 I see the problem almost every day.

I do not have particular problems with Youtube, but when I use Flickr.com, IE8 momentarily freezes quite often, especially when the "back" button is used, and sometimes it also happens when I visit Smugmug.com.

After 2 or 3 seconds, the browser recovers by itself without any message warning but it's very annoying.

Let's hope to receive a reply from Symantec in the next few days.

 

 

Hi, Apostolos.  Have a look at the following thread:

 

http://community.norton.com/t5/Norton-Internet-Security-Norton/CPU-and-Memory-at-100/m-p/590736

 

 

Something there may help you track down the problem.

 

 

Hope this helps.

 

6

Bro,

 

When you say "disable NIS IP", you mean disable the Intrusion Prevention add-on from the browser or from the main NIS user interface?

Thank you.

 

Best,

7

I mean Intrusion Prevention from the main NIS interface. It can also be found at the top of Network tab in NIS settings window.

8

Does it make any difference to your system if you only disable the Intrusion Prevention add-on from the browser (Norton toolbar) ?

I tried with Norton toolbar Intrusion Prevention disabled and I have a much better browsing. (no microfreezes etc).

However, it was only for test purposes because it is highly recommended NOT to disable Intrusion Prevention.

I hope that there will be a fix from Norton.

Let me know if it works for you too.

Thank you.

 

Kind regards, 

9

You have explained a problem which I have been having.  I use my computer to control some specialized equipment, and the software is very sensitive to DPC isssues.  By various tweaks to the program, it is fairly robust, but I still notice bursts of long DPC when I browse.  As discussed in the other replys, I can verify that turning off those services solves the problem!  Let's hope that Symantec has a real fix.

10

I've tried disabling both Norton addons in Firefox, but the problem remained. Checked with DPC Latency Checker while loading pages from Flickr. I've also found a site with a lot of images on front page where spikes in latency are always noticeable to test it - uberhumor.com. Since in that older thread I mentioned before, high spikes in latency were present during Acronis backup using ftp connection to network drive, it seems that, at least in that case and mine, high latency is not connected to browser add-on but to Intrusion Prevention (setting in NIS main window).

 

Apostolos, can you please check if there are latency spikes with add-on disabled but Intrusion Prevention (in main NIS window) enabled using DPC Latency Checker from my first post? Maybe they are smaller but still there. It would be best to delete temporary internet files in IE before testing, so that images and content on pages get downloaded from the network and not from disk cache. If disabling add-on indeed makes latency return to normal while browsing in your case, maybe it has something to do with other factors, like only certain network drivers are having this problem with NIS IP. Then we can get more information on this problem.

 

As Tregonsee said, some software can be very sensitive to high DPC, so even if browsing microfreezes are not connected to DPC latency spikes in most cases, it would still be better if Symantec fixes it.

11

Hello Bro,

 

Just checked with my XP Pro SP3 system and IE8.

Norton toolbar's add-ons both disabled (Vulnerability protection and Identity Protection).

Browsing was little improved, not a noticeable difference.

However, when I re-enabled the 2 add-ons but disabled Intrusion Prevention from the main NIS GUI, I had a huge improvement!!.

Conclusion, you were right about  NIS IP.

One strange thing is that with my other laptop W7 HP 64-bit and i7 2670Q processor and 8GB DDR3 RAM, I have no microfreezes at all even when I visit flickr or other image websites.

The only difference, other than better hardware components, is that I use IE9 32-bit.

Hope this helps,

 

Best,

12
Apostolos wrote:

Hello Bro,

 

Just checked with my XP Pro SP3 system and IE8.

Norton toolbar's add-ons both disabled (Vulnerability protection and Identity Protection).

Browsing was little improved, not a noticeable difference.

However, when I re-enabled the 2 add-ons but disabled Intrusion Prevention from the main NIS GUI, I had a huge improvement!!.

Conclusion, you were right about  NIS IP.

One strange thing is that with my other laptop W7 HP 64-bit and i7 2670Q processor and 8GB DDR3 RAM, I have no microfreezes at all even when I visit flickr or other image websites.

The only difference, other than better hardware components, is that I use IE9 32-bit.

Hope this helps,

 

Best,

 

Hi, Apostolos.  This would indicate to me that NIS could be the "canary" and not the problem.  It also tends to suggest the problem is an interaction between NIS and certain other components - which are not present on all machines.  The question then becomes - is NIS the offender or the other component?

 

 

Things to check:

 

1. Have a look at that stuff I mentioned in Post 5 in this thread.

 

Note: That post was written to someone who did not have a lot of competency in dealing with complex software interactions.  Thus, the post recommends steps which may not apply to those with high competence.  However, the gist of the post remains relevant - and the investigative steps can be performed regardless - in order to narrow down the cause/effect.

 

 

2. I have had two instances where NIS has impacted Latency on my machine.  One situation had to do with non-Microsoft Windows Explorer Shell Extensions which interfered with the speed at which Explorer opened subfolders containing lots of images.  This "magically" cleared up one day - no doubt as part of a NIS Live-Update.  Regardless, I had traced down the source of the offending shell extension - it was part of Roxio Easy Media Creator 8.  Because I was not willing to do without the features of that program - I put up with the delay while Symantec worked out a fix.

 

Note: The Roxio Easy Media Shell Extensions perform non-standard manipulation in the Windows Explorer right-click flyout-window.  The problem is definitely Roxio's doing - NIS has accommodated Roxio's screwup.

 

 

3. The second latency issue had to do with extremely slow redraws on the Symantec site itself.  This was noticed and commented on by many at the time.  Symantec responded to that situation and again the problem was resolved with no changes on my end - all I and everyone else had to do was be patient.  I suspect this was a problem with Lithium - but I have had no confirmation as to whether or not my suspicion was correct.

 

 

4. You have seen variations on your problem - depending upon the machine on which NIS is installed.  Because issues like you describe vary with the particular drivers installed on a machine, the problem can be resolved in one of two directions.  Either Symantec can accommodate the other software, or the other software can be properly updated and fixed so it does not induce latency.  The decision as to which scenario takes place depends upon the developers of both pieces of software.

 

If Symantec thinks the offending piece of software will be upgraded - then Symantec expects the developers of the offending software to get off-the-stick and fix their problem.  If Symantec thinks the offending piece of software will not be upgraded - and they know that piece of software is common enough that Symantec are going to take it in the shorts for the other software developer's screwup - then Symantec will work-around the other software developer's mistake.

 

 

5. You have two choices.  You can either wait for this problem to be solved in-house at Symantec, or you can research the situation yourself and provide details which accelerate the problem-resolution-process.  You start your research by following the suggestions made in Post 5 in this thread.  It is possible that an update to your Network Drivers (or something similar) is all that is required to resolve this problem.

 

However, that information is not forthcoming without investing the time and energy to do the research and isolate the problem.  Eventually research will lead to evidence either pointing towards something completely under Symantec's control (which is possible) - or proof the problem is an interaction with XXXXXXXX software such that Symantec and that software developer need to cross-coordinate (there are lots of times this has occurred with Creative Labs software).

 

 

Hope this helps.

 

13

Hi, twixt.

 

I checked this issue on an older machine of mine.

That system is powered by Pentium 4 2.6GHz (Northwood core) with 4GB RAM (3.25 available) and 3Com 3C940 Ethernet NIC.

 

I backed up my system and restored a clean image of Windows XP SP3 and NIS 19.8, and installed all security updates for Windows and Norton. So there is nothing on this system besides latest Windows critical updates, drivers, and NIS.

 

High latency spikes remained, checked with DPC Latency Checker. In all three major browsers. Again, that was a clean system, with nothing besides NIS installed. Processor usage was never higher that 40%, and there was plenty of free memory, so low system performance causing this is unlikely. And, as I posted before - on my laptop both memory and CPU load are very low when there are spikes in latency.

 

I also checked this using wi-fi on my laptop. Same issue.

 

So, to sum all of the info we got up until now.

 

We have high DPC latency spikes when using network with NIS Intrusion Prevention enabled in at least 19.7, 19.8 and 20.1 versions, in both Windows XP SP3 32bit, and Windows 7 SP1 64bit, with at least four different NICs: Realtek 8111E (from the thread I linked to in my second post), 3Com 3C940 (driver was published whole 9 years ago, no updates after that), and Intel 82579LM and Advanced-N 6205. In addition, while using Intel 82579LM, I checked with several driver versions starting from 2010 up until the latest version.

 

If NIS Intrusion Prevention is disabled that DPC latency is stable and within normal limits. And high DPC spikes can be caused not only while using browser, as evidenced by that other thread, but by a general network usage, like uploading files by ftp. Also, I checked with both IE, Chrome and Firefox. This problem is always reproducible.

 

So, a lot of different systems, different hardware and drivers. I think it is more than likely that the only common factor here is NIS.

14
bro wrote:

Hi, twixt.

 

I checked this issue on an older machine of mine.

That system is powered by Pentium 4 2.6GHz (Northwood core) with 4GB RAM (3.25 available) and 3Com 3C940 Ethernet NIC.

 

I backed up my system and restored a clean image of Windows XP SP3 and NIS 19.8, and installed all security updates for Windows and Norton. So there is nothing on this system besides latest Windows critical updates, drivers, and NIS.

 

High latency spikes remained, checked with DPC Latency Checker. In all three major browsers. Again, that was a clean system, with nothing besides NIS installed. Processor usage was never higher that 40%, and there was plenty of free memory, so low system performance causing this is unlikely. And, as I posted before - on my laptop both memory and CPU load are very low when there are spikes in latency.

 

I also checked this using wi-fi on my laptop. Same issue.

 

So, to sum all of the info we got up until now.

 

We have high DPC latency spikes when using network with NIS Intrusion Prevention enabled in at least 19.7, 19.8 and 20.1 versions, in both Windows XP SP3 32bit, and Windows 7 SP1 64bit, with at least four different NICs: Realtek 8111E (from the thread I linked to in my second post), 3Com 3C940 (driver was published whole 9 years ago, no updates after that), and Intel 82579LM and Advanced-N 6205. In addition, while using Intel 82579LM, I checked with several driver versions starting from 2010 up until the latest version.

 

If NIS Intrusion Prevention is disabled that DPC latency is stable and within normal limits. And high DPC spikes can be caused not only while using browser, as evidenced by that other thread, but by a general network usage, like uploading files by ftp. Also, I checked with both IE, Chrome and Firefox. This problem is always reproducible.

 

So, a lot of different systems, different hardware and drivers. I think it is more than likely that the only common factor here is NIS.

 

Hi, bro.  I have a test machine here running a Northwood 3.4GHz, 4GB RAM, WXP-SP3 - which does not exhibit the problems you describe in NIS 2011 or NIS 2012.  Thus, I think, what your experiments show, is that in your particular case - the problem is not network-driver-related.  It is something else.  Furthermore, there is no guarantee that the fix to the problem does not involve updates to the system which are not part of the standard "Critical Updates" package.

 

For example, installing/updating the entire DotNet 1.0/1.1/2.0/3.0/3.5 stack, the removal and replacement of the Microsoft JVM in XP with a recent copy of the Oracle JVM, an update to Windows Media Player 10 or later - along with all the subsidiary patches to these products - etc., etc. and so on - may be integral to solving the problem.

 

 

Other things which are known to have affected DPC Latency in the past:

 

1. Realtek/Creative Labs/CMI/ADI Sound Card Drivers.

 

2. ATI/Nvidia Video Drivers - specifically Catalyst Control Centre with its need for updated DotNet support and/or Nvidia Forceware Control Panel bugs.

 

3. Nero/Roxio CD/DVD Burner Software

 

4. Windows Explorer Shell Extensions added by various-and-assorted different programs.  Thus, the problem could be caused by NIS - and my previous post explains that is still a possibility - but there are lots of other shell extensions that could be implicated as well.  Thus the need for more-wide-ranging tests.

 

5. Buggy Video and/or Sound Codecs

 

 

Now, that gives quite a list of things to investigate.  More than can just be scanned over a few hours.  To check all the above for latency implications would take an expert following the instructions at the DPC investigative websites mentioned in Post5 at least a day or two, probably more.

 

Thus, I am forced to conclude by the quick replies here that what's happening is that people want to kvetch and whine and moan - more than they want to invest time and effort into researching what's really going on. 

 

Please note that no disrespect is meant by this observation - it's just an inescapable conclusion forced by the actions of those doing the complaining.  Either you're part of the problem, part of the solution, or an interested bystander.  Pick your poison.

 

 

If you want to help resolve this problem more quickly, and get back to enjoying your system in a productive manner, then IMO it behooves you to contribute, not complain.  Symantec have not indicated they have a handle on this problem - thus they can use all the help they can get from users who are experiencing the fault.

 

If you can provide the info Symantec require to allow them to be able to duplicate the problem in-house - or you find the root cause of the problem and discover what is needed is an update to something else which is inducing DPC stalls when NIS is using DPCs - then you are contributing to the resolution of the problem.  To complain and kvetch and not contribute to the research will not get the bug fixed one day earlier.

 

 

Hope this helps your understanding.

 

 

15

Hi twixt.

 

Thanks for you suggestions, however, you are jumping to conclusions when you say that I or anyone else on this thread are moaning and whining and not contributing. I haven't read anything on this thread that can be described as whining, except maybe when you said it about others or maybe even someone in particular. That looks like you are whining, no disrespect intended of course, just observation of your actions. Anyway, your opinion of our reaction doesn't help to resolve this issue either, so please avoid such off topic remarks. If you have new suggestions to test something, than please, by all means, post them, and when someone is able to perform them, I'm sure they can post the results.

 

I read your post in that thread you have linked, and if I have the time, I will follow those suggestions and share results either here or directly with Symantec. As you said, these tests can take a lot of time. Time that many people, myself included, can't spend immediately to go do right after you post it. These test can also cause a lot of inconvenience if affected machine is the main computer that is used for work. There is also the question of spending a lot of time testing software that you paid a good amount of money for. You can suggest, of course, to go buy competitors products if someone is unhappy and unwilling to spend time to test software that they paid for to make it work for them as intended. This is not me whining, I just think you misunderstood and I'm trying to make my intention to contribute clear to you.

 

Regarding your points 1 through 5 about different things. As I mentioned in my previous post, I spent some time restoring a clean image. So again, there was no other software besides installed Windows and NIS on it. I checked with only 3Com driver installed. No AMD drivers, no sound card drivers, no .Net, no JRE, no nero, no shell extensions, no codecs. I checked it again with other drivers installed. As I said, if NIS IP is enabled, the problem appears, if it is not, there is no problem. Perhaps you think that this information was not contributing, but here it is anyway.

 

Regarding your suggestion that presence/updates of .Net, JRE, WMP even can be related to this - I'll check this also when I have the time. I doubt that installing them on a system can make the issue that is causing high DPC when NIS IP to disappear, but I'll test it. I'll also install recommended updates to Windows to see if fix is a part of them.

 

Hope this helps your understanding.

16

Quick update. Using xperf I found that ndis.sys causes high latency when NIS IP is enabled. I found this earlier using LatencyMon when I thought that bad Intel ethernet driver before I found out that latency spikes dissapear if NIS IP is off.

 

The only suggestion that I've found yet is from the thread at msfw.org that twixt linked to in another thread: "If the NDIS.sys driver is shown as possible cause, check your (W)LAN drivers for updates".

 

Problem with this pointing to ndis.sys is that before pinning this on NIS IP, I've read a lot of posts about Intel 82579LM where it was said that downgrading to a specific lower version (or version from certain manufacturer, HP, and not generic Intel or Lenovo driver) resolves this. I tried these versions, and they didn't resolve the issue in my case.

 

I'll investigate this further when I have enough time.

17
bro wrote:

Quick update. Using xperf I found that ndis.sys causes high latency when NIS IP is enabled. I found this earlier using LatencyMon when I thought that bad Intel ethernet driver before I found out that latency spikes disappear if NIS IP is off.

 

The only suggestion that I've found yet is from the thread at msfw.org that twixt linked to in another thread: "If the NDIS.sys driver is shown as possible cause, check your (W)LAN drivers for updates".

 

Problem with this pointing to ndis.sys is that before pinning this on NIS IP, I've read a lot of posts about Intel 82579LM where it was said that downgrading to a specific lower version (or version from certain manufacturer, HP, and not generic Intel or Lenovo driver) resolves this. I tried these versions, and they didn't resolve the issue in my case.

 

I'll investigate this further when I have enough time.

 

Hi, bro.  Your previous two posts are great - filled with the kind of feedback that is needed to make further suggestions.   Now I understand in greater depth - which is the needed information.

 

 

Next steps:

 

From the reactions of ndis.sys - I concur that the network drivers are certainly worth investigating in more detail.

 

Things to try:

 

1. In the Internet Explorer Tools/Internet_Options Panel, under the "Connections" tab, there is a button marked "LAN Settings".  Clicking on the "Lan Settings" button opens a dialog box where you have the ability to customize how IE "talks" to the LAN.  By default, Microsoft enable the first option in this panel called "Automatically Detect Settings".  This plays absolute hob with certain ISPs that use transparent caching proxy servers  (My ISPs here qualify).  Uncheck the box, close and reopen IE, and see if that makes the stalls go away.  On general principles here, I disable this option on every machine because of its potential to make IE slow, stuttery and unstable.

 

2. For Windows XP, there is a Registry Parameter called IRPStackSize.  The default value (Decimal 15) is commonly too small for home networks with more than 3 machines - if you have lots of fileshares active - which I do.  I add the parameter to the Registry and update the value to Decimal 30.  This fixes "a whole whack" of mysterious Windows-Network-Related weirdness.  Google "IRPStackSize" for info on how to add this parameter to your Registry.

 

3. NIS occasionally messes up its configuration of the Symantec Network Security miniport.  The way to fix this is to completely remove all network-card-specific entries in Device Manager for the target network card - and allow this stuff to be autodetected and autoinstalled on the next reboot.  NIS will then autoregenerate the Symantec Network Security miniport.  See what happens.

 

Note: When you reinstall the Network Card Drivers, go in and enable the QOS settings.  This will add the Network Card Driver's QOS miniport element to the Device Manager tree.  This could "smarten up" the driver so it doesn't waste time waiting for stuff that won't show up in certain contexts.

 

4. Can you generate a Network Security Map?  Did you have to "Initialize" the map the first time you tried to view the map?  If so, this changes bunches of things inside NIS during the initialization process - one or more of which might be "the magic bullet".  Check it out and see what happens.

 

5. The latest set of Windows XP updates - which were released on Tuesday - include new kernel drivers.  While there is no information forthcoming on what MS fixed inside the kernel - updates for these usually contain fundamental changes to the timing parameters for general Windows operations.  Often, kernel changes "migrate" their benefits back in other directions than anticipated.  Can you check to see if these recent updates are the solution?

 

6. Can you try a different network card from a family that you have not investigated so far?  Eg: SMC 1211TX?  If this problem occurs across all netcards, then this points back to either NIS or Windows itself.

 

 

If the above investigations do not provide any further information towards localizing the problem, it's time to bring out the heavy artillery.  Go here:  http://technet.microsoft.com/en-us/sysinternals/

 

On the Windows Sysinternals website you will find a program available for download called AutoRuns.  If you download and install this program, it contains the ability to probe *everything* that Windows autoloads at startup - including all the various and assorted Windows Shell Extensions.  Autoruns has the ability to selectively enable/disable "bits and pieces" of the autoloaded elements of Windows - thus experiments here can determine which sub-component of Windows is active in causing the delay.

 

Another program available from the Windows Sysinternals website is Process Explorer.  This is one of the "big daddy" Windows debugging tools - used when everything else is not providing the desired info.  Using Process Explorer and its companion utility Process Monitor, you may be able to figure out what is going on during those mysterious "delays".  That should provide the information that points towards what is truly causing the DPC stalls.  And again, this might be NIS - but the results of these investigations may let us know rather than guess.

 

If you are unfamiliar with using Process Explorer to investigate Windows problems,  check out Mark Russinovich's "Case of the Unexplained" presentations for info on how to use Process Explorer and Process Monitor to profile Windows activities during suspicious or annoying "events".   Warning: this is heavy duty stuff for propellerheads - but it does provide an excellent overview of what is commonly necessary to determine what is actually going on when a bug is causing a problem.

 

 

Hope this helps.

 

18

Hi, twixt. Thanks for assistance. Here’s a quick update on what I have been able to test so far. I’m not sure when I will be able to use old desktop with XP for testing, so for now I’m running tests on Win 7 laptop. 1) I tried switching off proxy settings auto detection both in FF and in IE (control panel) settings. Spikes in ndis remained. 2) I didn’t find IRPStackSize parameter in Win 7, so I assume this is only for XP? Anyway, I tried adding it to registry to where it is supposed to be and setting it to 30. After rebooting, I checked and spikes remained. 3) I removed NIC drivers and rebooted to reinit it. Still no fix, with QoS and without. 4) Yes, I can generate this map. When I first viewed it, I remember NIS asking me to initialize it. I also tried setting different trust levels inside Map window, still no fix. 5) in Win 7 I have the latest updates installed, didn’t seem to change anything, spikes remained. I also installed all of the recommended updates to win7, still no effect on latency spikes. 6) Checking with another NICs is impossible in my case since I don’t have any other cards besides Intel ones integrated to the laptop. I also don’t have any PCI cards to test on desktop. As for sysinternals tools, I didn’t have enough time to test with them yet. I’m going to be very busy for the next few weeks, so I’m not sure when exactly I will be able to continue testing, but I will post here when I have new information.

19
bro wrote:
Hi, twixt. Thanks for assistance. Here's a quick update on what I have been able to test so far. I'm not sure when I will be able to use old desktop with XP for testing, so for now I'm running tests on Win 7 laptop. 1) I tried switching off proxy settings auto detection both in FF and in IE (control panel) settings. Spikes in ndis remained. 2) I didn't find IRPStackSize parameter in Win 7, so I assume this is only for XP? Anyway, I tried adding it to registry to where it is supposed to be and setting it to 30. After rebooting, I checked and spikes remained. 3) I removed NIC drivers and rebooted to reinit it. Still no fix, with QoS and without. 4) Yes, I can generate this map. When I first viewed it, I remember NIS asking me to initialize it. I also tried setting different trust levels inside Map window, still no fix. 5) in Win 7 I have the latest updates installed, didn't seem to change anything, spikes remained. I also installed all of the recommended updates to win7, still no effect on latency spikes. 6) Checking with another NICs is impossible in my case since I don't have any other cards besides Intel ones integrated to the laptop. I also don't have any PCI cards to test on desktop. As for sysinternals tools, I didn't have enough time to test with them yet. I'm going to be very busy for the next few weeks, so I'm not sure when exactly I will be able to continue testing, but I will post here when I have new information.

 

Hi, bro.  Good work on the tests, you've narrowed things down considerably.

 

Things I have found out in the last couple of days:

 

1. Improvements to the TCPIPBufferSize parameter in XP make a marked difference in latency when entering or refreshing a website.  The default values are junk.  I've had stuff like this in place on all my WXP boxen for ages.  This may be why the problem does not show up for me.

 

 

Latest parameter updates are as follows:

 

 

--------------begin_Webtweak.reg-------------

 

Windows Registry Editor Version 5.00

 

[HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:00000020

 

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:00000020

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"GlobalMaxTcpWindowSize"=dword:01000000
"TCPWindowSize"=dword:00040000
"Tcp1323Opts"=dword:00000001

 

 

---------------end_Webtweak.reg--------------

 

 

Creation/Installation Instructions for Webtweak.reg:

 

1. Copy the above into notepad (omitting the begin/end items) and create Webtweak.reg

 

2. Ensure you have at least one full carriage return at the end of the file (cursor can go past the end of the last line)

 

3. Use "Save As" in Notepad to create Webtweak.reg  (icon for file should be blue building blocks, not a text icon)

 

4. Double-click on file to merge the above with the Registry.  OK the changes.

 

5. Shut down and restart WXP to ensure all changes to the TCP/IP Stack are fully propagated.

 

 

See what happens.

 

 

As far as Vista or W7 is concerned, much of the stuff that plagues WXP regarding TCP/IP Buffer Sizes has been replaced with auto-adaptive algorithms that adjust buffersize on-the-fly-as-necessary.  Thus, the above changes are not supposed to be necessary for Vista or W7.  Then there's the difference between theory and reality...   :smileywink:

 

See here:  http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

 

 

 

Hope this helps.