gesquive / fast-cli Goto Github PK

running go get -u .. on a clean machine yields:

$ go get -u github.com/gesquive/fast-cli
# github.com/gesquive/fast-cli
src/github.com/gesquive/fast-cli/main.go:66:2: undefined: cli.SetLogLevel
src/github.com/gesquive/fast-cli/main.go:68:3: undefined: cli.SetLogLevel

Forked the repo to add in the Upload feature asked about in #7, and in testing I've been seeing drastic differneces in download speed in browser vs via the cli app.

Example:

Tests taken just a few seconds apart:
CLI: 302.58 Mbps
Browser: 560 Mbps

Wanted to mark this as an issue. I'll be investigating as well.

I can't run fast-cli on my m1 Mac, can you support it?
thanks

Please add some option, maybe --simple, to not show any progress but just the estimated download speed. I want to use this for a nagios service test and only want the final estimate.

Thanks.

Upstream now supports testing upload also, could that be added say behind a flag --upload?

It would be cool if you can add an option to force IPv4 test over IPv6 test

Overview

An option for normalized output in bytes (aka a non-human readable form) would allow for easier machine processing of the output.
For example, normalized results could be trivially plotted over time.

Currently the result is always printed in human readable form, which makes the magnitude of the numeric result change depending on its unit. Machine processing requires post-processing of the result in order to get it back into bps, which is cumbersome to do from the command line. The resultant line also includes additional whitespace prefixing, which makes processing in bash even more cumbersome.

Example

Example of current output:

$ fast-cli --simple
  47.19 Mbps

Example of normalized output:

$ fast-cli --simple --normalized
47190000

Workaround

Current workaround is to use numfmt (available in debian coreutils package):

$ fast-cli --simple | numfmt --from=auto --suffix=bps -d \n
47100000bps

However, this still includes a "bps" suffix which must be removed.

Changes

This would require parsing an additional argument, and adding an extra case in main.go:

Hi,

any chance we could make the test last longer? For high speed connections it gets very inacurate:

[root@haproxy bin]# ./fast-cli -D
Using HTTPS
trying to get fast api token from https://fast.com/app-233b5b.js
token found: YXNkZmFzZGxmbnNkYWZoYXNkZmhrYWxm
getting url list from https://api.fast.com/netflix/speedtest?https=true&token=YXNkZmFzZGxmbnNkYWZoYXNkZmhrYWxm&urlCount=3
urls:
 - https://ipv6-c081-fra002-ix.1.oca.nflxvideo.net/speedtest?c=de&n=24940&v=5&e=1575368342&t=_6HtmgNNziNVhSqCLyoziWVuZO8
 - https://ipv6-c085-fra002-ix.1.oca.nflxvideo.net/speedtest?c=de&n=24940&v=5&e=1575368342&t=E4ThGGZ8eUrO_ogKnCSM7G4vVbY
 - https://ipv6-c147-ams001-ix.1.oca.nflxvideo.net/speedtest?c=de&n=24940&v=5&e=1575368342&t=51DwzqeI43brrdK5pSR0rJayMKY
Got 3 from fast service
Download Size=26214400
Estimating current download speed
   1.64 Gbps - 100.0%
Completed in 0.2 seconds

How can he accurately calcutate 1.65 Gbps with just 26 MB?

Also if repeated over and aover again it jumps from 1.26 to 1.89 Gbps

So my suggestion would be to either add a flag to run a long test (download larger files more than once) or make it more dymanic like fast.com ?

Thanks!

The client should also have an option for "more info" which shows latency and uplink speed.