On Wed, Jul 28, 2010 at 19:58, Piyush P Kurur 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. -- Roman Kyrylych (Роман Кирилич)

Pierre Schmitz (pierre@archlinux.de) wrote on 31 July 2010 15:09:

On Wed, 28 Jul 2010 22:28:33 +0530, Piyush P Kurur 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 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 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, https://users.archlinux.de/~pierre

On Sat, 31 Jul 2010 18:08:11 -0300, Carlos Carvalho 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. -- Pierre Schmitz, https://users.archlinux.de/~pierre