Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High load of MSE receiver #14

Open
AdithyanIlangovan opened this issue Sep 21, 2016 · 0 comments
Open

High load of MSE receiver #14

AdithyanIlangovan opened this issue Sep 21, 2016 · 0 comments

Comments

@AdithyanIlangovan
Copy link
Contributor

AdithyanIlangovan commented Sep 21, 2016

. Normal receiver MSE receiver - old MSE receiver - new
Video process 45% 90% 90%
Audio process 9% 35% 36%
  • The above shows the load of the process, as seen by the top command, when running the different receivers.
  • The top two process (which are assumed to video and audio ) in terms of load are specified here.
  • We need to find way to reduce the load in MSE receiver.
  • One idea is to increase the buffer delay before appending to the websocket, it is expected that increasing the delay should decrease the load

Update 1:

. Normal receiver MSE receiver - old MSE receiver - new MSE receiver - stripped with only web socket reception
Video process 45% 90% 90% 46%
Audio process 9% 35% 36% 34%

Update 2:

We are not entirely sure, whether two process correspond to audio and video process. They could as well be two threads running inside chrome. This has to be further investigated. But the inference from the above table is that the websocket reception does take a lot of load on the system. We need to figure out a way to reduce this load.

(Flute Sender) ----> (Receive packets chunked into the size of 1428) ----->(Store inside the circular buffer) ----->(Lib websocket read from the circular buffer) ---> (Forwarded to the websocket of the javascript)

The reason we need the circular buffer in between is because the lib websocket read is an ansychronous process. And reads whenever it is done with a packet, so we need something in between where it can take those data from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant