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
I'm running ndt-server on Ubuntu 24.04(Desktop), and I have ndt-go-client-minimal binary on my Linux ARM device. When I perform a speed test on the ARM device ./main -locate=false -ssl=false -download=ws://192.168.2.6/ndt/v7/download -upload=ws://192.168.2.6/ndt/v7/upload, I get around 1.8Gbit for upload and 1.2Gbit for download. Both devices are directly connected to each other via a 2.5Gbit port using a CAT 6 cable. BBR is enabled on the server side, and I'm not encountering any errors. Do you have any idea what might be causing this imbalance?
note: When I tested with iperf3, the results were parallel and approximately 1.8Gbit.
The text was updated successfully, but these errors were encountered:
I have two suggestions here. Can you attempt enabling BBR also on the client side? What is the CPU utilization of both the ARM device and your desktop while running the experiment? I wonder if the CPU might be the bottleneck.
Another suggestion / comment: I experienced a similar behaviour (limitation in the download throughput) using Raspberry PI (arm device) with ndt-client and 32 bits OS (the default image for Raspberry PI OS is 32-bit). After changing to 64 bits OS, this limitation disappeared.
Hello,
I'm running ndt-server on Ubuntu 24.04(Desktop), and I have ndt-go-client-minimal binary on my Linux ARM device. When I perform a speed test on the ARM device
./main -locate=false -ssl=false -download=ws://192.168.2.6/ndt/v7/download -upload=ws://192.168.2.6/ndt/v7/upload
, I get around 1.8Gbit for upload and 1.2Gbit for download. Both devices are directly connected to each other via a 2.5Gbit port using a CAT 6 cable. BBR is enabled on the server side, and I'm not encountering any errors. Do you have any idea what might be causing this imbalance?note: When I tested with iperf3, the results were parallel and approximately 1.8Gbit.
The text was updated successfully, but these errors were encountered: