Hi,
Sorry for the late reply. I am currently away from IIT Kanpur and was not able to make the necessary changes. We maintain the arch linux mirror at mirror.cse.iitk.ac.in.
We will now be syncing from one of the Trier 1 mirrors. I have send a mail to one of the admins rsync://rsync.gtlib.gatech.edu/archlinux/" I will start the cronjob once I get a go-ahead from them.
By the way I noticed in the mirror listing at http://www.archlinux.de/?page=MirrorStatus that our http mirrors response time is of the order of 6 seconds whereas our ftp server seems to be doing much better. (0.52).
I noticed that some mirrors have comparable response time for both http and ftp and in some cases the situation is reverse. Am I reading too much into these figures or is there some special reason for this?
Regards
ppk
On Wed, Jul 28, 2010 at 19:58, Piyush P Kurur ppk@cse.iitk.ac.in wrote:
By the way I noticed in the mirror listing at http://www.archlinux.de/?page=MirrorStatus that our http mirrors response time is of the order of 6 seconds whereas our ftp server seems to be doing much better. (0.52).
Currently there is something wrong with the mirror status page - it doesn't list some mirrors (including yours).
I noticed that some mirrors have comparable response time for both http and ftp and in some cases the situation is reverse. Am I reading too much into these figures or is there some special reason for this?
I don't know the reason for this.
On Wed, 28 Jul 2010 22:28:33 +0530, Piyush P Kurur ppk@cse.iitk.ac.in wrote:
By the way I noticed in the mirror listing at http://www.archlinux.de/?page=MirrorStatus that our http mirrors response time is of the order of 6 seconds whereas our ftp server seems to be doing much better. (0.52).
I probably should explain how this page works. Every hour a script downloads our core.db (~35kb) and a file called lastsync from each mirror. Our mainserver puts the current time into last one every hour. This way we get a rough idea when the mirror had synced. I also time the download of that small db file to measure the response time or speed.
So this response time shouldn't be taken too serious. Due to the small file size http mostly wins over ftp because http server seem to be more optimize for low response time. You can check that by comparing the results of these commands:
time wget -q ftp://mirror.cse.iitk.ac.in/archlinux/core/os/i686/core.db.tar.gz -O /dev/null time wget -q http://mirror.cse.iitk.ac.in/archlinux/core/os/i686/core.db.tar.gz -O /dev/null
Btw: You mirror is currently not listed on http://www.archlinux.de/?page=MirrorStatus because it hasn't synced within the last week. I have setup a page which displays more information especially of outdated mirrors at https://www.archlinux.de/?page=MirrorProblems There is also an error log at the bottom of that page.
Greetings,
Pierre
Pierre Schmitz (pierre@archlinux.de) wrote on 31 July 2010 15:09:
On Wed, 28 Jul 2010 22:28:33 +0530, Piyush P Kurur ppk@cse.iitk.ac.in wrote:
By the way I noticed in the mirror listing at http://www.archlinux.de/?page=MirrorStatus that our http mirrors response time is of the order of 6 seconds whereas our ftp server seems to be doing much better. (0.52).
I probably should explain how this page works. Every hour a script downloads our core.db (~35kb) and a file called lastsync from each mirror. Our mainserver puts the current time into last one every hour. This way we get a rough idea when the mirror had synced. I also time the download of that small db file to measure the response time or speed.
Could you please put the last sync column in UTC? It makes it much easier for admins spread worldwide.
What's the meaning of the Delay column?
On Sat, 31 Jul 2010 16:26:57 -0300, Carlos Carvalho carlos@fisica.ufpr.br wrote:
Pierre Schmitz (pierre@archlinux.de) wrote on 31 July 2010 15:09:
On Wed, 28 Jul 2010 22:28:33 +0530, Piyush P Kurur ppk@cse.iitk.ac.in wrote:
By the way I noticed in the mirror listing at http://www.archlinux.de/?page=MirrorStatus that our http mirrors response time is of the order of 6 seconds whereas our ftp server seems to be doing much better. (0.52).
I probably should explain how this page works. Every hour a script downloads our core.db (~35kb) and a file called lastsync from each mirror. Our mainserver puts the current time into last one every hour. This way we get a rough idea when the mirror had synced. I also time the download of that small db file to measure the response time or speed.
Could you please put the last sync column in UTC? It makes it much easier for admins spread worldwide.
Ok done. times are now in format Y-m-d (GMT)
What's the meaning of the Delay column?
I added some titles. For the delay I added "Average difference between time of probe and last sychronization". This means if I download the lastsync file at 12:00 from your mirror and the file indicates that you have synced at 10:00 you got a delay of 2 hours.Of course this is very rough but should give us an idea how often you sync with the master server (directly or indirectly). We might update the lastsync file more often in future to get some better results. For now I would guess we have an error of about one hour.
Thanks for your feedback btw.. This was one of the projects you do just for fun and should never actually be used by anybody. :-)
Greetings,
Pierre
Pierre Schmitz (pierre@archlinux.de) wrote on 31 July 2010 22:47:
On Sat, 31 Jul 2010 16:26:57 -0300, Carlos Carvalho
Could you please put the last sync column in UTC? It makes it much easier for admins spread worldwide.
Ok done. times are now in format Y-m-d (GMT)
Thanks!
What's the meaning of the Delay column?
I added some titles. For the delay I added "Average difference between time of probe and last sychronization". This means if I download the lastsync file at 12:00 from your mirror and the file indicates that you have synced at 10:00 you got a delay of 2 hours.Of course this is very rough but should give us an idea how often you sync with the master server (directly or indirectly). We might update the lastsync file more often in future to get some better results. For now I would guess we have an error of about one hour.
Yes, but the numbers there don't make sense. For our case (c3sl.ufpr.br), the delay is 12.92 or 12.72 hours. Since you list us as having updated at 2010-07-31 18:01, and now is Jul 31 21:05:23 UTC, there are two possibilities. The first is that you're in the past, in which case you cannot know we updated at the moment you list. The second possibility is that your're in the future :-)
Thanks for your feedback btw.. This was one of the projects you do just for fun and should never actually be used by anybody. :-)
:-)
On Sat, 31 Jul 2010 18:08:11 -0300, Carlos Carvalho carlos@fisica.ufpr.br wrote:
Pierre Schmitz (pierre@archlinux.de) wrote on 31 July 2010 22:47:
I added some titles. For the delay I added "Average difference between time of probe and last sychronization". This means if I download the lastsync file at 12:00 from your mirror and the file indicates that you have synced at 10:00 you got a delay of 2 hours.Of course this is very rough but should give us an idea how often you sync with the master server (directly or indirectly). We might update the lastsync file more often in future to get some better results. For now I would guess we have an error of about one hour.
Yes, but the numbers there don't make sense. For our case (c3sl.ufpr.br), the delay is 12.92 or 12.72 hours. Since you list us as having updated at 2010-07-31 18:01, and now is Jul 31 21:05:23 UTC, there are two possibilities. The first is that you're in the past, in which case you cannot know we updated at the moment you list. The second possibility is that your're in the future :-)
There is a solution which does not involve time travel at all: the delay value is an average value measured during the last week every hour. So if you mirrors keeps updating this value should decrease soon. I did this to get more usable values instead of just snapshots.
Maybe I should just show you the code:
delay = (SELECT AVG(mirror_log.time-mirror_log.lastsync) FROM mirror_log WHERE mirror_log.host = tmirrors.host AND mirror_log.time >= '.$range.')
with $range being 1 week and time being the time of probe.
We (archlinux.c3sl.ufpr.br) got
rsync: failed to connect to rsync.archlinux.org: Connection timed out (110)
twice today. Is there a problem?
On Sat, Jul 31, 2010 at 22:30, Carlos Carvalho carlos@fisica.ufpr.br wrote:
We (archlinux.c3sl.ufpr.br) got
rsync: failed to connect to rsync.archlinux.org: Connection timed out (110)
twice today. Is there a problem?
Looks like there was a connection problem in a region where our server is hosted.
arch-mirrors@lists.archlinux.org