Network packet loss due to audio usage, Win7
I've come across a rather strange problem when testing under Windows 7. I am running all standard tests except USB, tape, and printer. I have set the network test set to fail if packet losses exceed .1%. When running the tests, the systems will fail after approx. 20 minutes with excessive network packet loss. There are two NICs in the system, and I have set Burnintest to test all NICs with each NIC pointing to a different server. If I remove just the sound tests, there is 0% network packet loss even after running for 12 hours. This same failure mode was observed on three different platforms using all different motherboards - one a 945GME, one a 965GME and the last a Q45 chipset. They all have Realtek audio chipsets, but the chips are different between them (ALC888, ALC655, etc.) At this point I was thinking that the driver might be to blame, as all these have the latest driver versions from Realtek, but there are no previously released drivers available to try. So, I instead disabled the onboard audio and installed a PCI audio card using a Crystal Media chipset using completely different drivers. The failure persists. I then removed the audio test from Burnintest, and instead played a .mp3 file with Windows media player. The failure persists. In fact, even when media player is *paused* and not playing the .mp3 file (but the file is locked), Burnintest STILL fails with packet loss. Tested both 5.3 build 1036 and 6.0 build 1017. I'm beginning to think this is a problem with Windows 7. DRM or something? Note that If I only test the MIDI function with Burnintest that the failure still occurs.
Hoping you guys have some ideas, I'm pretty much out of them.
I have not heard of this problem and I don't know. It sounds like a chipset hardware issue when under load. I had a look at some of the related Intel specification updates, e.g. http://www.intel.com/Assets/PDF/specupdate/316274.pdf, and note that there are some issues related to DMA Transfer completion for DMA sensitive devices in some scenarios. Depending on your setup, maybe it is related to this.
Also, http://www.intel.com/Assets/PDF/specupdate/313057.pdf, refers to
"Intel ICH8 Integrated LAN DMA Error" and "ICH8 GbE Packet Buffer Writing Error". Less likely I suspect.
I would look at updating your motherboard BIOS.
I would test XP on the same system. The specification updates do refer to specific Vista (and hence probably Win7) issues, but none seemed related.
It would be interesting to remove some load and only run the Network and audio tests to see if the problem still occurs. Also I don't know if both of your NICs are on the motherboard and you get errors on both NICs.
Originally Posted by Ian (PassMark)
Thanks for your reply.
If I was only seeing the problem on a particular motherboard, it wouldn't bother me so much. BUT every motherboard I've tested so far (with different chipsets) exhibits the failure. I would think this would eliminate errata on particular chipsets and the likelihood of it being a BIOS problem.
None of the three motherboards I've tested has this anomaly when running Windows XP. They all pass testing. One of the motherboards uses the Q45 chipset and ICH10 to which neither of those specification updates would apply - it is also using core 2 quad CPU which I would think would eliminate the CPU being overloaded. All of these motherboards have dual Intel GB PCI express NICs built into the MB and the packet loss occurs on both.
I've tried setting the duty cycle to 25% for all tests and the problem persists. I've also tried testing just one LAN port, and it still fails. I'll do some more experiments by removing tests other than audio and LAN, and see what happens. Not that that would be a solution, however...
What is the strangest part as I mentioned before: remove the audio test and it passes, BUT just having an MP3 file file locked in Windows media player BUT NOT PLAYING - just paused; and it fails. Weird.
Last edited by Comark Corp; 12-30-2009 at 03:37 PM.
Originally Posted by Comark Corp
I found that if I remove the CPU and 3D tests, the test will then pass. Since that's really not a solution for us, I did some more testing and found that if I use the Windows 7 troubleshooting utility, and run the diagnostics in Windows XP service pack 3 compatibility mode, all the tests pass! There are still some lost packets, but they are well under the .1% loss that I have set in the config.
It is hard to say, but we had an interesting problem a few weeks back, where CPU SIMD errors were reported only when the audio test was running. This occurred under XP and not Vista (unknown in Win7). In this case it turned out that the XP audio device driver was changing some SIMD 'compatability' features at the kernal level to overcome a 'limitation' of the XP driver. This effected some SIMD operations if being processed by the CPU at the same time as certain audio driver operations. The audio vendor had removed this limitation in the Vista driver.
While this does not answer your specific problem, I do wonder if it could be something related (but not the same), in terms of different drivers setting different CPU settings, but another operation occurring at the same time on the CPU that requires different setting - i.e. some sort of driver incompatability ('limitation'). The CPU and 3D tests are the 2 tests exercising SIMD. I don't know how this would impact the network test (but could probably come up some theories).
To fully solve the problem, I think you would need to identify the relevant common drivers between all your platforms and then contact the drivers vendors.
Edit 1: It could also be a Win7 operating system issue.
Last edited by Ian (PassMark); 01-03-2010 at 10:44 PM.
The only common drivers seem to be the Intel NIC and graphics drivers. I disabled the onboard Intel NICs and instead added 2 Realtek NIC boards. Same failure.
Originally Posted by Ian (PassMark)
I then disabled the on-board Intel graphics controller and installed a Nvidia card and driver. Same failure.
I agree that it could be a Win7 problem, but I'd rest easier if other people were seeing this bug. Dumb question perhaps, but are you saying that you've tested similar configurations and not seen anything?
I've emailed my test.bitcfg as I do not see a way to attach a file. Could you see if this works for you after changing the network settings to reflect your own servers?
I re-tested on 2 different Windows 7 systems with your configuration(*) and could not reproduce the problem you reported.
(*) Whilst it may not be relevant, our hardware is newer hardware and does not have a Parallel or Serial port, so I excluded these tests. I don't believe this would have impacted the results.
Out of interest, is your hardware more than a couple of years old?
Originally Posted by Ian (PassMark)
The three motherboards I have tried this on so far are:
Being in the industrial field, many of our customers require serial and parallel ports as well as long-life hardware. Also, the first one is using the Q45 chipset and is quite new.
Just in case, I removed the serial and parallel port tests, but the failure persists.
I don't know what the problem is.
I guess you have tried anything I would suggest, but maybe you could try different destination addresses, a longer timeout, different cables, removing/changing any intermediate networking gear, updating audio and network device drivers, getting the latest Windows patches, testing the Network ports one at a time (just to see if you get the same result), increasing the ratio value (if you think it may be appropriate) ...