[osol-discuss] [pkg-discuss] [on-discuss] ON/SXCE bi-weekly schedule not valid anymore?

[Enda O'Connor]

Hi
Just so that people are aware starting in s10 update 8, or applying a 
few patches to existing system, a new feature called turbo packaging is 
being introduced, which will improve any long running packaging 
operations, ie install, upgrade, zone creation etc, not so much for 
patching.
6820054 Turbocharged SVr4 package commands [PSARC 2009/173]

Enda


Mike Gerdts wrote:
> On Tue, Aug 25, 2009 at 3:27 PM, <johansen at sun.com> wrote:
>> On Tue, Aug 25, 2009 at 12:21:18PM +0100, Peter Tribble wrote:
>>> It's not just search that's slow - most pkg operations feel slow.
>> How about providing some data instead of wild accusations?
>>
>> I can install entire, SUNWcs & SUNWcsd, and babel_install all in under 7
>> minutes on a 100mbit network.  Are you using modern hardware?
> 
> Silly example, but is representative of something that needs to be
> done from time to time.
> 
> Solaris 10:
> 
> $ uname -srvi
> SunOS 5.10 Generic_141414-02 SUNW,SPARC-Enterprise-T5120
> 
> $ ptime grep -w ls /var/sadm/install/contents
> [snip]
> real        2.771
> user        2.653
> sys         0.115
> 
> OpenSolaris:
> 
> $ uname -srvi
> SunOS 5.11 snv_111b SUNW,SPARC-Enterprise-T5120
> 
> $ ptime pkg search -l ls
> [snip]
> real       34.130866085
> user       30.690454076
> sys         0.774897050
> 
> My experience with hardware that I can order from Sun today says that
> the new software takes 12x longer for equivalent tasks.  There is a
> very high startup cost with pkg that does not exist with pkgadd.  With
> pkgadd I don't think too far ahead to be sure to group as many
> operations into one invocation as possible.  When I use pkg, I most
> certainly try to lump as many operations as possible into each
> invocation to avoid this startup penalty.
> 
> In balance, I believe that with a local repo, installation of large
> images will be faster with pkg than with pkgadd.  Hopefully it is
> competitive with installation via flash archives.  Even when upgrading
> across the internet, pkg image-update is way faster than luupgrade.
> 
> When I look at the publicly disclosed/speculated road map for CMT
> systems, I don't see things improving for the simple operations
> without fixing the software.  I eagerly await the SAT solver and any
> other improvements that are in the works.
> 
> Right now I'm not complaining - I know the software is young and the
> primary development platform is x86 where the regression isn't so
> apparent.  Once I start hearing that there aren't big performance
> improvements coming, I will start opening support calls if the
> performance is still worse than before.
>