Re: Using speedtest in CLI

[André Luiz dos Santos]

Hello,

https://github.com/m-lab/ndt7-client-go

The go get command should build a binary ready for use.

Em quinta-feira, 18 de agosto de 2022 às 12:49:51 UTC-3, appuka...@gmail.com escreveu:

Since M-Lab speed test is open-source, is there any way to integrate it into the command prompt, as is the case with Ookla?

[Cleiton Moya de Almeida]

Hi Karthik,

You can use the reference nd7-client implementation:

https://github.com/m-lab/ndt7-client-go

Best regards

Cleiton

Em qui., 18 de ago. de 2022 às 12:49, Karthik Sunkad <appuka...@gmail.com> escreveu:

Since M-Lab speed test is open-source, is there any way to integrate it into the command prompt, as is the case with Ookla?

--
You received this message because you are subscribed to the Google Groups "discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@measurementlab.net.
To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/78b9e915-564b-47a0-a9ae-32086d538fden%40measurementlab.net.

[Dave Taht]

Oh, cool.

I'd really like it if more tests (especially command line ones like
this one) had a final phase where they tried up and downloads at the
same time. The behavior of a network in this scenario is only tested
today by the infamous flent rrul test, and the results of mixing up
and down in this way are not well understood...

... and yet a network with loads going both ways is rather common.
Anyone here's network users shout out to whole household: "OK!
EVERYBODY DOWNLOAD NOW! Y'ALL DONE? OK, EVERYBODY CAN UPLOAD NOW! THX!
MAKE SURE YOU TELL US IF YOU NEED TO DO a big up or download so we can
be ready!"

I really think there could be a lot more papers written about what
goes wrong on todays networks, especially in asymmetric situations,
when you do both up and down at the same time.

[Dave Taht]

So I tried a quick test of both up and down on my starlink terminal,
and got a puzzling result.

1) I assume it's BBR on the server?
2) I got no result for latency on the upload. So wonderful to crack
the speed of light in this way!

davet@milliways:~/git/ndt7-client-go$ ./ndt7-client -upload=false &
download in progress with ndt-mlab3-lax02.mlab-oti.measurement-lab.org
Avg. speed : 65.1 Mbit/s
download: complete
Server: ndt-mlab3-lax02.mlab-oti.measurement-lab.org
Client: 98.97.61.1
Latency: 27.2 ms
Download: 65.1
Upload: 0.0
Retransmission: 0.41 %

davet@milliways:~/git/ndt7-client-go$ ./ndt7-client -download=false &
[1] 2032051
upload in progress with ndt-mlab2-lax04.mlab-oti.measurement-lab.org
Avg. speed : 4.0 Mbit/s
upload: complete
Server: ndt-mlab2-lax04.mlab-oti.measurement-lab.org
Client:
Latency: 0.0
Download: 0.0 Mbit/s
Upload: 4.0 Mbit/s
Retransmission: 0.00

--
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[Roberto D'Auria]

Yes, all the M-Lab servers use BBR, which is only relevant when the server is the one sending test data (i.e. download tests). For upload tests, it depends on the cc used by the client's TCP stack.

Re. breaking the speed of light: :)

The latency shown to the user is TCPInfo's MinRTT field read at the sender. Clients cannot in general (even though it would be possible for a Linux-only client) collect TCPInfo data. During a download test this is not a problem since the server sends periodic messages including the TCPInfo struct. During an upload test, clients must rely on the receiver's (the server's) TCPInfo.

We previously assumed that during upload tests the server does not send enough packets to make its calculated MinRTT accurate enough, and that's why an upload-only test does not report latency. We are revisiting this assumption and I'm going to push a fix to the client soon.

(The same goes for retransmission, but in that case we can't use server-side data -- the client just cannot know its retransmission rate without access to TCPInfo.)

-Roberto

--
You received this message because you are subscribed to the Google Groups "discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@measurementlab.net.

To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAA93jw6zUmwkrRH0hxqQOBDB03DwOPvkqCJeqgOAGQD0wnz%2BUg%40mail.gmail.com.