USB3.0 Loopback: physical layer error in summary & can't find record in logs

[helloeasyji]

Hi Passmark Team,
We are currently using a tripplite (USB-C to 4 USB 3.0 A ) hub to connect the PC and 2ea passmark 3.0 loopback hardware.
One passmark was running at 5Gb/s while another running at 480Mb/s.
We are opening 2ea USB 3.0 Stand alone test application to run the loopback at the same time.
After 1hr loopback testing, we can see there are 25ea physical layers error in the USB 3.0 test results area ( for the 5Gb/s hardware), but when we save the log and try to search any detailed error, we can't see any record ( 8b/10b or any CRC), and we also can't see any error of physical layer occurs at any specified loopback cycle.

The software setting is posted as the attachment.

Thank you for the outstanding help.
Ping

[David (PassMark)]

The USB3Test tool stores the log in RAM and only allocates enough RAM to hold 300000 log lines. So maybe you exceeded this limit, by the time you saved the log to disk?

[helloeasyji]

The USB3Test tool stores the log in RAM and only allocates enough RAM to hold 300000 log lines. So maybe you exceeded this limit, by the time you saved the log to disk?

Thanks, David, it look like even through the USB3 loopback takes 1hrs, the log only saves the last 20minutes records ( which is around 300K lines)
Is there any potential solution we can get more RAM to store more logs?

[David (PassMark)]

Quick fix for debugging would be to save the log each 20min.

If we bumped it to 1M log lines we might end up using Gigabytes of RAM, which has it's own problems, on low end systems.
Writing the log to disk on the fly would be technically possible, but slow disks (e.g. USB2 flash drives) might cause problems by being too slow.
Maybe a option to stop testing after an error might make sense?

[helloeasyji]

Quick fix for debugging would be to save the log each 20min.

If we bumped it to 1M log lines we might end up using Gigabytes of RAM, which has it's own problems, on low end systems.
Writing the log to disk on the fly would be technically possible, but slow disks (e.g. USB2 flash drives) might cause problems by being too slow.
Maybe a option to stop testing after an error might make sense?

Make sense, thank you, David.