Re: dbus message queue latency time is not constant for same data payload

On Tuesday, 23 May 2023 15:39:53 PDT Lawrence D'Oliveiro wrote:
> On Tue, 23 May 2023 09:56:39 +0530, deepak jewargi wrote:
> > Latency time between transmitting from one process and receiving at
> > another process is not constant for the same payload message.
> 
> My guess is, don’t expect D-Bus to operate as a channel for
> high-performance IPC.

Agreed, D-Bus isn't designed for low-latency either. The daemon is single-
threaded by design, does a lot of checking, and will thus have a limit on how 
fast it can relay messages. It's neither designed for real-time: the daemon 
makes absolutely no promise on how quickly it will deliver messages. D-Bus is 
designed with timeouts measured in seconds.

That said, it would be interesting to know where the bottleneck is.

Deepak, there are three processes involved here: the sender, the D-Bus daemon, 
and the receiver. Can you find out which one of them is the one causing 
trouble? Please benchmark your own code to ensure that you're still sending 
the messages on time. The problem may be in your application that it gets slow 
over time for a reason unrelated to D-Bus.

Any conclusion other than that the application is spending time waiting for 
the D-Bus socket to become writable is a problem in the application. If that's 
the case, just run your application in a benchmark tool and find out what it is 
doing.

Similarly, the receiver application should read the messages as fast as 
possible, with no delay. Since you're benchmarking the ability to send 
messages and receive them on time, there should be zero workload after 
receiving the message. Just drop it on the floor.

Once you've confirmed that the problem is D-Bus daemon, either in receiving the 
messages fast enough or relaying them quickly, the question is why. Is it 
consuming 100% CPU? Is it increasing in memory allocation?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering