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.

Sign up for GitHub

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

Jump to bottom

Enable experimental BWE by default in AppRTC #17

Closed
juberti opened this issue Apr 30, 2014 · 9 comments
Closed

Enable experimental BWE by default in AppRTC #17

juberti opened this issue Apr 30, 2014 · 9 comments
Labels
enhancement

Comments

@juberti
Copy link
Contributor

juberti commented Apr 30, 2014

No description provided.

@marwahvikas
Copy link
Contributor

Thanks will work on it.

@marwahvikas
Copy link
Contributor

Looked into it, seems like need to add constraint googImprovedWifiBwe set to true. Do we want to have this as a url param to enable/disable it as well?

@juberti
Copy link
Contributor Author

juberti commented May 1, 2014

Just set it to true universally.

On Thu, May 1, 2014 at 3:35 PM, Vikas Marwaha notifications@github.comwrote:

Looked into it, seems like need to add constraint googImprovedWifiBwe set
to true. Do we want to have this as a url param to enable/disable it as
well?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-41964848
.

@marwahvikas
Copy link
Contributor

sure thanks!

@cowwoc
Copy link

cowwoc commented May 21, 2014

What is the meaning of googImprovedWifiBwe?

@juberti
Copy link
Contributor Author

juberti commented May 21, 2014

It was an experimental change to our bandwidth estimation algorithm. The
experiment was successful and it is now on by default in Chrome 36.
On May 21, 2014 5:36 PM, "cowwoc" notifications@github.com wrote:

What is the meaning of googImprovedWifiBwe?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-43817461
.

@cowwoc
Copy link

cowwoc commented May 21, 2014

Is it too technical to explain how you treat Wifi and non-Wifi connections differently under this new algorithm?

@juberti
Copy link
Contributor Author

juberti commented May 22, 2014

We didn't treat wifi differently, we just improved the algorithm to deal
better with some issues that were seen in congested wifi networks.

On Wed, May 21, 2014 at 7:03 PM, cowwoc notifications@github.com wrote:

Is it too technical to explain how you treat Wifi and non-Wifi connections
differently under this new algorithm?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-43825585
.

@fippo fippo mentioned this issue May 24, 2014
Closed
@juberti
Copy link
Contributor Author

juberti commented May 30, 2014

Fixed in #24

@juberti juberti closed this as completed May 30, 2014
dogben pushed a commit that referenced this issue Oct 5, 2021
@palak8669
WebGPU sample pages that use Insertable Streams (#1481)
89ef09b 
* WebGPU sample pages that use Insertable Streams

* Changes to the main index file (#7)

* Formatting changes (#8)

* Main (#9)

* Formatting changes

* Editing info on index page

* Adding errorMsg

* Adding errorMsg (#10)

* Changing the structure of worker processing (#11)

* Renaming files (#12)

* Formatting changes (#13)

* Formatting (#14)

* More changes (#15)

* Adding the break clause (#16)

* Main (#17)

* resolving comments

* resolving comments

* Minor changes (#18)

* Formatted with eslint (#19)

* Modifying eslint config (#20)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cowwoc @juberti @marwahvikas