lubuntu-qa team mailing list archive

[alan c <aeclist@xxxxxxxxxxxxxxxxxx>]

On 04/03/12 21:51, alan c wrote:
> (new team member here......)
> 
> I had a Pentium II - 400 PC  holding up some shelves (literally) and
> heard the call for low spec PCS.
> 
> Am I correct in thinking that the PII chipset will necessarily be non
> pae? And is the objective of this sort of test that the Lubuntu kernel
> is pae compatible, and does it work on the ancient PCs?
> 
> My PII 400Mhz Pc was running Ubuntu 7.04 (and win 98) using 281MB RAM
> total, and I reduced that to
> 128MB (PC133, CL3) ram for the test.
> 
> I used  a 32 bit  alternate CD Lubuntu beta1, and the CD self check in
> the PC passed ok, verifying also the CD drive.
> 
> I used manual directed install, continuing the PC existing
> configuration as a dual boot with Windows 98. Wired ethernet.
> 
> The install went quite normally as far as I could see.
> 
> This install process took about 2 hours 10 minutes.
> 
> The PC then booted ok, took just over 3 minutes to get to login
> request and a further 5 or so minutes to show a completed desktop.
> Subsequent startups might possibly go faster, I have not yet tried that.
> 
> However, a very significant thing occurred soon after startup and this
> was that, for a solid two and half hours, the PC was almost literally
> un usable because of a constant activity.
> 
> My guess is that it was maybe an indexing of updates status, I am not
> sure. However, I managed to view task manager and for the whole of
> this period the CPU as maxed at 100%, the memory indication was almost
> constant at 109MB out of 116MB indicated, and the hard drive access
> light was full on with obvious continuous hard drive activity.
> 
> After the two and half hours it fell away and the quiescent values are
> cpu 3%, memory 53MB of 116MB.
> 
> A rapid  and continuous movement of the mouse cursor takes the cpu up
> to near 30% - this is the low resource machine speaking of course.
> 
> What struck me was how impractical it would be to attempt an install
> in this machine with any normal expectations of the post install
> situation, or maybe other tasks also.
> I have not yet attempted updates but it would sensibly be an overnight
> job.
> 
> I wonder if there is a way of reducing the priority of the update (?
> if that is what it is) indexing here?  Or maybe giving (me) some
> control over when the indexing is to be done, or its priority.
> Intuitively, the machine is not usable at this stage. So, many users
> would simply write it off. I do not know if  more ram will help, it is
> something  for later?
> 
> I have not done further checks such as confirm that the swap partition
> is in place and apparently normal, but the install configuration
> seemed ok. Swap is (should be) 370MB.
> 
> Summary so far: it does install ok, but the resources are totally
> consumed for hours  initially following install and re start.
> 
> Other timings after the initial dust has settled:
> 
> File manager appears in 13 seconds (cpu 100%)
> web browser chrome 1 min 42 initial  startup and 1 min subsequent.
> Most of this time seems to be spent getting the Google sign up pages
> ready, because the homepage (now set to www.google.co.uk) refreshes in
> 6 seconds by itself. If Google  encumber chrome browser with a
> crapware sign up log in page, then in a PC like this is it a lead
> balloon. Of course, maybe the user wants to sign in, but this is a low
> resource PC and could be on a low speed network etc. (?)  I dont know
> how firefox runs in these conditions yet.
> 
> I do not know enough about chrome browser to know yet how to make it
> remember  that I do *not* want to be asked to sign in.

Further:
Chrom browser now accepts  use without a sign on.
With no sign in screen, just a home page of www.google.co.uk,  it
starts in 55 seconds.
(then a subsequent search in google for distrowatch, then)
 going to distrowatch took about 45 seconds, again cpu limited I think.
Generally this machine looks as if it is cpu limited.

-- 
Ubuntu user #10391
Linux user #360648