PassMark and pktgen compatibility？LAN pktgen port stop!

[karry]

Dear PassMark,
When I run PassMark to disk burnIn(15%),my LAN pktgen port can stop or make errors.The attachment display the LAN pktgen status and Linux OS status by console when running PassMark to disk burnin.However,that I run other Disk BurnIn programmer is ok.
I want to know the principles about disk BurnIn in PassMark BurnIn! And there are compatibility problems between PassMark BurnIn and LAN pktgen?
thanks.

PassMark BurnIn Pro version:PassMark BurnIn Test Linux v4.1 build 1002

What I have done...
1.I have changed the OS version to try
2.I have changed the PassMark vesion to try
3.I find that the memory free space can dynamically change.The space can change smaller,this is can refer to attachment picture:'free -m',

[Richard (PassMark)]

We are not made aware of any issues with BurnInTest and pktgen. However, we have not tested pktgen.

The description for the disk test in BurnInTest Linux:

During each test cycle, a file is created and verified on the disk. The size of the file is equal to a certain percentage of the disks capacity and all files are created in the root directory of the drives selected. The default file size is 1.0% of the disk size. For small capacity drives, like floppy disks, there is a minimum file size of 32KB. It is possible to change the default file size percentage from the preferences window. The default setting is to cycle between the patterns. In this case a new pattern will be selected each time the disk is full.

Each test file is filled with a coded number sequence (a pattern) that is used to verify the correct operation of the disk when the file is verified (read). Files are created in the free space on the disk until the disk is 94% full. When the disk has reached this limit, all the test files are deleted and the test starts again. A limit of 94% is used to ensure that some space is kept for use by other applications (including the swap files).

Note: We no longer support older versions of BurnInTest Linux and recommend using the latest release when possible.

[karry]

Thank you for your response to the principles.Could you test pktgen now?I really confused about this issue that PassMark BunrnIn pro (disk) leads to LAN pktgen port errors.

[David (PassMark)]

I had a look in the source code of pktgen for you.

The error,
"couldn't allocate SKB in fill_packet"
Can only seem to occur in the case where memory could not the allocated for the SKB (network socket buffer). But there are a few different code paths. There is one for IP4 and another for IP6 and one for single CPU systems and one for multi-CPU systems that have NUMA support. This would be so that the socket memory buffer is allocated in RAM that is connected to the specific CPU that the code is running on.

On older 32bit systems we saw out of memory errors due to fragmentation, even when there was lots of available RAM. Are you running 32bit or 64bit O/S? And is pktgen also 64bit?

It is also possible it is a bug in pktgen, that results in it requesting an unexpectedly large buffer. It is outside the scope of our free support to debug other peoples' open source tools however. You might want to contact the author for support.

BTW: BurnInTest has a network test built in.

[karry]

My OS and pktgen are 64bit. OS:UOS Server 20 1050a(4.19.0-91.82.141.6)
The error is on memory.In fact,there is no error when runnning LAN pktgen port alone.And I run PassMark BurnIn Pro to Disk rather than memory to lead to the error.How much memory resources will be occupied if I run PassMark BurnIn Pro to disk?

[David (PassMark)]

We've got no experience with UOS Server 20.

Disk test should only use a small amount of RAM. Haven't exactly measured it, but maybe around 20MB (+the space occupied by the executable itself). Exact amount would depend on the settings used and how many disks are being tested at the same time however.

If it was a critical issue for you we could offer some paid consulting service to test pktgen + BIT and debug it (i.e. get to the root cause and fix the bug in pktgen if that was the issue).