The next version (24.1-1) of package eos-rankmirrors will include a new config variable EOS_RANK_WHEN_MIRRORLIST_CHANGES in file /etc/eos-rankmirrors.conf.
The variable enables or disables running eos-rankmirrors when package endeavouros-mirrorlist gets an update. Currently eos-rankmirrors will be executed in such condition.
The new package will be released later today, or tomorrow.
Edit 2025-Oct-29
Added the news table below.
Struck through the old information above.
Date
Version
Changes
2025-Oct-29
25.10.1-1
Support for parallel mirror ranking which makes it much faster. See eos-rankmirrors -h about new options --parallel and --sequential.
I’m quite mindful when ranking mirrors, of what other activity my system, and even other systems on the network are doing. I’d pick a quiet time to do it, so the benchmarking wasn’t impacted by unrelated fluctuations in the available bandwidth.
Perhaps you’ve accounted for this already @manuel, but here’s some thoughts if you don’t mind me sharing.
For example, lets say we have 100MiB available bandwidth on our connection.
If benchmarking in parallel, and the two fastest mirrors are tested simultaneously, the bandwidth might be evenly saturated, scoring an even split of 50MiB/s per mirror. If the full bandwidth had been available to each mirror when testing, lets say they would have scored 100MiB/s.
But then as testing continues, two new mirrors are tested. One mirror has ok speed, and the other is poor, the ok mirror might consume 60% of the available bandwidth with room to spare, because it wasn’t competing with another decent mirror, giving it a score of 60MiB/s.
In the rankings, the ok mirror scores #1, whilst the two (would be) faster mirrors are relegated to #2 and #3, because of the competing bandwidth when they were benchmarked.
This would be a more prominent issue on systems that have an Internet connection that is readily saturated by the benchmarking, and perhaps very low end hardware which may be loaded by a fast connection.
Mirror ranking result depends on very many factors, and we have no reasonable control over all of them.
For example, the fastest mirror can be temporarily offline at the time we rank them thus giving a suboptimal mirror list.
So usually ranking gives only partially correct estimate. Better would be ranking at many different times and collecting results, this way we could really find the “best” overall list. But then again, a good mirror can go permanently offline…
Some notes about eos-rankmirrors:
The number of available EOS mirrors is quite small.
We can prefer the speed or the update level of mirrors.
We can rank mirrors in parallel or sequentially.
Speed is measured by fetching a very small file from each mirror, causing a very small amount of traffic beyond connection management.
Hope this helps seeing what eos-rankmirrors does to deal with this complexity.
it is also that we need some playground for ranking inside installer at installtime, it is a problematic part and other tools do not work good too there in circumstances, thats a battlefield with constant work to do for us. And: no one have to use eos-rankmirrors your system your rules
rate-mirrors is also supported by welcome if you install it will show as a button. it could have a second button to add using it with the endeavouros flag in welcome i think? @manuel
Sometimes i miss the positive vibe here.. ( a bit )
hey @manuel nice tool! I love to use it, and i love to give feedback and have a nice conversation around that a l l t h e t i m e!
Users feedback and reporting about issues, improvement ideas e.t.c. will work to resolve issues and make it better and may having it a dependency less e.t.c, our tools are not the only perfect solution, its about errors too if you want to go forward and find new pathways. No progress without fails.
And a reminder:
Everyone is welcome to join development by pull requesting changes to the code too!
Only just me having a minute and reading this and some other threads., feeling like there is the need to remind all of us.
Proper options for apps do make a difference!
For example:
$ eos-rankmirrors --timeout 2
real 0m5,274s
user 0m1,401s
sys 0m0,553s
Naturally a timeout of 2 seconds (for each mirror) cannot be used everywhere, that’s why the default is 30 seconds.
Tip: see EOS_AUTORANK_TIMEOUT in /etc/eos-rankmirrors.conf.
There is still a problem with this i guess. I just run it, “twice” with sudo and without, in both occasions, the app doesn’t “end” itself after it is done. I have to do ctrl+z or ctrl+c to close it. And even “maybe” that it did finish its job, when i do it like that, i get “Stopped sudo eos-rankmirrors” message and it feels like an error message.
Well, Ctrl + Z suspends the job and stops it until you run fg so that won’t end the job. eos-rankmirrors is working here without sudo but it’s taking a while.
The output “gives the impression” that the app has finished its job. It actually lists the mirrors and their timings etc. But it doesn’t return back to the command prompt. It stays there.
I mean i switched to X11 yesterday, could this have done something? I don’t think so.
.
rate-mirrors is also supported by welcome if you install it will show as a button. it could have a second button to add using it with the endeavouros flag in welcome i think? 