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

Why final result is considered the last stat received in the test ? #15

Open
guiracine opened this issue Mar 2, 2016 · 5 comments
Open

Comments

@guiracine
Copy link

I am trying to understand how the network stats test works under the hood. I understand that the test stabilizes as the time goes up but is it the correct thing to do to present the final result as the last stat received ? Shouldn't we do an average of all stat values received ?

We implemented the test in both iOS and js.
In the javascript version we observed that that packet lost ratio could be > 0.0 in the test but the last stat received is == 0.0 so we consider that there is a good connection when this is not the case...Thats why we thought that we should compute the average of the stat values.

@guiracine guiracine changed the title Why final result is the last stat received in the test ? Why final result is considered the last stat received in the test ? Mar 2, 2016
@dylanjha
Copy link
Contributor

👍 wondering the same thing, did you try saving the stats and computing averages yourself?

@dylanjha
Copy link
Contributor

I'm experimenting with saving all the report objects and calculating the mean bitsPerSecond and packetLossRatioPerSecond values.

The thing I'm wondering is this line in the "How does it work" section:

During the test period, the video quality will stabilize, based on the available network connection quality.

It might be useful to try:

  • plot the data points out over a time series and see how long it takes to stabilize
  • discard outliers before calculating the mean so that we ignore early sporadic data points

@wobbals
Copy link

wobbals commented Dec 15, 2016

I think we'll be taking another look at this project in the coming months. In the meantime, I did start a separate project that uses the same API to accumulate periodic reports and produce less granular result: https://github.com/wobbals/opentok-mos-estimator - still a very rough draft, but it could be useful to get your feedback if you're looking at improving how to process getstats data.

@dylanjha
Copy link
Contributor

@wobbals this looks cool. I would love to help move opentok-mos-estimator forward. For the way it is set up now, what is a reasonable timeframe to run this test and get an estimate?

For our use case, we're looking at running a 20s or 30s test and making an assessment based on that. Would opentok-mos-estimator fit that use case?

@wobbals
Copy link

wobbals commented Dec 15, 2016

@dylanjha Probably some modifications might be wise for periodic sampling -- I'll shoot you an email and we can discuss.

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

3 participants