Mailinglist Archive: opensuse-factory (757 mails)

< Previous Next >
Re: [opensuse-factory] Bug 177758
  • From: Graham Anderson <graham.anderson@xxxxxxxxx>
  • Date: Thu, 25 May 2006 10:04:21 +0100
  • Message-id: <200605251004.21720.graham.anderson@xxxxxxxxx>
On Tuesday 23 May 2006 08:05, Marcus Meissner wrote:
> We cannot confirm this behaviour.
> parse-metadata occassionaly leads to a slow down, but only a minute
> at most and not on bootup.

Is it possible that parse-metadata or update-status are looping waiting for
the next metadata file to download? Please read the following and consider
this as a contributing factor somewhere in the update stack chain. If not
related to the problems with parse-metadata or update-status in it's own
right it highlights symptoms many users are reporting.

A user last night on #suse was having difficulty adding a mirror for the main
installation source. His symptoms were that the inst_source module would seem
to 'freeze' after he clicked the finish button.

Now knowing that the main repo can take a while to download, and knowing that
there is no progress indicator ( <hint> a *working* progress indicator for
inst_source would be an improvement by orders of magnitude I cannot convey in
written text </hint> ) I suspected that it was maybe a slow download of the
repo metadata after he had clicked finish.

I asked the user to try a few things and I was surprised to discover he would
have the same problem for smaller repos with small sized metadata, I asked
him to try adding a ZYPP source using rug and the same response, he would say
that 'rug had stalled, it had frozen on 0% progress'. This was indicative of
reports from many users in #suse over the past couple of weeks. Many of them
report the same symptoms.

Now, knowing the mirror is good and knowing that in rug the progress indicator
when adding a ZYPP source is broken ( <hint> a *working* progress indicator
for rug when adding ZYPP sources would be an improvement by orders of
magnitude I cannot convey in written text </hint> ) I asked the user to add
the same repository as a YUM source, knowing the progress indicator for YUM
actually works ( <hint> Oh wait, this one works ;) </hint> ) I was quite
suprised to discover just how slow his download of the catalog meta data was
adding a YUM source.

[09:14] * spyderous watches '13.0 bytes/s'
[09:19] <cenuij> spyderous: your mirror is on your campus yeah?
[09:21] <spyderous> cenuij: yeah, i get 1+M/s downloads
[09:21] <cenuij> and your attached to the campus network with a 100Mbit/sec
[09:24] <spyderous> cenuij: sorry, yeah i am. didn't see what you said
[09:27] <cenuij> spyderous: ok one more thing if you dont mind please :) could
you try a wget on inst-source/suse/repodata/filelists.xml.gz ?
[09:28] <spyderous> 42% [===============> ] 7,363,246
1.31M/s ETA 00:08

So, on a 100Mbit/sec LAN/WAN connection the update stack was transfering the
repo metadata at a staggering 13.0 bytes/s and from the same repo he was able
to transfer metadata at 1.31M/s

I understand this is not scientific, or conclusive and other factors may be at
work here but we were able to reproduce the same symptoms and slow transfer
using the update stack. Eventually he was able to add the main installation
repo, I asked him how long it took; "20-30 minutes".

I asked the user to file a bug report, hopefull he will. Of course if anyone
has time to test this or profile whatever network aware part of the update
stack may be causing this...

Cheers the noo


< Previous Next >
This Thread