09-20-2009 12:04 PM - edited 09-20-2009 12:16 PM
I'll give up; it seems not possible to change the title of the thread :(
Mattsegers had anyway flagged this thread for a moderator
09-21-2009 09:39 AM
09-21-2009 10:10 AM - edited 09-21-2009 10:36 AM
I have tested this on two computers running NIS2010 (1x64bit, 1x32bit) as well as two computers running NIS2009 (2x32bit). The same issue is present for all of them. Maybe Symantec just won't discuss this?
Thanks and regards,
09-21-2009 10:20 AM
Interesting. The strange thing is, when I was beta testing NAV 2010, I didn't notice the issue. But, then again, I wasn't looking for it and I would only notice it in certain situations, such as large file copies to or from my server.
Disabling the IPS driver is a workaround to get the network speed back and stop the long pauses when you are writing to a network share, but, to be honest, I'd rather uninstall it than start performing ugly hacks to make it work correctly.
Hopefully this issue will be fixed soon and as always, I am available to do any testing required, because I'm like that.
09-21-2009 12:58 PM
Because the IPS feature must inspect all of your network traffic, there will be a hit to your network performance. For most users' regular Internet activity the impact should be negligible. For higher speed network traffic, the impact depends upon processor speed and characteristics of the data being copied. Symantec will continue to investigate ways to reduce the CPU and memory requirements of the various technologies, including IPS, but there will always be some impact.
Rather than disabling the driver, have you tried to disable Intrusion Prevention from the main product interface? This accomplish similar performance results as disabling the driver and will automatically re-enable after a few minutes.
09-21-2009 01:52 PM
In my system, there was no gain in just disabling the intrusion prevention. With/without this feature, the transfer of a 683MB zip file was approximately 30-32MB/s. When disabling the IDSvix86 driver, the transfer was approximately 52-57MB/s. This is not acceptable.
Thanks and regards,
09-21-2009 02:06 PM
Disabling Intrusion Prevention from the main UI has absolutely no effect on the network slowdown, I just tried it several times.
The only action which makes a difference is running 'sc stop IDSvia64' from an elevated Command Prompt.
To put this in perspective, with the IDS driver enabled, I get 40 Megabytes / second from my server to my desktop. If I stop the driver as above, I get 65 Megabytes / second from my server to my desktop. This is a good 60% improvement.
My CPU speed is not an issue, I have 2 * Dual Core Xeons and the cpu usage whilst copying across the network is the same regardless if the IDS driver is running or stopped, so CPU usage is not an issue here.
If it was maxing out my cpu, I could understand, but it isn't.
The type of data that I have ran these tests with is HD .mvk video files, but I have also used Windows 7 .iso files with exactly the same result, so I do not believe that the data is the issue.
The most I can ever get through my network with IDS enabled is 40 Megabytes / Second, on a gigabit network I must add, that is with 2 concurrent transfers (which come from 2 separate disks on the server) that would normally hit 80 Megabytes / sec.
There is definitely an issue here which does need to be investigated.
09-21-2009 05:46 PM
09-21-2009 06:41 PM
09-21-2009 07:18 PM - edited 09-21-2009 07:20 PM
Having a 40 Megabyte / sec slowdown on my network isn't acceptable, there has to be a balance between performance and security and trashing a network connection is not a good balance.
It basically turns my gigabit ethernet into 400mbit ethernet, as that is the fastest I can get data through when the IDS driver is loaded. Plus, when I am writing files to my server, there is a big spike of network activity, then a 15-20 second pause, then it eventually transfers the file. This also does not occur with the IDS driver unloaded.
It really needs to be looked at. It almost seems like the IDS is capped at 400mbit because it will not go any quicker. Maybe it's a bug in the driver that is artificially capping the throughput?