[jitsi-dev] Re: Additional Information for: Desktop sharing drives CPU usage and latency sky high


#1

Hallo Seb,

... today I had the opportunity to test again. The machines are the same - call on LAN - no fancy delay stuff in between.

As mentioned - sharing the Intel notebook screen works perfectly well. I can work fluently from the remote side.

The other way around it is still unusable. I observed that the mouse movement is delayed by a couple of seconds. The mouse pointer on the local side is trailing the movements at the remote side. So from there it looks as if nothing happens. Interestingly - entering text from the remote side apperars instantly on both local and remote screens.

Observing the remote screen while changing the content locally shows the changes with a delay of 500msec or so - which is fine.

So - the problem lies into propagating the mouse movements from remote to local which is probably not caused by the ATI card's RAM read cycles.

Hope that helps you to find the issue. Give me a buzz if I can help you further.

Conrad

···

----- Ursprüngliche Nachricht -----
Von: Conrad Beckert
Gesendet: 16.02.11 22:30 Uhr
An: dev@jitsi.java.net
Betreff: [jitsi-dev] Re: Additional Information for: Desktop sharing drives CPU usage and latency sky high

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 R
AM, - 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 sh
aring - 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 >

Bitte antworten an/Please reply to/Por favor conteste a:
conrad_b@iname.com


#2

Hi Conrad,

Hallo Seb,

... today I had the opportunity to test again. The machines are the same -
call on LAN - no fancy delay stuff in between.

As mentioned - sharing the Intel notebook screen works perfectly well. I
can work fluently from the remote side.

The other way around it is still unusable. I observed that the mouse
movement is delayed by a couple of seconds. The mouse pointer on the local
side is trailing the movements at the remote side. So from there it looks as
if nothing happens. Interestingly - entering text from the remote side
apperars instantly on both local and remote screens.

Strange, when Java's MouseListener methods (move, click, ...) are called,
they immediately trigger send of messages (move, right click, ...) to the
peer. The KeyListener method do the same. Maybe the mouseMove, mouseXXX, ...
are delayed... Things you can do is to put debug line in
OneToOnePeerPanel.java file in mouseMove method that they are called
immediately when you move the mouse, and ensure with wireshark that desktop
sharing event packets (SIP NOTIFY in case of SIP) are sent near the same
time as the mouse move. On the other peer ensure also that packets are
received quickly.

We will try to lookup to the "desktop frozen after 5 min" problem in the
following week or two if high priority tasks are finished.

Regards,

···

2011/2/19 Conrad Beckert <conrad_videokonferenz@gmx.de>
--
Seb

Observing the remote screen while changing the content locally shows the

changes with a delay of 500msec or so - which is fine.

So - the problem lies into propagating the mouse movements from remote to
local which is probably not caused by the ATI card's RAM read cycles.

Hope that helps you to find the issue. Give me a buzz if I can help you
further.

Conrad

----- Ursprüngliche Nachricht -----

Von: Conrad Beckert

Gesendet: 16.02.11 22:30 Uhr

An: dev@jitsi.java.net

Betreff: [jitsi-dev] Re: Additional Information for: Desktop sharing drives
CPU usage and latency sky high

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
>

Bitte antworten an/Please reply to/Por favor conteste a:
conrad_b@iname.com