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

Miscellaneous fixes #91

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Miscellaneous fixes #91

wants to merge 6 commits into from

Conversation

nosnilmot
Copy link

@nosnilmot nosnilmot commented Mar 3, 2023

Primarily motivated by finding poor results during upload speed tests

SwiftWebSocket: thread-safety fixes

Use one source for measurements in each direction (See also: m-lab/ndt7-client-go#75)

  • For download test, prefer measurements of bytes confirmed received by client
  • For upload test, prefer measurements of bytes confirmed recevied by serve

Remove hardcoded delay when output is buffered

  • Instead of fixed time interval delay when buffering is encountered, adjust delay based on currently calculated bitrate to estimate time to flush buffer before resuming upload

Remove crude repeats of same WebSocket frame

  • Scaling upload frame payload size is preferred to sending multiple (100) copies of same relatively small frame for upload tests

Minor optimization to local measurement reporting

  • Avoid unnecessary JSON parsing of '{}'

Implement upload message scaling

  • As recommended in NDT7 protocol increase size of upload message payload as test progresses, doubling up to maxMessageSize when the current binary message size is <= than 1/scalingFactor of the bytes sent so far

This change is Reviewable

Apply thread-safety fixes from
tidwall/SwiftWebSocket#141 to embedded copy of
SwiftWebSocket
For download test, prefer measurements of bytes confirmed received by
client

For upload test, prefer measurements of bytes confirmed recevied by
server

See also: m-lab/ndt7-client-go#75
Instead of fixed time interval delay when buffering is encountered,
adjust delay based on currently calculated bitrate to estimate time to
flush buffer before resuming upload
Scaling upload frame payload size is preferred to sending multiple (100)
copies of same relatively small frame for upload tests
Avoid unnecessary JSON parsing of '{}'
As recommended in NDT7 protocol increase size of upload message payload
as test progresses, doubling up to maxMessageSize when the current
binary message size is <= than 1/scalingFactor of the bytes sent so far
@stephen-soltesz
Copy link
Contributor

@olgagalchenko Are you able to take a look at this change?

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

Successfully merging this pull request may close these issues.

2 participants