Bug 1377222 - netsniff-ng: drops packets when max CPU is not very high
Summary: netsniff-ng: drops packets when max CPU is not very high
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: netsniff-ng
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Paolo Abeni
QA Contact: xmu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-19 08:56 UTC by xmu
Modified: 2017-09-26 09:51 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-26 09:51:14 UTC
Target Upstream Version:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1360213 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1360213

Comment 1 Paolo Abeni 2017-09-15 16:44:49 UTC 
I'm replicating it on my host using a much longer test period (e.g. -t 1000).

The problem is that with very large captures, we stress a lot the storage and the kernel activity to flush the block device are not accounted to the netsniff-ng process, but to some worker thread.

Increasing the number of netsniff-ng processes decreases the change for this to happen, because introduce more per process 'caching'.

I think this behavior is not a bug, wdyt?
Can you please verify that increasing the iperf run time you can reproduce the issue more frequently even in presence of may netsniff-ng processes?

Thanks,

Paolo
Comment 2 Paolo Abeni 2017-09-21 15:47:46 UTC 
Hi,

This is a notice that I'm going to close this bz as not a bug soon, unless you provide some feedback on the above.

Paolo
Comment 3 xmu 2017-09-22 03:41:19 UTC 
paolo,
sorry, I missed your comment before, since we are in pegas1.0 snapshot4 testing phase, now I have no machines with 10 NIC in my hand. the machines may be available after 1-2 days or more longer.

I don't mind you close the bug status now, if there is still a problem, I'll contact you and reopen it.
Comment 4 xmu 2017-09-26 09:50:08 UTC 
I have tested it again, and I found the CPU can be hit 100%, it's a mistake.
so I think this bug can be closed.
Sorry for the inconvenient
Comment 5 Paolo Abeni 2017-09-26 09:51:14 UTC 
as per comment#4
Note You need to log in before you can comment on or make changes to this bug.