My config for reflector is currently set as follows:
# Set the output path where the mirrorlist will be saved.
--save /etc/pacman.d/mirrorlist
# Select the transfer protocol.
--protocol https
# Use only the most recently synchronized mirrors.
--latest 200
# Sort the mirrors by synchronization time.
--sort rate
# Return, at most, the following number of mirrors.
--number 20
# Print extra info.
--verbose
I have Reflector set to run as a Systemd service, so it will run when my computer boots.
The “issue” is that I update my system as soon as I boot. Since Reflector is sorting mirrors by their measured download rate, I wonder if downloading updates, or simply doing any action that downloads data, would interfere with those measurements and cause Reflector to choose mirrors that may not be the fastest. I could simply wait for Reflector to finish before using the computer, but it takes quite a while to sort through 200 mirrors.
Is this concern justified? If so, are there ways to mitigate it that don’t require me to wait for Reflector to finish? I’ve thought about setting it as a Pacman hook so that it runs after updating, but, then, that relies on me to perform an update for the mirrorlist to be refreshed, and that still leaves the concern of other actions eating up network bandwidth, thus skewing the measurements.
How much data does Reflector download for each test?
It could simply be that Reflector isn’t overly efficient handling back-to-back tests. Perhaps there is a substantial idle period between tests that is eating up a large chunk of the total test time. Anecdotally, I have seen activity that suggests this in my network activity monitor — there are very short spikes and a comparatively long idle period in between.
If one doesn’t want to make arbitrary decisions then yes evidence would be required.
Lost time is still lost time. I’d prefer to saturate my connection. Anything less is an inefficiency. Small losses in time add up.