bad order if ftp error ? #169
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
if we have one ftp error, all result list is not sorted ?
https://forum.manjaro.org/t/pacman-mirrors-fasttrack-adding-slow-or-invalid-entries-to-mirrorlist/75348/8
first at
0.5576is number 2 🙃second at
0.686is number 3 🙃changed the description
changed the description
changed the description
changed the description
The reason it is spotted is a symptom caused by an earlier issue.
Some time ago - there was an issue where mirror response was not sorted correctly because the values used was text based and those values couldn't be used in calculations.
The return value from the probing was then changed to
floatbut thesortingfunction's field argument was forgotten and still defined as string - which will wreck the sorting of numbers.Hmmm - No - that is not it ...
I found out why.
The Python sorted function does not change the list - but creates a new list.
My mistake was to assume that when using return sorted() a new list would be returned.
Assigning a the result of sorted to a variable then return the variable did the trick.
v4.21.5 is pushed to unstable
no change with 4.21.5
same "no sort" if
Bulgariais in input list (same command as post#1)changed the description
It works at my end
yes, work for you because list is now update : ftp
Bulgariawith error is removed from list ;)no error == no problem ;)
but we have another ftp error in Ukraine, so same "no order" if user select europe
here "zetup" is first with only
0.7...europe: truncated output and re-ordered lines for easy compare
also bad order (23media.com at pos 3 !! , i have 15 mirrors before)
The
--api --protocol allarguments has no relation to the sorting results - it only indicates that all protocols are accepted and the config is written accordingly.I am wondering why you get those results - because my result is expected - the sort parameter is the https result because default https is prioritized and only one protocol is used from each mirror. It makes no sense to include both http and https for the same mirror.
An error does not change the sort order as the protocol/mirror combination is not included in the final list.
OK, found why order is false :: is not with ftp errors (fixed by last commit) !!
ps: not possible to send you mp in forum for this long text 🥲
bad order is since beginning 😬
I had add "time info" in output filefn.py#L118 when app write list
result :
App use best time but always protocol[0] ! result
"osmir.ch" is in pos 7 (https:0.509) when "lavatech.top" (https:0.526) is at pos 2 🤪
Why test http if we have before https in protocol ? it is a big waste of time, we can skeep if we use always https
http is always most faster than https ;) if user want best speed why not chose best speed and not always first protocol ?
When mirror have only http protocol, it still has an advantage over https (in time) but is not necessarily faster in transfer (if other have only https)
Some mirrors have only http, result:
they are always very disadvantaged against those who have http and https, too bad they could sometimes be in first place because very fast if we compare only the https
exists aur package
httpstat-gofor understand diff https/http and what pamac-mirrors mesuretransfert http/https is the same (no reason to test 2 times...) - but time total diff is big ;)
note: with ftp we write on disk so we can't compare to http(s) ...
mentioned in commit
5a313d78e8mentioned in commit
5d867a90e6is this solved?
mentioned in merge request !336
mentioned in commit af61fd271e1a1cfefa94243a8403a8be037b072f
No response closing this one