How the voice package works in TeaSpeak?

[REDOSS]

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).

Spoiler: Test 1.3.20-beta-1 (optimized) and 3.0.13.8

 

[WolverinDEV]

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]

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

 

[WolverinDEV]

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

 

[REDOSS]

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

 

[REDOSS]

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

at least enabling/disabling encryption was fixed in 1.3.21-beta-7.
We are waiting for further changes.

 

[WolverinDEV]

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.​

 

[REDOSS]

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))

 

[REDOSS]

// Closed