Announcement

Collapse
No announcement yet.

How to run burn-in Tests (ARM version)?

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

  • How to run burn-in Tests (ARM version)?

    Click image for larger version

Name:	Passmark v5.0.png
Views:	326
Size:	92.5 KB
ID:	53831I downloaded passmark from the website to support ARM platform v5.0 version, but after decompressing, I found no program (burnin.sh) was executed. May I ask how to run the program?

  • #2
    From the FAQ, Q. How do I launch BurnInTest Linux from the command line?

    There are two versions of BurnInTest in the "arm" folder a version for 32-bit systems called bit_cmd_line_arm and a version for 64-bit systems called bit_cmd_line_aarch64, type ./bit_cmd_line_arm or ./bit_cmd__line_aarch64 to launch the software.

    Comment


    • #3
      Thanks for your reply, I have successfully run it. But I have two more questions to ask you:

      First: May I ask if the V5 key of this ARM version needs to be purchased separately? Our company has purchased the V4 version of the key, but I tried the V4 version of the key and it didn't seem to activate the V5 version.

      Second: Can the V5 of ARM only run on text interface? Don't you have to run it in a graphical interface like the X86 version?

      Comment


      • #4
        You would need a V5 license key for BIT V5. If you have a existing V4 license, you would be eligible for upgrade pricing:
        https://www.passmark.com/products/burnintest/price.php

        There is no GUI version of BIT Linux ARM.

        Comment


        • #5
          Hi,
          When I ran Passmark burnin v4.1 b1001​ version to test the serial port loopback, there was always an error in the red box in the following picture, but I used other programs to test the receiving and sending of these three serial ports(Receiving and sending are the same). May I ask what might cause this problem?
          "COM port data set ready" "Com port clear to send"
          Click image for larger version  Name:	burn-in_V4.png Views:	0 Size:	54.5 KB ID:	53911

          Comment


          • #6
            It looks like the flow control isn't working very well and the lines aren't responding correctly when BurnInTest is setting them on/off.
            You can turn off the flow control testing by uncommenting the DisableRTS option in the command line config (or both the DisableRTS and DisableDSR options in version 5).

            Comment


            • #7
              I tried to disable RTS, and all three coms displayed the error "COM Port Data Set Ready".

              At present, our company only purchased the V4 version of Key, so we did not test the V5 version. May I ask if the V5 version can solve this problem?

              Comment


              • #8
                Originally posted by Tim (PassMark) View Post
                It looks like the flow control isn't working very well and the lines aren't responding correctly when BurnInTest is setting them on/off.
                You can turn off the flow control testing by uncommenting the DisableRTS option in the command line config (or both the DisableRTS and DisableDSR options in version 5).
                Click image for larger version

Name:	Capture2.png
Views:	312
Size:	8.4 KB
ID:	53919
                Click image for larger version

Name:	Capture1.png
Views:	260
Size:	33.7 KB
ID:	53920
                Click image for larger version

