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 connection? [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 Graham --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
