• Hey Guest, we're evolving the future of TeaSpeak.
    You're invited to join the discussion here!

How the voice package works in TeaSpeak?

REDOSS

TeaSpeak Team
Staff member
TeaTeam
As I said on my server rose sharply online due to the start of the game event in our game.

I am currently using two servers with the same configurations:
  1. Tea*Speak 3 Server, version 3.0.13.8
  2. TeaSpeak Server, version 1.3.20-beta-1 (optimized)


I noticed that when users join into one channel and start chatting, the TeaSpeak server starts consuming a lot of resources, namely the CPU. If such actions are repeated on the Tea*Speak server, the CPU load also increases, but it is almost not noticeable.

Maybe now I will talk nonsense, but in my head these thoughts.
  1. The Tea*Speak server encodes a voice packet once for all channel members.
  2. The TeaSpeak server encodes each time a new voice packet for each channel member.
  3. In this regard, the load on the processor increases, as the number of requests for encoding increases.

Waiting for review Wolverine :) Please strong not to swear and not to laugh, it's just observation.

Below I attached the test (on the Tea*Speak server even more channels with online 15+ clients).
Без названия.png
 
Last edited:

WolverinDEV

TeaSpeak Team
Staff member
Administrator
Hey,
well you're right.
I'm encoding a voice packet for each client individually, but I guess Tea*Speak does that as well because every client has another private key which is used for the encryption.
I could improve performance there a bit by not copying the packet if the data should not be encrypted, but because encryption is usually recommend I haven't yet thought about that.
 

REDOSS

TeaSpeak Team
Staff member
TeaTeam
Hey,
well you're right.
I'm encoding a voice packet for each client individually, but I guess Tea*Speak does that as well because every client has another private key which is used for the encryption.
I could improve performance there a bit by not copying the packet if the data should not be encrypted, but because encryption is usually recommend I haven't yet thought about that.
If users are divided into more channels, the load is drastically reduced ... and becomes more or less close to Tea*Speak
 

REDOSS

TeaSpeak Team
Staff member
TeaTeam
Hey,
well you're right.
I'm encoding a voice packet for each client individually, but I guess Tea*Speak does that as well because every client has another private key which is used for the encryption.
I could improve performance there a bit by not copying the packet if the data should not be encrypted, but because encryption is usually recommend I haven't yet thought about that.
I think it's worth working on, as the performance will improve significantly... on the screenshot is very much a big difference))

Are you having voice encryption enabled on Tea*Speak and TeaSpeak?
Yes
 

WolverinDEV

TeaSpeak Team
Staff member
Administrator
Well I took some looks and I'm definably not sure how Tea*Speak does it, but I was only able to reduce the CPU usage about 3%.
I've also looked a bit deeper and for the the main "issue" seems to be the main "sendmsg" kernel function which took in avg 30 microseconds to perform. In general the encryption stuff took 30 microseconds a well. So thats def. not improvable.

Test case:
- 21 Users in one channel
- 1 User speaks (permanent voice activation)

Results:
TeaSpeak (beta7): 11-12% avg. CPU usage
TeaSpeak (beta8) 8-9% avg. CPU usage
Tea*Speak 3 (3.1.0) 5% avg. CPU Usage

Side note: You should might change some settings within your config.yml under the category "threads".
Depending on the instance usage could you may set execute_limit and execute_per_server to 2 or 4,
io_per_server and events_per_server could be set to 2 and io_limit to 2 as well :)
If you notice that in general the ping go up dramatically for everyone or that the server gets unresponsible sometimes then you should increase the io_per_server value along with io_limit.

A general explanation:
IO Threads:​
Each server as a configurable number of IO threads/events which listen for incoming data or for data which needs to be send.​
Tasks which will be executed within these threads are also packet de/encryption and fragmentation (Splitting packets to fit the MTUs)​
io_min and io_limit are the boundaries of how many threads should be used to perform this task.​
io_per_server is useful to increase the IO threads per server.​
An example would be:​
io_min: 2​
io_per_server: 1​
io_limit: 6​
Result:​
For 1 VS: Two IO threads will run​
For 3 VS: Three IO threads will run​
For 6 VS: Six IO threads will run​
For 8 VS: Six IO threads will run​
events_per_server:​
This property determines how many kernel "events" will be registered for listening to incoming messages.​
These events are also listening for the signal that new data could be send. So actually these events are the "trigger" for the tasks within the IO thread (Decode/encode a message). This also results in a dependency between the value of events_per_server and the total running IO threads. Recommend is to have a equal or for many virtual servers less events_per_server then​
IO threads.​
 
Last edited:

REDOSS

TeaSpeak Team
Staff member
TeaTeam
Thank you for the detailed configuration overview. I will look and try with the release of the beta 8. In General, a good job, optimization is not immediately, but gradually))

Today optimization is not visible, and the next day after a good rest immediately catches the eye)) ;)