Announcement

Collapse
No announcement yet.

Shows error "No operations reported in timeout period" on BurnIn after resume from S4

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Shows error "No operations reported in timeout period" on BurnIn after resume from S4

    Hello,

    We tested the following configuration:
    1. Set “Auto Stop After” as “30 minutes”
    2. Tick up “CPU”/”2D Graphics”/”Disks”/”RAM” and set these items as 100(Maximum load)
    3. Select the [GO] button to start.
    4. Perform S4 manually during BurnInTest running
    5. Resume the system from S4
    Then error message "No operations reported in timeout period" shows up on BurnInTest after resuming the system from S4.
    Click image for larger version

Name:	NG.jpg
Views:	1017
Size:	148.0 KB
ID:	53521
    OS: Win11 22H2 22581.1 and Windows 10 build 22593

    Does Passmark have any suggestions? Thank you.

  • #2
    The No Operations reported in Timeout reported by the test means that for at least 8 minutes the test didn't perform any operations. So, it is a warning that the test is not running for a period. This can be caused by the test 'locking' up.

    You are using an older version of the software, V9.1 Build 1004 from March 2020. There have been many changes since then including to the 2D Graphics test,

    https://www.passmark.com/products/bu...st/history.php

    We no longer support older versions of the software as development has moved on to the current release. We'll recommend testing with the current version of the software.

    https://www.passmark.com/products/bu...t/download.php

    If the issue continues, you change the travel level to activity trace 2 in the logging options there should be more formation logged around the time when the error occurs.

    Comment


    • #3
      The No Operations reported in Timeout reported by the test means that for at least 8 minutes the test didn't perform any operations. So, it is a warning that the test is not running for a period. This can be caused by the test 'locking' up.
      >> Why does only the 2D Graphics item show "No operations reported in timeout period"? Other items like CPU, Disk, and Memory don't show this warning message after 8 minutes the test didn't perform any operations.

      Comment


      • #4
        Originally posted by Andy Chen View Post
        Why does only the 2D Graphics item show "No operations reported in timeout period"? Other items like CPU, Disk, and Memory don't show this warning message after 8 minutes the test didn't perform any operations.
        Because the other test didn't stop responding. The 2D Graphics test may have stopped responding because of drivers crash, deadlock, bug in code, etc. Without additional information, we do not know and can only speculate. As mentioned previously, try testing with V10 and if it is still an issue, run BurnInTest with level activity trace 2 and there may be more information in the log files as the reason why.

        Comment


        • #5
          Thank you. We used the current version of the software to verify.
          The result is PASS.

          Comment


          • #6
            Dear Richard,
            Because we can see the 'No operations reported in timeout period' message at 2D/3D/CPU/GPU setting at 100%, and after decreasing the CPU/GPU to 80%, the symptom disappears. We know that the PassMark User Guide mentions that this error can occur during 2D/3D testing when the CPU/GPU is tested at a high duty cycle. My question is, what is the recommended percentage setting for CPU/GPU (?%) tests when 2D/3D is set to 100% for a system without an extra external graphics card? What about 80% or 90% for CPU/GPU?​

            Thanks
            Jack

            Comment


            • #7
              You should be able run the video card at 100% load.
              Really the video card driver should never crash (and a crash is probably what is happening here).

              There is no justification at all for a "no operations" error on the CPU test however.

              ​Maybe, depending on your view of the world, you can excuse a video card driver crash under extreme load.

              Imagine you have a task that uses 100% CPU and 100% GPU time. But then you run the same task again, and again, all at the same time. You can't have 300% CPU load, so instead each task gets 33% of the CPU & GPU time. Each task runs 3 times slower. The CPU / GPU doesn't do any extra work, the actual load is the same, but everything gets way slower.

              Eventually things start to run so slow that you get unexpected software bugs as well, things that the software expected to occur in 0.1seconds are now taking 10seconds. Resources (handles, RAM, etc..) get locked for long periods, you get deadlocks, timeouts, maybe disk RAM swapping, etc.. and eventually something serious enough goes wrong that some software bug crashes the driver.

              So two schools of thought.
              1) The system should remain stable but very slow under extreme load OR
              2) It's OK (and expected) that the machine fails under extreme load. As extreme load doesn't occur very often in the real world.

              What is reasonable is a matter of opinion and depends on the expected use for the machine.​ If you accept that instability is OK under extreme load, then where do you draw the line? Is it also OK to crash under just heavy load? We can't answer this for you. We think 1) is better. No crash, but things get slow. But it is a cost benefit trade off.

              Comment


              • #8
                Dear David,
                Yesterday, I forgot to mention that our machine is a low-performance computer, and all devices including the disk, RAM, network, video, etc., are set to 100%, not just the CPU/GPGPU/2D/3D 100%. When we try to run everything at 100%, you tools popup warned us that lower-end computers might encounter timeout issues. That's why I think setting everything to 100% is unreasonable. Instead, following your tools suggestion, we reduced the CPU/GPGPU load. For lower-end computers, if we set the CPU/GPGPU load to 90% and keep everything else at 100%, it should be more reasonable. What do you think?
                Best Reagrds
                Jack

                Comment


                • #9
                  If you are testing and selling hardware that is unlikely to ever experience extreme load AND the consequences of a crash is low, then maybe you can accept the machine crashing. e.g. gaming hardware.

                  If you testing and selling hardware that might experience extreme load OR the consequences of a crash are fatal, then a crash is probably not acceptable. e.g. medical equipment, flight control systems, etc...

                  Comment


                  • #10
                    Dear David,
                    Thank you for your response. Our machine is just a standard user's computer, capable of playing light games. However, due to the lack of an external graphics card, playing games like Street Fighter can be a little bit challenging. According to Buintest's user manual, if we encounter the issue of "No operations reported in timeout period," we can reduce the load on the CPU/GPGPU while keeping everything else at 100% load. Our current setup aligns with your user manual's recommendations. What do you think? Could you provide some feedback? The testing team hopes to set the system to run at 100% load for a whole day, but there might be one or two machines encountering the "No operations reported in timeout period" issue one time for whole day during 2D or 3D tasks. However, when the CPU/GPGPU load is reduced to 90% or 80%, with everything else set at 100%, running the system for a whole day does not see this issue, do you agree with my point of view?.
                    PS: our burnin tools is the v10.2 last version.
                    thanks
                    Jack

                    Comment


                    • #11
                      Could you provide some feedback?
                      We don't have anything more to provide. The summary of the situation is above.

                      In a perfect world the video card driver wouldn't crash. You need to make a business decision if a crash is acceptable or not.

                      Comment

                      Working...
                      X