[Bug 772841] udpsrc: high CPU usage at high packet rate

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=772841

--- Comment #27 from Petr Kulhavy <brain at jikos.cz> ---
(In reply to Tim-Philipp Müller from comment #24)
> Not sure I follow. The bug summary talks about a high packet rate. If that's
> the case, you will likely be able to retrieve multiple packets with a single
> system call, which improves throughput, latency and cpu usage. And in no
> case should you be worse off than with the current implementation.

Tim, the use case I'm talking about is for example AES67 with 1k
packets/second, 1ms each. To reduce the latency as much as possible ideally you
would receive every single packet as fast as possible and send it down the pipe
for further processing individually. So things like interrupt coalescence or
receiving multiple packets are not desired in the first place since they
increase the latency. The primary goal is then not to gather packets but to
make the processing lightweight so it can sustain the high packet rate. Now
that is the theory. The other thing is how much realtime Linux able to provide,
how much overhead are the syscalls going to create and eventually how many
packets per second is the system able to process with the given MIPS. So when
it turns out the system is not responsive enough to handle that packet rate
things like recvmmsg would actually help to save the situation (where packets
cumulated). But ideally it should never come to that point. Does it make more
sense now?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.