-
-
Notifications
You must be signed in to change notification settings - Fork 120
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
[Feature] Implement a "blocked" servers list #1877
Comments
This is great news, Alex! The steps look spot-on, and I like Option 1 for generating a list of servers to choose from for the reason you stated. This method is essentially the same as that used by another script I use from time to time and it has been very reliable. It allows the closest servers list to change dynamically as servers come and go over time, while still being able to filter out the slow ones that are identified. Also, --selection-details (show server selection details) seems to produce the same list of servers as --servers (aka -L), but includes what I believe is the idle latency and in a slightly different format. I only mention this because if you specify --selection-details, it picks the first server in the list to run the test, so it does appear that the list is an ordered list, although it doesn't appear that the order is based strictly on latency.
|
When dumping to json looks like the latency is missing but as long as the order is maintained I suppose that doesn't matter. {
"id": 56485,
"host": "secaucus.nj.speedtest.frontier.com",
"port": 8080,
"name": "Frontier",
"location": "Secaucus, NJ",
"country": "United States"
}, |
The latency is outside of the "server" structure:
BUT...I think you can use the simpler speedtest -L to generate the list as you originally suggested; it appears to be the same list of servers in the same order according to my testing. The only thing I was pointing out is that --selection-details generates the list and runs a test using the first entry, which would indicate that the list is in order of preference, and since that order matches -L, the -L list is likely also in order of preference. Interestingly, the list is not in order of increasing idle latency as illustrated in my earlier post which indicates that there are likely other factors that go into the ordering process. |
Looking forward to this, thanks so much! Also, if there's any chance of being able to configure this via the UI over time, that would feel like a big win as well |
📃 Description
In some cases "most" servers available locally are ok but sometimes they're not preferred and shouldn't be used when running a speedtest.
This issue will track the research needed to implement a blocked server list as the cli doesn't support this use-case.
🤔 Research
Since the cli doesn't support
--exclude
anymore we'll need to get a list of local servers first and intentionally choose one while excluding and "blocked" servers.Options
speedtest --servers --format=json
which returns a list of servers using Ookla's opinion of which is "best for you".https://www.speedtest.net/api/js/servers
. This looks close to the "best for you" cli list but does have some variance with my testing.In my option 1 is likely the best source as it's "probably" the method the cli uses to choose a server anyways.
🚶♂️ Steps
If a blocked server list exists take the following steps:
The text was updated successfully, but these errors were encountered: