Timeout waiting for packet

[wcnackers]

I am testing a computer board with an Intel Q35 MCH and an ICH9D0 ICH. The board uses a dual 82571EB ethernet controller and a single 82562G1 ethernet controller.

If I run a standard network test, put check mark next to 3 ethernet ports, set the addresses to 127.0.0.1 (so all that is being done is internal loopbacks) and the set the duty cycle to 100%, I am getting Timeout waiting for packet errors. If is se the duty cycle to 50%, the errors go away.

I would think that simply running an internal loopback on these would not cause timeout errors. If I run Windows ping, the response back is less than 1ms.

It is not the board...I have tried 3 and all other ethernet tests pass. It is not the OS, I get the same results with 32 bit or 64 bit OSs.

Anyone have any ideas???

[passmark]

Sounds like the machine is just overloaded. I don't think it is a hardware fault. Note that using the internal loopback port 127.0.0.1 isn't a very good hardware test. you should use an external machine and external IP address for a better test

[wcnackers]

I found out that I can set the duty cycle to 99% and then the network tests don't fail??? Why would that be???

[wcnackers]

I found out that I can set the duty cycle to 99% and then the network tests don't fail??? Why would that be???

Please...anyone have any idea why this would happen. I get "timeout waiting for packet" errors if I set the network duty cycle to 100% but they go away if I set it down one notch to 99%. I need to find an answer for a customer that I did some testing for.

Any input will be greatly appreciated!

[passmark]

There is a significant difference in load between 99% and 100%.

With 100% there is no delay at all in the test cycle. With 99% there is a few milliseconds between each packet. This few milliseconds makes s big difference in terms of load.

In other words the difference in load between 99% and 100% is greater than the difference in load between 98% and 99%. The load progression isn't totally linear with the duty cycle setting unfortunately.

Timeouts under very heavy load should not be considered as an error. To some degree a timeout under heavy load is expected behaviour.

You can also get similar behaviour if the remote machine you are testing against is slow or busy, or if the network is under load from other traffic.

[wayneh]

Hi Passmark,

I am testing two platforms, one is using Realtek 8103EL ethernet controller, the other one is using Intel 82578. Testing OS is Windows 7.

I also get the same error, timeout waiting for packet.This error occurs when performing Burn-In network test with default setting option#1. (“Every bad packet generates an error”)

Failure will go away if changing setting to option#2. (“High bad packet ratio generates an error” with 2.0%)

The symptom occurs with Burn-in v6.0 build 1018 or latest build 1019.

The LAN test passed if Mapping the network drive for testing.
Could it be a problem with the Windows Drivers for the Network or could it be the Burn in Test?

[Ian (PassMark)]

If you don't get errors with the "High bad packet ratio generates an error” (with 2.0%) setting, then this means that your total packet errors (including timeouts) is less than 2%.

The main reasons for Network timeouts are outlined in David's earlier post.