[jitsi-dev] Desktop sharing drives CPU usage and latency sky high


#1

Today I tested desktop sharing on my local network between two machines:

1. Acer Travel Mate 5720 (some Intel 3,6GHz) - Intel onboard 1280x800
2. AMD (as described in my other posting today on CPU usage) ATI graphic 1920x1080
3. Local LAN in between (wireless involved)

Though image quality is excellent - latency on the shared desktop is about 3-5 sec, rendering it completely useless - even for myself who knows that I have to wait.(clicking and typing in the other direction seems to be faster - so it gets out of sync with the images)

The CPU usage of the machine serving the screen shoots up into the 90ies.(both ways) Latency for sound coming from the AMD machine goes up to 10sec while the other way around there is hardly any sound latency. This is even the case when the Intel machine serves the screen and the AMD is only watching.

Turning off Desktop sharing lets the situation stay the same: 71% CPU - latency a couple of seconds - for now audio only.

One observation: the AMD CPU steps up its speed from 800.000 to 1900.000 (accompanied by surging fan speed) - and stays that way for many minutes. I'm not sure what this means for interpreting the top-command: is 71% on 1900.000 around twice as much CPU cycles as 71% on 800.000??

I've tested for about 25 minutes.

Is there any help with that? I'm not using neither outdated nor toy- hardware. (actually I upgraded my hardware to run SC properly)

How could I analyze this further?

Greetings from Berlin
Conrad


#2

Hi Conrad,

Sorry for late reply.

Today I tested desktop sharing on my local network between two machines:

1. Acer Travel Mate 5720 (some Intel 3,6GHz) - Intel onboard 1280x800
2. AMD (as described in my other posting today on CPU usage) ATI graphic 1920x1080
3. Local LAN in between (wireless involved)

Though image quality is excellent - latency on the shared desktop is about 3-5 sec, rendering it completely useless - even for myself who knows that I have to wait.(clicking and typing in the other direction seems to be faster - so it gets out of sync with the images)

Is the shared desktop the AMD ones with ATI graphics ?

The CPU usage of the machine serving the screen shoots up into the 90ies.(both ways) Latency for sound coming from the AMD machine goes up to 10sec while the other way around there is hardly any sound latency. This is even the case when the Intel machine serves the screen and the AMD is only watching.

I remember that Werner has also some problem with desktop streaming last year with ATI graphics. He gave some explanations, http://markmail.org/message/5vm3in5rjjp2pc7j#query:+page:1+mid:x45muxzudpsf4xur+state:results .

Turning off Desktop sharing lets the situation stay the same: 71% CPU - latency a couple of seconds - for now audio only.

What audio codec do you use ?

Is it the same 71% when you begin an audio call only ?

One observation: the AMD CPU steps up its speed from 800.000 to 1900.000 (accompanied by surging fan speed) - and stays that way for many minutes. I'm not sure what this means for interpreting the top-command: is 71% on 1900.000 around twice as much CPU cycles as 71% on 800.000??

I don't know, maybe disable CPU frequency changes and test again.

I've tested for about 25 minutes.

Is there any help with that? I'm not using neither outdated nor toy- hardware. (actually I upgraded my hardware to run SC properly)

I will try to investigate more on this problem when I will have time.

···

On 05/02/2011 17:38, Conrad Beckert wrote:

--
Seb

How could I analyze this further?

Greetings from Berlin
Conrad


#3

Hallo Seb,

Sorry for late reply.

Never mind :wink:

I remember that Werner has also some problem with desktop streaming last
year with ATI graphics. He gave some explanations,
http://markmail.org/message/5vm3in5rjjp2pc7j#query:+page:1+mid:x45muxzudpsf4xur+state:results

He answered my posting with that information. I didn't test vnc on that machine though yet. I'll do so this weekend when I'm there.

Is it the same 71% when you begin an audio call only ?

No it isn't - it's much lower. It goes up under some circumstances (e.g. video or in this case desktop sharing - and stays there.

If this happenes - usually audio latency goes up too.

I had to get rid of pulse audio on the machine, we're talking about because latency was completely nuts. Now latency is a bit better but CPU usage still goes up sometimes (but not always) And then, latency is as high as with pulse audio running.

I don't know, maybe disable CPU frequency changes and test again.

What would be the result? The CPU steps up because there is a need for processing power - and top shows where it comes from: java.

I haven't been able to analyze this from the outside. But is it possible that we get into some concurrency of parallel instances of the same threads e.g. for fetching the audio signal that mount up if they get disturbed by something and run longer than expected- like by the desktop sharing desparately trying to fetch data from the video adapter?

I will try to investigate more on this problem when I will have time.

Thank you for that. This my sole issue I still have with Jitsi at the moment. Features and stability are excellent.

PS:I have a echo test to my Asterisk open right now for a couple of minutes. Video is on. CPU is at 76%, stable.I started with audio only and CPU was around 60%. Latency is still OK, echo canceller works. Before restarting everything was nuts (audio only in the 80ies,90ies, latency beyond echo cancelling)

This machine here has pulse audio running - but that can't be the primary cause since the other machine (AMD,the one with the desktop streaming) behaves similarily.

Regards
Conrad


#4

Hallo Seb,

... a recent test revealed some interessting information: I had the opportunity to do a throughout test of the latest Jitsi version on an XMPP connection.

1.
I managed to test Desktop sharing, the other side has Ubuntu 10.10 - like I have - and a ATI Radeon 34xx. video adapter on a Notebook (so probably not such a big screen as I have at home)

Desktop streaming was fine - relatively fluent, no delays, the latency didn't went up. Strangely, after some 5 minutes, my video of the remote screen image froze, while I still was able to click around with my mouse on the remote side.

I had this before- with the same partner but on another installation on Windows.

So what's going on here? Voice is fine - so it can't be NAT. Is it perhaps my site which stops recieving the screen updates?

2.
As mentioned: The test was fine. No delays, no latency, no echo, CPU usage in the 70ies, pulse audio active (!). The machine is an AMD dual core mobile processor with about 2GHz, 4GB of RAM, - lightly less than my new machine. Strange - the error is hiding somewhere. I suspect it even runs on OpenJDK.

Hope that helps.

Greetings
Conrad

-------- Original-Nachricht --------

···

Datum: Wed, 16 Feb 2011 20:23:22 +0100
Von: "Conrad Beckert" <conrad_videokonferenz@gmx.de>
An: dev@jitsi.java.net
Betreff: [jitsi-dev] Re: Desktop sharing drives CPU usage and latency sky high

Hallo Seb,

> Sorry for late reply.
Never mind :wink:

> I remember that Werner has also some problem with desktop streaming last
> year with ATI graphics. He gave some explanations,
>
http://markmail.org/message/5vm3in5rjjp2pc7j#query:+page:1+mid:x45muxzudpsf4xur+state:results

He answered my posting with that information. I didn't test vnc on that
machine though yet. I'll do so this weekend when I'm there.

> Is it the same 71% when you begin an audio call only ?
No it isn't - it's much lower. It goes up under some circumstances (e.g.
video or in this case desktop sharing - and stays there.

If this happenes - usually audio latency goes up too.

I had to get rid of pulse audio on the machine, we're talking about
because latency was completely nuts. Now latency is a bit better but CPU usage
still goes up sometimes (but not always) And then, latency is as high as with
pulse audio running.

> I don't know, maybe disable CPU frequency changes and test again.
What would be the result? The CPU steps up because there is a need for
processing power - and top shows where it comes from: java.

I haven't been able to analyze this from the outside. But is it possible
that we get into some concurrency of parallel instances of the same threads
e.g. for fetching the audio signal that mount up if they get disturbed by
something and run longer than expected- like by the desktop sharing
desparately trying to fetch data from the video adapter?

> I will try to investigate more on this problem when I will have time.
Thank you for that. This my sole issue I still have with Jitsi at the
moment. Features and stability are excellent.

PS:I have a echo test to my Asterisk open right now for a couple of
minutes. Video is on. CPU is at 76%, stable.I started with audio only and CPU was
around 60%. Latency is still OK, echo canceller works. Before restarting
everything was nuts (audio only in the 80ies,90ies, latency beyond echo
cancelling)

This machine here has pulse audio running - but that can't be the primary
cause since the other machine (AMD,the one with the desktop streaming)
behaves similarily.

Regards
Conrad