Name:	Capture3.png
Views:	255
Size:	52.0 KB
ID:	53921
                I tried to use version V5 according to the above Settings, but the error was still displayed when testing the COM Loopback, as shown in the red box in the picture above. May I ask how to solve it?

                Comment


                • #9
                  Try adding DisableDSR as well (an example wasn't added to the config file previously).

                  Comment


                  • #10
                    Originally posted by Tim (PassMark) View Post
                    Try adding DisableDSR as well (an example wasn't added to the config file previously).
                    Thanks for your guidance, it seems that this way is very effective! I modified it in this way and tested the COM Loopback for 5 minutes without any error. Does this method work with version V4?
                    Click image for larger version

Name:	Capture7.jpg
Views:	259
Size:	43.5 KB
ID:	53926
                    Click image for larger version

Name:	Capture5.jpg
Views:	270
Size:	80.4 KB
ID:	53925

                    Comment


                    • #11
                      It's possible as the change was made before the ARM v4 release, however they were using separate code bases / compiling systems at the time so it may not have made into the V4 ARM build (you'd have to try it and see).

                      Comment


                      • #12
                        When I was testing the network, although the program showed that it was being tested, the data LED of the network port did not blink when I observed it (the LED would keep blinking when there was data transmission in the normal ping process).
                        What is the reason? Isn't there any data being transferred over the network port at this time?
                        Click image for larger version

Name:	Capture3.jpg
Views:	257
Size:	38.3 KB
ID:	53938
                        Click image for larger version

Name:	LAN LED.jpg
Views:	254
Size:	51.8 KB
ID:	53939
                        I set the following Settings in the configuration file: (Short connect two network ports with a network cable)

                        <Network>
                        IP 192.168.1.1
                        IP 192.168.1.2

                        BadPacketRatio 2
                        TimeOut 2000
                        #TestAllNICs
                        </Network>​

                        Comment


                        • #13
                          It sounds like you're trying to use two local network addresses, so likely the system is using the local loopback path.

                          Also as you're not using the "TestAllNICs" option then the network addresses aren't bound to a local network card, they are handled however the system determines (which in this case seems likely to be the local loopback)

                          Ideally it's best to use another system as the destination, but this setup should work if you uncomment the "TestAllNICs" and the network addresses are entered in the opposite order that BurnInTest is detecting the cards (so the destination address for card 1 is card 2 and vice versa, this can take some experimentation to get right).

                          Comment


                          • #14
                            Originally posted by Tim (PassMark) View Post
                            It sounds like you're trying to use two local network addresses, so likely the system is using the local loopback path.

                            Also as you're not using the "TestAllNICs" option then the network addresses aren't bound to a local network card, they are handled however the system determines (which in this case seems likely to be the local loopback)

                            Ideally it's best to use another system as the destination, but this setup should work if you uncomment the "TestAllNICs" and the network addresses are entered in the opposite order that BurnInTest is detecting the cards (so the destination address for card 1 is card 2 and vice versa, this can take some experimentation to get right).
                            I'm sorry that I may have a mistake in understanding this. I connected the two local network ports together through the network cable loopback for test, and found that no data passed through the network port at all.

                            According to your suggestion, if you want the network port to have data passing through, it is better to use the test machine to couplet the network port of another machine, right?
                            Is it linked like the picture below?
                            Click image for larger version

Name:	link.jpg
Views:	241
Size:	21.7 KB
ID:	53959

                            If so, is the IP address of the other party's system network port set in the configuration file (instead of the local one)? I tried to turn on the "TestAllNICs" option and found that after the IP address of the other party was set in the configuration file, the data led of the network port began to blink after the test began.
                            In addition, how much BadPacketRatio is recommended for network testing? For example, is there any basis for setting 2%? thanks
                            ​<Network>
                            IP 192.168.1.20
                            IP 192.168.2.2

                            BadPacketRatio 2
                            TimeOut 2000
                            TestAllNICs
                            </Network>​
                            Click image for larger version

Name:	result.png
Views:	247
Size:	211.3 KB
ID:	53960
                            Attached Files

                            Comment


                            • #15
                              Having the network cards directly connected and on separate subnet may complicate things as you will need to have the remote IPs entered in the config file in the right order for Burnintest to use with the cards in the order it sees them (BunInTest won't know to 192.168.1.1 to 192.168.1.2 automatically, it only takes the next IP address in the config file and will bind the next network card to that address), but it should work once you get the order correct.

                              how much BadPacketRatio is recommended for network testing? For example, is there any basis for setting 2%?​
                              There isn't any basis, it's more what you are comfortable accepting as packet loss. With the standard network test using ICMP echo (ping) these packets can suffer from packet loss (particularly at higher rates or with any switch hardware in between that can drop them as unnecessary traffic) so using a ratio % rather than every bad packet generating an error makes more sense.

                              Comment

                              Working...
                              X