BurnInTest 7.1: Timeout Error for Network test

[Ng Ee Yeng]

Hi Passmark,

We stumbled upon an issue while using BurnInTest 7.1 build 1017. Basically, we had run a 50% network on our controller (that we designed) with a laptop as an external host overnight and get 1-3 timeout error. If we run the same test with another identical controller as an external host, it is able to run for days without any timeout detected.

We would like to know if the timeout is more likely a hardware issue or a software issue. Is it possible the issue is caused by how the laptop prioritize their workload? Thus, is it a way to force the laptop to prioritize the task for replying to pings (ICMP_ECHO)?

Here is the details of the setup:

Laptop- External host
static ipV4 address: 192.168.1.2
Firewall: Off
Notes:
This windows 7 laptop is for regular use, thus have a few basic software (e.g. antivirus) that will run on startup. There is no extra stress test running on this unit.

Controller
OS: Windows 7
Static ipV4 address: 192.168.1.1
Firewall: Off
BurnInTest settings:
50% Network
All available physical Ethernet ports
1: 192.168.1.2
Timeout: 4s
Bad packet generates error

Feel free to ask for more info if the ones I had provided is not sufficient. Thanks!

[Ng Ee Yeng]

Just to clarify, the cable is a cat 5. Not crossover.

[David (PassMark)]

Version V7.1.1017 is a bit old now.
Can you try the current release, Version 8.1 build 1015.

It is hard to know who to blame. Could be the laptop hardware, its device driver, cabling, or a loading issue as you suggested. Windows machines do tend to run a lot of background tasks so it isn't too hard to imagine that the machine was busy for a few seconds at some point during a 24 hour period.

[Ng Ee Yeng]

Update:

I had the laptop cleaned (no extra programs) and run the same test on BurnInTest V8.1 build 1015 overnight. There is still a timeout found.

On a side note, I also had done the test between 2 laptops, it doesn't have any problem with timeout for running overnight.

Do you have any suggestion on debugging/root-cause this?

[David (PassMark)]

A couple of lost packets during a 24h load test is very minor. TCP/IP deals with it (in fact TCP/IP expects errors, as it is used as a flow control mechanism).

If you really wanted to debug it you could take a WireShark trace, but it would be a massive log file for 24 hours. Then you could at least determine if the packet failed to be sent, or failed to be responded to, or was responded to, but slowly, or if there was physical errors, etc..

[Ng Ee Yeng]

Thanks for the suggestion for Wireshark. Would update here if I find anything interesting.