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

[karry]

I 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?

[Richard (PassMark)]

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.

[karry]

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?

[Simon (PassMark)]

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.

[karry]

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"

[Tim (PassMark)]

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).

[karry]

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?

[karry]

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).

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?

[Tim (PassMark)]

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

[karry]

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?

[Tim (PassMark)]

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).

[karry]

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?


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>

[Tim (PassMark)]

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).

[karry]

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?


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>

[Tim (PassMark)]

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.