Intel G3900TE platform On Windows 10 Timed Out Message in 3D graphics Test

[Jerry_TC_Lee]

Hi,

We conducted Burn In Test V9.0 on G3900TE boards and have the situation: Timed Out Error in 3D graphics Test.

Here's our workload settings:





This workload settings test PASS and no error occur (CPU loading 95%, others are all set to 100%).
But if we change the CPU loading during 96%~100%, the 3D graphics will show error about Timed Out message in short time period.
We do some experiment as below:

1.The time out error didn't occur when we run 3D graphics test ONLY. (3D graphics workload 100%)
2.We also use Burn In Test V7.1 and all items's workload are set to 100% in the same system, but Burn In Test V7.1 show PASS without any error.
3.We use the Burn In Test 9.0 and change 3D graphics setting from DirectX 12 to DirectX 9 . then all items test result show PASS,no error. (even we set the CPU workload as 100%, the test result still PASS)

According to above the test result, we suspect the Burn In Test V9.0 program's 3DDirectX 12 loading too much? (or resource request too much?) cause the CPU loading can not set to 100% to test? Is it mean we can not loading CPU 100% to test on 3D graphics with DirectX 12 to test at same time? Or could you explain this 3D test time out error phenomenon which won't occur in older version BIT program? (ex. BIT V7.1)

Hope to receive feedback soon. Many thanks.

[David (PassMark)]

It looks like the video card driver may have crashed or stopped responding correctly at this point, generally an issue like this there where there are no problems until after several hours are caused by small memory leaks in device drivers. It would be a good idea to check if there is an updated driver available for the video card.

There are also excellent Microsoft tools available for tracking down memory leaks. Start with Windows Task manager, then move on to Sysinternal's RAMMap. Then once it is determined that it is a kernel driver leaking RAM move on to PoolMon from the Windows DDK. Then use the tags displayed in PoolMon to track down the particular driver at fault.

But it also doesn't make sense to run all tests at 100% duty cycle.
See the FAQ
https://www.passmark.com/support/bur...php#duty_cycle

Is same issues as this post.
https://www.passmark.com/forum/burni...r-verification

[Jerry_TC_Lee]

Dear Sir:



Thanks for your help.

However, we still have question about DX12 and DX9 setting difference in BIT 9.0 3D graphics test.



Could you explain the different test result between DirectX 12 and DirectX 9 for 3D graphics item?

We use the Burn In Test 9.0 and change 3D graphics setting from DirectX 12 to DirectX 9, then all items test result show PASS with all item's workload at 100% (include CPU workload).

When change the 3D graphics setting to DirectX 12, then 3D graphics will occur time out error, unless we decrease CPU workload under 95%.

Please have your comment, thanks.

[David (PassMark)]

The DirectX12 test uses Microsoft's DirectX12 programming interface. This is only available in Win10.
The DirectX9 test uses Microsoft's DirectX9 programming interface, which has been available since 2002 for Windows XP.

There was a lot of new features added in DX10,11 & 12. See,
https://en.wikipedia.org/wiki/DirectX

The DX12 test is more complex, uses more RAM, has larger textures and places more load on the video card.

We have seen cases of where the hardware being tested is very low end, and the user selected very high load configuration. So the 3D test takes many minutes to launch. So the test times out before the test even starts. As stated above, it doesn't make sense to run all tests at 100% duty cycle at the same time, especially on low end hardware.

So just to be clear, there are likely too different error scenarios that lead to the same timeout error.
1) RAM leaks, leading to a low memory crash situation some hours into the testing.
2) An error within 5min of starting the tests, where the low end hardware is massively overloaded.


Edit March 2020: We had one instance of this timeout error being linked to this event in the Windows Event log for a machine with Intel Graphics.
Information, Event ID: 0x00000013, Source: I
Description: Check the remaining resource budget. Module exceeds resource budget, failed to AllocateFwCps, STATUS = 3221225626
(This is an event from an external source, presumably the video card device driver, but we couldn't find any additional information. It implies a low RAM situation however).

[David (PassMark)]

There is some confusion between 100% duty cycle and 100% CPU load. So I'll try and explain it a bit more.

The duty cycle setting in BurnInTest determines how quickly the various tests in BurnInTest run. So it might seem like a good idea to run all the tests at the same time and wind up all the tests to 100% duty cycle. It isn't.

Imagine you have one application running on a computer that uses 100% of the CPU time. Adding a second instance of the same application (which could also potentially use 100% of the CPU time as well) doesn't increase the load on the machine. You can't have 200% CPU load. It's impossible. So by running more tasks, you aren't increasing the load, instead the operating system puts more and more tasks into a sleep state as part of preemptive multitasking. Eventually none of the tasks get any work done as the execution time per task becomes less and less as you add more tasks. Most of the tasks are asleep for most of the time. It is the same with BurnInTest. You can have near 100% hardware load with duty cycle settings in BurnInTest of less than 100%.

So if 100% duty cycle for all tests isn't the best, then what is?
The best duty cycle setting to achieve 100% load your hardware depends on your hardware and your testing goals. See the FAQ
https://www.passmark.com/support/bur...php#duty_cycle

But as an example it might be something like,
Disk 100% duty cycle
3D 100% duty cycle
RAM 80% duty cycle
CPU 80% duty cycle (as the RAM, disk and 3D tests also use the CPU, the actual CPU load might still be 100%, depending on your hardware)