Burnintest Serial Test in different operating system

[harrycc]

Hello,

We conducted the serial test of Burnintest in the following conditions under Windows and Linux. However, we got different results and have a few questions about it.

Test 1:
Operating system: Windows 10 Pro 64bit
Burnintest version: Burn in Test V 9.1 (1001)
Burnintest test item: Serial test
Serial Port #: 1
Test Result: Run for 16 hours pass without errors

Test 2:
Operating system: CentOS 7.6 (1810) 64bit
Burnintest version: Linux Burn in Test V 4.0 (1003) cmdline version
Burnintest test item: Serial test
Serial Port #: 1
Test Result: Fail and error occurred "Corruption. Data received didn't match data sent"

All other conditions are the same in these two tests, including system, RAM, hard disk, COM port number, etc.

Q1. Since the system and other configuration is the same except for the OS, what is the possible cause of the different results in different OS??
Q2. What is the difference of the serial test algorithm between Windows and Linux burnintest??

Please help answer the questions, thank you!

Best,
Harry

[David (PassMark)]

Serial ports were never meant to be error free. If you run the test long enough a few errors are to be expected.

Pretty much all usage of serial ports used protocols to detect & correct errors (Kermit, XMODEM, YMODEM, FTP, etc..) .

A large number of errors in a short time (compared to the amount of data transferred) would indicate a problem however.

[harrycc]

We conducted the test only using simple loopback and with Tx/Rx only. Also, the transfer rate was set to be 115200. Currently, when running in Linux burnintest, an error would occur every 2-4 minutes in average. However, with the exact same system settings, no error would occur in Windows burnintest. That is why we would like to know the difference of the serial test algorithm between Windows and Linux burnintest. Please help answer the question, thanks!

[David (PassMark)]

We don't support home made loop back plugs.

Can you make one to our specs (or buy one of ours) and see how it goes
https://www.passmark.com/products/lo...ifications.php

(there are certain test options that need more than Tx/Rx connected)

[harrycc]

We simply use a common jumper to short Tx and Rx pins, since all other pins (except for GND) of the COM port are no connect by design of our system. In addition, we have activate the "DisableRTS" option in the cmdline_config file for Linux burnintest. Under such circumstances, the loopback should work as it does in Windows burnintest. Therefore, my question would still be the serial test algorithm differences between Linux and Windows burnintest. Please help answer this question, thanks!

[harrycc]

Any update on this issue??

[jerry]

Hi David,

Any update on this issue ?? We also encountered the same problem

Test 1:
CPU:intel(R) Xeon(R) Gold 6238T CPU @1.9GHZ X2
MemoryDR4 2666 128GB
Operating system: Windows 2012 R2 64bit
Burnintest version: Burn in Test V 8.1 (1025)
Burnintest test item: Serial test (Baud Rate: 9600)
Serial Port #: 1 & 2 & 3
Test Result: Run for 12 hours pass without errors

Test 2:
CPU:intel(R) Xeon(R) Gold 6238T CPU @1.9GHZ X2
MemoryDR4 2666 128GB
Operating system: CentOS 7.5 64bit
Burnintest version: Linux Burn in Test V 4.0 (1003)
Burnintest test item: Serial test (Baud Rate: 9600)
Serial Port #: 1 & 2 & 3
Test Result: Fail and error occurred "Corruption. Data received didn't match data sent"

All other conditions are the same in these two tests, including system, RAM, hard disk, COM port number, etc.

Q1. Since the system and other configuration is the same except for the OS, what is the possible cause of the different results in different OS ??
Q2. What is the difference of the serial test algorithm between Windows and Linux burnintest ??

Please help answer the questions, thank you!

[David (PassMark)]

There is no update as we aren't looking at the problem.

1) We don't support home made loop back plugs.
2) Serial ports were never meant to be error free. If you run the test long enough a few errors are to be expected. A large number of errors in a short time (compared to the amount of data transferred) would indicate a problem however.

Windows and Linux will use different serial port device drivers, typically supplied by the motherboard vendor.