Anders Patches for Zen/Zmd, et al
Largely on Anders recommendation I upgraded my 10.1 instalation software from his directory ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/rpm/i586 and turned zmd back on. Today my 9.3 machine and my 10.1 machine both at to apply changes to a single issue (ethereal). Both succeeded. 9.3 using YOU completed in 1 Minute 39 seconds 10.1 using zmd completed in 14 Minutes and 15 seconds. Both installed only the one ethereal patch. Both using the same cable modem. In my book, that counts as still broken. -- _____________________________________ John Andersen
On Tuesday 05 September 2006 06:00, John Andersen wrote:
Largely on Anders recommendation I upgraded my 10.1 instalation software from his directory ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/rpm/i58 6 and turned zmd back on.
While we share initials, that directory belongs to Andreas Jäger, not to me. I also have nothing to do with the patches
Both succeeded. 9.3 using YOU completed in 1 Minute 39 seconds 10.1 using zmd completed in 14 Minutes and 15 seconds.
Both installed only the one ethereal patch. Both using the same cable modem.
In my book, that counts as still broken.
Did you happen to notice where the time was spent?
On Monday 04 September 2006 21:06, Anders Johansson wrote:
On Tuesday 05 September 2006 06:00, John Andersen wrote:
Largely on Anders recommendation I upgraded my 10.1 instalation software from his directory ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/rpm/i 58 6 and turned zmd back on.
While we share initials, that directory belongs to Andreas Jäger, not to me. I also have nothing to do with the patches
Ah, sorry for that, It was your recommendation, on this list, so I jumped to the conclusion it was your directory. My bad.
Both succeeded. 9.3 using YOU completed in 1 Minute 39 seconds 10.1 using zmd completed in 14 Minutes and 15 seconds.
Both installed only the one ethereal patch. Both using the same cable modem.
In my book, that counts as still broken.
Did you happen to notice where the time was spent?
Well, in 9.3 the greatest amount of time was spent setting up the linker cache.... oh, sorry, you mean in 10.1 I bet.... Since 10.1 give so little in the way of progress reports its hard to say. There was several minutes before any patches appeared in the window after clicking the task bar icon. After the patch did appear there was a significant period of high cpu utilization, where it appeared to be determining the packages needed and applying the change, but I did not pay close attention. Probably this section was 5 minutes. Then another long period where it said "finishing". I think finishing lasted at least 3 minutes. But, I gotta ask, if you have nothing to do with the patches why the interest in time spent in various stages? -- _____________________________________ John Andersen
On Tuesday 05 September 2006 07:31, John Andersen wrote:
But, I gotta ask, if you have nothing to do with the patches why the interest in time spent in various stages?
I have an interest in seeing it fixed once and for all, and that sort of information is what the developers need, so they know where to spend energy. It belongs in bugzilla
On Tue, 2006-09-05 at 08:05 +0200, Anders Johansson wrote:
On Tuesday 05 September 2006 07:31, John Andersen wrote:
But, I gotta ask, if you have nothing to do with the patches why the interest in time spent in various stages?
I have an interest in seeing it fixed once and for all, and that sort of information is what the developers need, so they know where to spend energy. It belongs in bugzilla
Seeing as it's going to be in future releases one way or the other, I'd like to see it work smoothly as well.
John Andersen wrote:
But, I gotta ask, if you have nothing to do with the patches why the interest in time spent in various stages?
For one thing, they didn't even bother to include delta rpm support in rug/zmd. This means that your 10.1 machine had to download 8 megabytes, rather than 1.2 megabytes. This is another reason to use fou4s on 10.1 machines, it support delta rpms.
On Tue, Sep 05, 2006 at 12:15:55PM -0400, suse@rio.vg wrote:
John Andersen wrote:
But, I gotta ask, if you have nothing to do with the patches why the interest in time spent in various stages?
For one thing, they didn't even bother to include delta rpm support in rug/zmd. This means that your 10.1 machine had to download 8 megabytes, rather than 1.2 megabytes.
This is another reason to use fou4s on 10.1 machines, it support delta rpms.
YOU will support it soon. (with next package manager update). ZMD/RUG will follow :/ Ciao, Marcus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-09-05 at 12:15 -0400, suse@rio.vg wrote:
For one thing, they didn't even bother to include delta rpm support in rug/zmd. This means that your 10.1 machine had to download 8 megabytes, rather than 1.2 megabytes.
That's true, but the delta rpms have to be processed and expanded or reconstructed, and that is a slow process, probably slower than the download on wideband. After that, the reconstructed rpm has to be installed. I also guess that the process on 10.1 with "narrow band" is slower before starting the real download, but I can't be sure. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFE/ezVtTMYHG2NR9URAijHAJ4nZvU/p2TsuBkf83X1PQdI8+ayGgCdEG/5 pHAmJKa2puQMNRWVxC7w0hs= =sbo8 -----END PGP SIGNATURE-----
Anders Johansson
On Tuesday 05 September 2006 06:00, John Andersen wrote:
Largely on Anders recommendation I upgraded my 10.1 instalation software from his directory ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/rpm/i58 6 and turned zmd back on.
While we share initials, that directory belongs to Andreas Jäger, not to me. I also have nothing to do with the patches
Andreas J*ae*ger ;-)
Both succeeded. 9.3 using YOU completed in 1 Minute 39 seconds 10.1 using zmd completed in 14 Minutes and 15 seconds.
Both installed only the one ethereal patch. Both using the same cable modem.
In my book, that counts as still broken.
We're working on improving this. 10.1 does more than 9.3 did, so it takes longer - but it shouldn't be that bad. I expect 10.2 to see further speed-ups. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
We're working on improving this. 10.1 does more than 9.3 did, so it takes longer - but it shouldn't be that bad. I expect 10.2 to see further speed-ups.
"further speed-ups" meaning it will take 10 minutes instead of 15? That would be a major speed up, but still broken. Do you believe there is room in rug/zmd's current design that will allow for an order of magnitude increase in speed? I'm not seeing it. Aside from delta rpm support (which would greatly reduce the download time), you're still doing complete repodata updates on every wake up and every package install. You need to re-think the design to separate repodata updates and package installs. There's a reason systems like apt do this. When you don't have a top of the line machine connected via lan to the repo, updates are incredibly expensive.
On Tuesday 05 September 2006 18:26, suse@rio.vg wrote:
Andreas Jaeger wrote:
We're working on improving this. 10.1 does more than 9.3 did, so it takes longer - but it shouldn't be that bad. I expect 10.2 to see further speed-ups.
"further speed-ups" meaning it will take 10 minutes instead of 15? That would be a major speed up, but still broken.
Can you participate in a discussion without using inflammatory language? You're saying the same things over and over, which only serves to annoy people. People know it's not good the way it is, people know it's too slow, people know you're pissed off about it. Alright?
Do you believe there is room in rug/zmd's current design that will allow for an order of magnitude increase in speed?
There is a difference between design and implementation. You don't seem to want to understand this. A design can be correct even if the implementation is broken
I'm not seeing it.
Then again, you haven't looked at the code, have you
Aside from delta rpm support (which would greatly reduce the download time), you're still doing complete repodata updates on every wake up and every package install.
This would be a typical example of something which is implementation, and not design More things need to be cached, and not recalculated at each step. This is an example of an implementation improvement
On Tuesday 05 September 2006 07:59, Anders Johansson wrote: sniiiiip
Aside from delta rpm support (which would greatly reduce the download time), you're still doing complete repodata updates on every wake up and every package install.
This would be a typical example of something which is implementation, and not design
This SHOULD be a typical DESIGN built in from the START. To not incorporate such established, major speed feature is suicidal at best...
More things need to be cached, and not recalculated at each step. This is an example of an implementation improvement
sniiip
suse@rio.vg writes:
Andreas Jaeger wrote:
We're working on improving this. 10.1 does more than 9.3 did, so it takes longer - but it shouldn't be that bad. I expect 10.2 to see further speed-ups.
"further speed-ups" meaning it will take 10 minutes instead of 15? That would be a major speed up, but still broken.
Do you believe there is room in rug/zmd's current design that will allow for an order of magnitude increase in speed? I'm not seeing it. Aside from delta rpm support (which would greatly reduce the download time), you're still doing complete repodata updates on every wake up and every package install.
The teams have some ideas to avoid these complete repodata updates. And note: We do not download the complete repo, just fill the database.
You need to re-think the design to separate repodata updates and package installs. There's a reason systems like apt do this. When you don't have a top of the line machine connected via lan to the repo, updates are incredibly expensive.
This is fixed already with the previous official update, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tuesday 05 September 2006 02:15, Andreas Jaeger wrote:
We're working on improving this. 10.1 does more than 9.3 did, so it takes longer - but it shouldn't be that bad. I expect 10.2 to see further speed-ups.
Well I ripped out the prior version, but this one seems to do well enough that I am leaving it in. The slowness of updates is an annoyance, but since updates are not that frequent, and since I subscribe to Secunia Security Advisories I usually have an idea of how soon I need to apply the patches. The odd part is how long Yast takes if I leave the Zen/Zmd packages in. Just going in to install another package from the DVD takes a huge amount of time. A lot of this time is while its reading the package list. (For the record I don't actually have the DVD mounted, I just put the ISO image on disk). Maybe thats a problem? -- _____________________________________ John Andersen
Dňa St 6. September 2006 06:04 John Andersen napísal:
On Tuesday 05 September 2006 02:15, Andreas Jaeger wrote:
We're working on improving this. 10.1 does more than 9.3 did, so it takes longer - but it shouldn't be that bad. I expect 10.2 to see further speed-ups.
Well I ripped out the prior version, but this one seems to do well enough that I am leaving it in.
The slowness of updates is an annoyance, but since updates are not that frequent, and since I subscribe to Secunia Security Advisories I usually have an idea of how soon I need to apply the patches.
The odd part is how long Yast takes if I leave the Zen/Zmd packages in.
Do you mean that if you uninstall Zen/Zmd packages, YaST gets faster?
Just going in to install another package from the DVD takes a huge amount of time. A lot of this time is while its reading the package list. (For the record I don't actually have the DVD mounted, I just put the ISO image on disk). Maybe thats a problem?
This can be analyzed from the YaST logs. Feel free to report a bug and attach the y2log files. Stano
On Tuesday 05 September 2006 23:52, Stanislav Visnovsky wrote:
The odd part is how long Yast takes if I leave the Zen/Zmd packages in.
Do you mean that if you uninstall Zen/Zmd packages, YaST gets faster?
Thats my perception, yes. I'd have to un-install them all again to give you comparative times. -- _____________________________________ John Andersen
Dňa St 6. September 2006 10:11 John Andersen napísal:
On Tuesday 05 September 2006 23:52, Stanislav Visnovsky wrote:
The odd part is how long Yast takes if I leave the Zen/Zmd packages in.
Do you mean that if you uninstall Zen/Zmd packages, YaST gets faster?
Thats my perception, yes. I'd have to un-install them all again to give you comparative times.
Would be great. Just make sure you have cold cache. Reading the currently installed packages is much quicker if the data are in memory cache already. Stano
participants (10)
-
Anders Johansson -
Anders Johansson -
Andreas Jaeger -
Carlos E. R. -
John Andersen -
kanenas＠hawaii.rr.com -
Marcus Meissner -
Mike McMullin -
Stanislav Visnovsky -
suse＠rio.vg