The purpose of this page is to try to explain everything shown on the results page, so that the results page can link to the various parts for the curious.
Tests are tested over IPv4 if the mirror has IPv4 addresses.
Tests are tested over IPv6 if the mirror has IPv6 addresses.
The FTP tests have not been written yet.
There are two styles of HTTP tests - actual HTTP downloads and HTTP HEAD tests. Actual downloads happen when other tests need the files to be downloaded. HEAD tests are where apt-panopticon probes things in detail. For each mirror (including the DNS round robin domain), and for each IP of that mirror -
The HTTPS tests are very similar to the HTTP tests detailed above, though obviously they are tried with HTTPS requests intead of HTTP requests. The validity of the HTTPS certificate for each server is tested as well.
The RSYNC tests have not been written yet.
The "DNS round robin" column lists the IP addresses for each mirror that is part of the DNS round robin, or DNS-RR. The IPs are linked to the log for that specific IP when used via the DNS round robin, and is followed by the number of errors, warnings, or timeouts of any.
Mirrors that redirect /DEVUAN/ back out to deb.devuan.org is an ERROR. /DEBIAN-SECURITY/ packages must be redirected to a Debian mirror, specifically a mirror hosting Debian security updates. However, some Devuan mirrors might also be Debian mirrors, so this is just a WARNING.
The Protocol test will give a warning if the protocol is changed during a redirect, HTTP -> HTTPS for example. While apt HTTPS transport is now the default in Beowulf / Buster, not everyone with an older release will have that installed, so redirecting HTTP to HTTPS will break apt for those people. An error is given instead if that happens for mirrors in the DNS round robin. Servers in the DNS round robin will not have the HTTPS certificate for the round robin domain, so redirecting to HTTPS for that is a mistake.
The URL sanity test replaces "/" in URLS with "///", to see if the mirror can cope with that. This might happen due to a minor mis-configuration by the apt user, but decent web servers should cope with that. The result for a mirror that does not cope is a failed download for that use, so this is an error.
Actually download files, then check things like PGP keys, SHA256 check sums, and file size. For actual packages, pick the smallest one that has been recently updated.
Make sure the Release files are up to date by checking their internal "Date" field. If they are up to date, download and check updated Packages.xz files, and actual packages. For actual packages, pick the smallest one that has been recently updated.
Also shown is the mirrors scheduled time between updates, with "m" meaning minutes and "h" meaning hours.
The speed test tries to guess at a minimum and maximum speed range for each mirror. It does this by measuring the reported speeds from the curl commands that actually download files. Since apt-panopticon is trying hard to download everything from all mirrors all at the same time, this guess will be low. Also, the computer running the apt-panopticon might have a network connection that is busy with other things. Finally, the tested mirror may have a bigger network connection than the computer running the test, so wont show it's true maximum. So take this speed measurement with a grain of salt, it's more of an indication, the full graphs might be useful.
This is the percentage of time the mirror was up, and the percentage of time the mirror was up to date. Note that if the mirror has a low uptime, then there wasn't much chance to check if it was up to date.
A link to the graphs for this mirror.