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.
>=20
> My guess is, don=E2=80=99t 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 h=
ow=20
fast it can relay messages. It's neither designed for real-time: the daemon=
=20
makes absolutely no promise on how quickly it will deliver messages. D-Bus =
is=20
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 daem=
on,=20
and the receiver. Can you find out which one of them is the one causing=20
trouble? Please benchmark your own code to ensure that you're still sending=
=20
the messages on time. The problem may be in your application that it gets s=
low=20
over time for a reason unrelated to D-Bus.

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

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

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

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