Welcome! Log In Create A New Profile

Advanced

Perormance evaluation- cpu load, bit rate fps

Posted by ilayn 
Perormance evaluation- cpu load, bit rate fps
April 16, 2012 04:59PM
Hello
I would to know if i own a server if can know on my 20 +clients at
-what bit rates/resoultion/FPS the connected ?
for example 320X240 1 fps
- i would like to estimate whicn intel processor i need
do you have a table cpu load per decoder?
for example on intel's i5 or i7 what is the cpu load for decode 640x480 1 FPS ?
and 10 FPS?
i need this to estimate how many clients can my cmputer handle before crashing

cheers.
ilan
Re: Perormance evaluation- cpu load, bit rate fps
April 16, 2012 07:27PM
Hi

20 clients at 320X240 1 fps shouldn't be a problem. Once you increase the frame rate to 10 fps it might already start to choke. It's hard to say what the limit is. It also depends how much movement is in each video stream. All I can say is try and see what happens. You can always unsubscribe video streams to reduce the load.

One user told me that on his system it started to choke when he had 70 clients with 160x120 at 1 fps.

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 17, 2012 09:58AM
Bjoern
tks a lot, do you have a paper with some measured performance on one of intels platorms?
Re: Perormance evaluation- cpu load, bit rate fps
April 17, 2012 04:32PM
No, I haven't. You can try searching the Theora website for more info. [www.theora.org]

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 18, 2012 09:41PM
what could be bottleneck?

i know its not cpu(after upgrading to quad)
though it do use alots of cpu
when i open TT client with 25 cams with 640 resolution it chokes after few seconds
regrds
Re: Perormance evaluation- cpu load, bit rate fps
April 19, 2012 04:54PM
How much CPU does TT use? If it's running at 100% on one core then you're out of resources...

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 19, 2012 07:44PM
thats exactly the thing
cpu is 30-50%

there is free mem
there is free net resources still....

now i have figured out, ony TT moves slow and ... like in "breaks"...

rest of the programs are ok...

we do open a lot of cams... may be 70-80... (240-160) but still pc resources are available

should we try to use 32 bit ? (on windows 7 x64)?
may be linux client?
what do you say?
Re: Perormance evaluation- cpu load, bit rate fps
April 20, 2012 10:54AM
ok.... 640x480

23 cams in one TT are killing the program (the pc keeps on working good)
23 cams in two TT instances 10/13 is alright and works very good

Bjoern, is this given situation, because some kind of technical limit?

or can it be changer for good smiling smiley?
Re: Perormance evaluation- cpu load, bit rate fps
April 20, 2012 12:50PM
It's a bit complicated to explain but basically only one core on the CPU is handling the decoding of the video streams, so having more cores doesn't help easy the CPU usage. There are, however, ways in which TT can be optimized to distribute decoding on multiple cores but it's quite complicated to implement.

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 20, 2012 01:31PM
hmm...

that means that it is limited to about 20 video streams with reasonable resolution and bitrate.

bacause i use Q9505 quad 2.8 Hz
so there is nothing more to improve really on the hardware side...
Re: Perormance evaluation- cpu load, bit rate fps
April 20, 2012 02:14PM
The guy who was running 70 video sessions was running on Linux, so maybe Linux handles the UI updates in a better way than Windows.

On Windows you can also start two clients and have each client handle a subset of the users. That way you distribute users on separate cores.

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 24, 2012 05:38PM
Hi Bjoern.

Do you plan to make teamtalk multi threaded?

Regards
Re: Perormance evaluation- cpu load, bit rate fps
April 24, 2012 06:16PM
Hi

No, not at the moment. It's a quite big task, since core parts of the API needs to be redesigned.

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 24, 2012 08:22PM
oh...
just when i thought life is beautiful smiling smiley
Re: Perormance evaluation- cpu load, bit rate fps
April 28, 2012 07:46AM
Someone please humour me if I'm out to lunch on this but if you developed a client with the SDK couldn't you multithread the video decoding yourself. Maybe you could have a scenario where video for the even number users would get decoded by thread A and odd numbered users processed by thread b. In the long run I would think that would be simpler than having two client instances. Since I don't do video I haven't looked at the functions that deal with the video very closely but it seems to me that you should be able to split the work up within the same client instance some how.
Re: Perormance evaluation- cpu load, bit rate fps
April 28, 2012 04:11PM
Hi Barry

Whenever you call one of the TT_* functions you lock that instance so other threads cannot access it. If multiple threads should be able to decode video then this locking strategy would have to be changed so multiple threads can access the same client instance. This would require quite a change in the design, so that's why I say supporting this is a big task.

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 28, 2012 09:46PM
I guess that means that you would need to run two or more servers. Am I correct in saying that two instances of the client cannot connect to the same server at the same time?
Re: Perormance evaluation- cpu load, bit rate fps
April 28, 2012 11:28PM
Having several clients connecting to the same server is no problem. It's just that only one thread can access each client instance.

-- Bjoern
Re: Perormance evaluation- cpu load, bit rate fps
April 30, 2012 02:21AM
Very interesting. I'm surprised that more than one client instance can access the same server at the same time. If that's true then it means that you should be able to use the SDK to create a client where multiple threads share the workload of decoding the video. Perhaps as I suggested you could subscribe one instance to the video for the odd numbered users and the other to the even numbered ones. As long as each instance runs in its own thread the workload distribution should be roughly equal. And you don't need to stop there. You could have as many threads and instances as you like. Kind of a messy solution until the API itself is multi-threaded. Bjoern your mission should you decide to accept it is to give the TT5 api the ability to share client instances across threads!

Barry
Your IP-address is listed as spammer. Email contact@bearware.dk if this is an error
Sorry, only registered users may post in this forum.

Click here to login