You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more an FYI than an actual bug report, since I believe fixing it would mean making significant protocol changes, but it's still something worth documenting.
Some context: during a download measurement, the server can send either binary (random bytes) or text (Measurement objects in JSON format) messages. The collection of a Measurement and the corresponding send is tied to a timer, which fires at slightly randomized delays -- every 250ms on average. This is implemented in ndt7/download/sender/sender.go.
The issue: since both binary and text messages are sent over the same websocket connection, only one of them can be sent at any time. The maximum size of a binary message is set to 1MB, so for the time it takes to send 1MB no Measurement object can be sent over the network.
Moreover, since the goroutine handling the timer sends Measurements to the sender goroutine over a blocking channel, no new Measurement object is created (i.e. no TCPInfo/BBRInfo polling) until the previous Measurement has had a chance to be sent over the network.
This issue becomes particularly evident when building ndt-server with a higher polling rate (e.g. every 50ms on average instead of 250ms). With the current maximum message size, a quick estimation is that every flow slower than 32Mb/s (1 MB / 0.25s * 8) will see sparser Measurement messages than expected.
I also believe this behavior became noticeable only after fixing the message scaling in 2021 since binary messages would never get larger than 64KB before then.
The text was updated successfully, but these errors were encountered:
This is more an FYI than an actual bug report, since I believe fixing it would mean making significant protocol changes, but it's still something worth documenting.
Some context: during a download measurement, the server can send either binary (random bytes) or text (Measurement objects in JSON format) messages. The collection of a Measurement and the corresponding send is tied to a timer, which fires at slightly randomized delays -- every 250ms on average. This is implemented in ndt7/download/sender/sender.go.
The issue: since both binary and text messages are sent over the same websocket connection, only one of them can be sent at any time. The maximum size of a binary message is set to 1MB, so for the time it takes to send 1MB no Measurement object can be sent over the network.
Moreover, since the goroutine handling the timer sends Measurements to the sender goroutine over a blocking channel, no new Measurement object is created (i.e. no TCPInfo/BBRInfo polling) until the previous Measurement has had a chance to be sent over the network.
This issue becomes particularly evident when building ndt-server with a higher polling rate (e.g. every 50ms on average instead of 250ms). With the current maximum message size, a quick estimation is that every flow slower than 32Mb/s (
1 MB / 0.25s * 8
) will see sparser Measurement messages than expected.I also believe this behavior became noticeable only after fixing the message scaling in 2021 since binary messages would never get larger than 64KB before then.
The text was updated successfully, but these errors were encountered: