4.6 build - Atlas fails on Ubuntu 10.10 on amd turion X2 laptop

[RegB]

I know this is a modest laptop, but it seems to be in the tuning
section that the Atlas install fails after 12 hours or so.

Here is the last section (STAGE-2) of the install.log;
========================================================================

IN STAGE 2 INSTALL: TYPE-DEPENDENT TUNING


STAGE 2-1: TUNING PREC='d' (precision 1 of 4)


STAGE 2-1-1 : BUILDING BLOCK MATMUL TUNE
make -f Makefile INSTALL_LOG/dMMRES pre=d 2>&1 | ./xatlas_tee
INSTALL_LOG/dMMSEARCH.LOG
The best matmul kernel was ATL_dmm6x1x60_sse2_32.c, NB=60,
written by R. Clint Whaley
Performance: 3776.81MFLOPS (179.85 percent of of detected clock
rate)
(Gen case got 1903.74MFLOPS)
make -f Makefile INSTALL_LOG/dNCNB pre=d 2>&1 | ./xatlas_tee
INSTALL_LOG/dMMSEARCH.LOGmake -f Makefile INSTALL_LOG/dbestNN_60x60x60
pre=d nb=60 2>&1 | ./xatlas_tee INSTALL_LOG/dMMSEARCH.LOG
NCgemmNN : muladd=1, lat=4, pf=512, nb=60, mu=1, nu=5 ku=60,
ForceFetch=0, ifetch=5 nfetch=1
Performance = 415.11 (10.99 of copy matmul, 19.77 of
clock)
make -f Makefile INSTALL_LOG/dbestNT_60x60x60 pre=d nb=60 2>&1 | ./
xatlas_tee INSTALL_LOG/dMMSEARCH.LOG NCgemmNT : muladd=1, lat=4,
pf=512, nb=60, mu=1, nu=5 ku=60,
ForceFetch=0, ifetch=5 nfetch=1
Performance = 1525.73 (40.40 of copy matmul, 72.65 of
clock)
make -f Makefile INSTALL_LOG/dbestTN_60x60x60 pre=d nb=60 2>&1 | ./
xatlas_tee INSTALL_LOG/dMMSEARCH.LOG NCgemmTN : muladd=1, lat=4,
pf=512, nb=60, mu=1, nu=5 ku=1,
ForceFetch=0, ifetch=5 nfetch=1
Performance = 1799.89 (47.66 of copy matmul, 85.71 of
clock)
make -f Makefile INSTALL_LOG/dbestTT_60x60x60 pre=d nb=60 2>&1 | ./
xatlas_tee INSTALL_LOG/dMMSEARCH.LOG NCgemmTT : muladd=1, lat=5,
pf=512, nb=60, mu=1, nu=5 ku=1,
ForceFetch=0, ifetch=5 nfetch=1
Performance = 463.55 (12.27 of copy matmul, 22.07 of
clock)
make -f Makefile MMinstall pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/
dMMSEARCH.LOG


STAGE 2-1-2: CacheEdge DETECTION
make -f Makefile INSTALL_LOG/atlas_cacheedge.h pre=d 2>&1 | ./
xatlas_tee INSTALL_LOG/dMMCACHEEDGE.LOG


STAGE 2-1-3: LARGE/SMALL CASE CROSSOVER DETECTION


STAGE 2-1-3: COPY/NO-COPY CROSSOVER DETECTION
make -f Makefile INSTALL_LOG/dXover.h pre=d 2>&1 | ./xatlas_tee
INSTALL_LOG/dMMCROSSOVER.LOG
done.


STAGE 2-1-4: LEVEL 3 BLAS TUNE
make -f Makefile INSTALL_LOG/atlas_dtrsmXover.h pre=d 2>&1 | ./
xatlas_tee INSTALL_LOG/dL3TUNE.LOG
make -f Makefile dcblaslib 2>&1 | ./xatlas_tee INSTALL_LOG/dL3TUNE.LOG
done.


STAGE 2-1-5: GEMV TUNE
make -f Makefile INSTALL_LOG/dMVRES pre=d 2>&1 | ./xatlas_tee
INSTALL_LOG/dMVTUNE.LOG
make[3]: *** [build] Error 255
make[3]: Leaving directory `/home/reg/Downloads/sage-4.6/spkg/build/
atlas-3.8.3.p16/ATLAS-build'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/home/reg/Downloads/sage-4.6/spkg/build/
atlas-3.8.3.p16/ATLAS-build'
Failed to build ATLAS.
ATLAS failed to build for the 1-th time, possibly because of a
loaded system, so we will automatically try again up to 4 more times.
Waiting 12 minutes...
ATLAS failed to build for the 2-th time, possibly because of a
loaded system, so we will automatically try again up to 3 more times.
Waiting 11 minutes...
ATLAS failed to build for the 3-th time, possibly because of a
loaded system, so we will automatically try again up to 2 more times.
Waiting 5 minutes...
ATLAS failed to build for the 4-th time, possibly because of a
loaded system, so we will automatically try again up to 1 more times.
Waiting 9 minutes...
Too many failures to build ATLAS. Giving up!

real 766m39.838s
user 686m45.420s
sys 17m38.250s
sage: An error occurred while installing atlas-3.8.3.p16
Please email sage-devel
explaining the problem and send the relevant part of
of /home/reg/Downloads/sage-4.6/install.log. Describe your computer,
operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/reg/Downloads/sage-4.6/spkg/build/atlas-3.8.3.p16 and type 'make
check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/home/reg/Downloads/sage-4.6/spkg/build/atlas-3.8.3.p16' && '/
home/reg/Downloads/sage-4.6/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/atlas-3.8.3.p16] Error 1
make[1]: Leaving directory `/home/reg/Downloads/sage-4.6/spkg'

real 790m11.981s
user 702m18.290s
sys 20m48.510s
Error building Sage.
===========================================================================
This is on Ubuntu 10.10 Linux that had been updated via Update Manager
and Synaptics Package manager only minutes earlier.
I think all the pre-reqs were met.

The whole install log is about 28Meg..... can't see posting THAT (-:

[RegB]

WOW, that was quick - THANKS.
I reviewed all of those and while interesting/useful they seem to be
not applicable to this particular failure.

I had meant to say that on previous attempts I had discovered the need
for a fortran compiler and to disable cpu throttling. Also the
desirability of installing LaTeX, so I did those.
This is a very lightly loaded system, i,e, it is my personal laptop
and about the only other thing it was doing at the time of failure was
running Firefox with 1/2 dozen tabs open.

Thanks again, I will try it all over again.

Minh Nguyen wrote:
> Hi,

>
> On Sat, Nov 6, 2010 at 12:30 AM, RegB <2regb...@earthlink.net> wrote:
> > I know this is a modest laptop, but it seems to be in the tuning
> > section that the Atlas install fails after 12 hours or so.
>

> You might want to read this section of the Sage FAQ:
>
> http://www.sagemath.org/doc/faq/faq-usage.html#when-i-compile-sage-my-computer-beeps-and-shuts-down-or-hangs
>
> --
> Regards
> Minh Van Nguyen

[mhampton]

Depending on what those Firefox tabs were, they could have put a
significant load on your CPU (Flash ads for example) or used enough
memory to make atlas work too hard. It would be interesting to know
if it works if you aren't running anything else.

What is your processor and amount of RAM?

-M. Hampton

On Nov 5, 9:12 am, RegB <2regburg...@earthlink.net> wrote:
> WOW, that was quick - THANKS.
> I reviewed all of those and while interesting/useful they seem to be
> not applicable to this particular failure.
>
> I had meant to say that on previous attempts I had discovered the need
> for a fortran compiler and to disable cpu throttling.  Also the
> desirability of installing LaTeX, so I did those.
> This is a very lightly loaded system, i,e, it is my personal laptop
> and about the only other thing it was doing at the time of failure was
> running Firefox with 1/2 dozen tabs open.
>
> Thanks again, I will try it all over again.
>
> Minh Nguyen wrote:
> > Hi,
>

> > On Sat, Nov 6, 2010 at 12:30 AM, RegB <2regburg...@earthlink.net> wrote:
> > > I know this is a modest laptop, but it seems to be in the tuning
> > > section that the Atlas install fails after 12 hours or so.
>
> > You might want to read this section of the Sage FAQ:
>

> >http://www.sagemath.org/doc/faq/faq-usage.html#when-i-compile-sage-my...

[RegB]

Thanks,
I have ads blocked, fairly sure that none were playing any U-tube or
other graphics,
no adobe flash.
Looking at System monitor, barely a Gig of memory is being used and
swap is NOT
being used at all. There is 4 Gig of ram.
CPU #2 is running at 100% most of the time during the atlas build, CPU
#1 sometimes
goes to 96% at the same time that #2 is at 100% - so I'm GUESSING that
Atlas is
CPU bound and I assume it SHOULD BE during the timing tests ?

I'm trying to find out what the Atlas build errors 2 and 255 mean,
hopefully that
will lead me somewhere ? (-:

[Mike Witt]

I wonder if you might have run into whatever problem I had on
my Acer machine. It's documented in:

http://ask.sagemath.org/question/107/building-atlas

I never did find out what the problem was.

-Mike

[RegB]

Well, I'm certainly under qualified to evaluate your thread (-:
It would SEEM that you were getting error messages that
said the flags to the compiler were wrong/inappropriate (GUESSING) ?
I got specific tune errors 2 and 255.
I'm not saying they don't have some common cause, just that the
symptoms
seem so different.
What little I've read over the last day or three (a long day) suggests
to me
that ATLAS is complex and requires quite a bit of specialised
knowledge about IT as well as all the tools that build it.
Thanks for the feedback, { I had meant to open with that comment (-:}

[Dr. David Kirkby]

On 11/ 5/10 05:38 PM, mhampton wrote:
> Depending on what those Firefox tabs were, they could have put a
> significant load on your CPU (Flash ads for example) or used enough
> memory to make atlas work too hard. It would be interesting to know
> if it works if you aren't running anything else.
>
> What is your processor and amount of RAM?
>
> -M. Hampton

I've not managed to build ATLAS on any single virtual machine on my Sun. That
has a 3.33 GHz Xeon and 12 GB RAM, so should not be troubled by CPU load. I've
tried allocating one CPU, and allocating more to the virtual machine, but still
no joy.

I think there's a way to increase the amount of time spent on the timing loops,
so that the overall result is less perturbed to short term changes in the system
load. But I could never quite work out how to pass the compiler option to the
ATLAS configure script.

There is probably some advantage in having some of the ATLAS parameters
configurable by Sage environment variables. In particular, spending longer on
the timing tests might help in cases where there is too much uncertainty on
results.

Dave

[Volker Braun]

You can try my new atlas spkg at http://trac.sagemath.org/sage_trac/ticket/10226
if you have a minute.

SAGE_ATLAS_ARCH=HAMMER,SSE3,SSE2,SSE1
export SAGE_ATLAS_ARCH
sage -f atlas-3.8.3.p17.spkg

or just save the new spgk in SAGE_ROOT/spkg/standard/

Volker

[Andrey Novoseltsev]

This may be related:

I also regularly (although not deterministically) have troubles with
ATLAS on a Turion x2 notebook. I has 4Gb RAM, but I am running Ubuntu
10.4 in VirtualBox with 1.5Gb and one CPU core accessible to it. It
always takes forever to build ATLAS on it and often it crashes. Since
I mostly work on other computers anyway, I don't get too concerned and
just repeat make or sage -upgrade when it happens, usually it
helps ;-) It also seems to me that mistakes happen only if I DON'T use
the computer at all (including host OS) while the build goes, but I am
not sure.

Thank you,
Andrey

[RegB]

I would like to try that.
I will report back results (good or bad).
Is there any info you would like me to collect from good/bad results ?
Thanks.

On Nov 5, 7:24 pm, Volker Braun <vbraun.n...@gmail.com> wrote:
> You can try my new atlas spkg athttp://trac.sagemath.org/sage_trac/ticket/10226

[RegB]

I get confused with the directions about running in virtual box (-:
I think it should be OK and very possible to create virtual
machines, say within virtual box within Windows Vista and install
Linux in those VMs , then go ahead and install Sage on the Linux.
i.e. (Windows Vista (Virtual Box(UBUNTU 10.10(Sage))))
Now the Linux doesn't have anything LIKE a wall clock, so I
would have to ASSUME that Atlas would blow itself up
on the timing, other than that I see no GOOD reason to not put
ANY pre-built sage in a virtual machine within Virtual Box.
I may try that if/when I get a good build under UBUNTU 10.10

SO FAR my build with atlas-3.8.3.p17 is running successfully,
it has gone WAY past the Atlas install.

[RegB]

So far that is working, i.e. Atlas has completed and no other packages
seem to have tripped over any side effects.
Thanks again.

On Nov 5, 7:24 pm, Volker Braun <vbraun.n...@gmail.com> wrote:

> You can try my new atlas spkg athttp://trac.sagemath.org/sage_trac/ticket/10226

[RegB]

Update:
Since my last update;
The Atlas problem seemed to have been fixed with the atlas-3.8.3.p17
spkg, however I ran into more trouble later with matplotlib-1.0.0
and that sent me off on a course of enquiry that led me to try
building
each component separately; BLAS, NUMPY, PYTHON, ATLAS, etc.
At one point I gave up and downloaded a pre-built binary.

I got back to building on friday and I am HAPPY to announce that
I have successfully built and tested SAGE in the Linux partition AND
in a virtual box under Windows Vista.
This is with the original atlas-3.8.3.p16 from the tarball.

This is probably documented somewhere and in any case I should
have taken it as implicit that one needs to be ROOT to do the build.
{perhaps in formal terms I should say one needs to have root acting
on one's behalf, i.e. $sudo su on Ububtu/Debian}
That was sufficient on the standalone Linux partition.

In the Virtual box it SEEMS to be necessary to give the virtual
machine
more than 1 Gig of memory.
Although I haven't found the limit 2,961 Meg has worked here.
Virtual Box would not allow me to devote more than 75% of the physical
machine's memory and I only have 4 Gig.

Also it is not necessary to disable CPU throttling in the virtual
machine.
I can speculate why, but Atlas reports that it cannot detect
throttling.

[David Kirkby]

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

[David Kirkby]

Ignore what appears to be an empty message from me. I got a message
"Your message has been sent," but I don't recall pressing the "Send"
button.

On 21 November 2010 17:17, RegB <2regb...@earthlink.net> wrote:

> In the Virtual box it SEEMS to be necessary to give the virtual
> machine
> more than 1 Gig of memory.
> Although I haven't found the limit 2,961 Meg has worked here.
> Virtual Box would not allow me to devote more than 75% of the physical
> machine's memory and I only have 4 Gig.

I've never managed to get ATLAS to build on any virtual machine I've
used on my Sun Ultra 27. I'll try allocating it more memory and giving
it a try. I'm not at home, and are unaware of how much I have
allocated, but the machine has 12 GB of RAM, so it should be
sufficient to build an updated version.

Dave

[Jan Groenewald]

Hi

I had ATLAS fail to build from sage-3.6 running Ubuntu 10.04.1
on an HP Probook 4515s with and AMD CPU (yesterday).

Due to time pressure I installed a prebuilt binary instead.
Sorry, no more info.

regards,
Jan

--
.~.
/V\ Jan Groenewald
/( )\ www.aims.ac.za
^^-^^

[Karen Bindash]

Did you really mean Sage 3.6 or was you intending to write 4.6?

If you did mean 3.6, then the ATLAS package would have changed a lot
since Sage 3.6.

Dave

[pipedream]

Hi

On Dec 17, 11:52 am, Karen Bindash <karenbind...@googlemail.com>
wrote:

> Did you really mean Sage 3.6 or was you intending to write 4.6?

Woops. Yes, 4.6.

regards,
Jan

[Dima Pasechnik]

I have the same sort of issues with an old laptop with Pentium M CPU
(banias 1.1GHz, http://ark.intel.com/Product.aspx?id=27600)

Actually, I think the idea of re-running Altas install from scratch,
many times, as the spkg does, makes not too much sense. Googling that
issues shows that one should restart tuning phase if it fails (i.e.
just type make again), rather than restart the whole building process.
And indeed, I tried modifying Atlas spkg so that it does just this,
and it helped...

Dima

[Volker Braun]

The tuning is done in the "configure" script. I would have thought that if that fails and you run "make" then you'd just build ATLAS with broken timings. Do you have a reference? 

I'm still working on an updated ATLAS spkg that gives up automatic tuning after 2 tries and then proceeds to build with specific arch configurations. The latter can't fail but may not give the best performance.

[Dima Pasechnik]

On Dec 18, 7:58 pm, Volker Braun <vbraun.n...@gmail.com> wrote:
> The tuning is done in the "configure" script. I would have thought that if

No, I don't think so. Atlas's INSTALL.txt says:

"For the impatient, here is the basic outline:
**************************************************
mkdir my_build_dir ; cd my_build_dir
/path/to/ATLAS/configure [flags]
make ! tune and compile library
...."

And I actually had success with this....

> that fails and you run "make" then you'd just build ATLAS with broken
> timings. Do you have a reference?

can't find it now. But I'm pretty sure that's how it is.

[Dima Pasechnik]

PS. Actually, re-running make is supposed to take care of that
"VARIATION EXCEEDS TOLERENCE, RERUN WITH HIGHER REPS"
error message, IMHO...

[Dima Pasechnik]

On Dec 19, 7:22 pm, Dima Pasechnik <dimp...@gmail.com> wrote:

> On Dec 18, 7:58 pm, Volker Braun <vbraun.n...@gmail.com> wrote:> The tuning is done in the "configure" script. I would have thought that if
>
> No, I don't think so. Atlas's INSTALL.txt says:
>
> "For the impatient, here is the basic outline:
> **************************************************
>    mkdir my_build_dir ; cd my_build_dir
>    /path/to/ATLAS/configure [flags]
>    make              ! tune and compile library
> ...."
>
> And I actually had success with this....
>
> > that fails and you run "make" then you'd just build ATLAS with broken
> > timings. Do you have a reference?
>
> can't find it now.  But I'm pretty sure that's how it is.
>

http://math-atlas.sourceforge.net/errata.html#tol
It says that a restart is needed in this case.
Not from scratch, but as explained here:
http://math-atlas.sourceforge.net/errata.html#restart

So I wasn't completely right - this restart is even "warmer" than the
one I was proposing,
and certainly much "warmer" than reconfiguring from the very
beginning, as spkg does
currently.

Dima

[Dima Pasechnik]

> http://math-atlas.sourceforge.net/errata.html#tol
> It says that a restart is needed in this case.
> Not from scratch, but as explained here:http://math-atlas.sourceforge.net/errata.html#restart
>
> So I wasn't completely right - this restart is even "warmer" than the
> one I was proposing,
> and certainly much "warmer" than reconfiguring from the very
> beginning, as spkg does
> currently.
>

according to
http://sourceforge.net/tracker/?func=detail&aid=3068313&group_id=23725&atid=379483
this has been fixed in the newer Atlas (3.9.26)

[Alexey U. Gudchenko]

Sorry for my English,

I carried out some experiments, used the system reinstalation to excuse.

Configuration:
Ubuntu 10.10 with 2.6.35-23 kernel
2 GB of memory
AMD Athlon II X2 245

Processor clock frequency is on the "On demand" mode

$ cd /home/goodok/ta/sage-4.6
$ ./make

On about 0:43 minute I have the error while ATLAS was tuning
====
best cgemvT : ID=106, mu=1, nu=128 at 6748.29 MFLOPS
...
make[5]: *** [res/cMVRES]
...
ERROR 734 DURING MVTUNE!!. CHECK INSTALL_LOG/cMVTUNE.LOG FOR DETAILS.
====

Then, just in case, I went to the sage-4.6 directory so that the path
pointed to sage-4.6 do not contains any soft links.
(it was /home/goodok/ta --> /home/goodok/Tools-arsenal )

$ cd /home/goodok/Tools-arsenal/
$ rm -r sage-4.6
$ tar -xf sage-4.6.tar
$ cd sage-4.6

I run "./make" once more.
Installation ended with success.

./sage shell worked normally too.

Then I again remove "sage-4.6" dir and chage dir as at first case
$ cd /home/goodok/ta/
$ rm -r sage-4.6
$ tar -xf sage-4.6.tar
$ cd sage-4.6
$ ./make

Installation ended with success too.

So I decided it is independent of the file system links.
I suppose that the ATLAS tuning is unstable in random.
Or may be the screen saver GLMatrix has significance for this process.

16.12.2010 20:48, Jan Groenewald:

[Dima Pasechnik]

to install Atlas well, you should switch to "performance" CPU mode.
"On demand" might produce inconsistent timings during the tuning
stage.
http://math-atlas.sourceforge.net/atlas_install/atlas_install.html#SECTION00032000000000000000

[Alexey U. Gudchenko]

Thanks, I suspected of this too.

I will reinstall sage with this command

$ /usr/bin/cpufreq-selector -g performance
$ ./sage
$ /usr/bin/cpufreq-selector -g ondemand

21.12.2010 06:50, Dima Pasechnik пишет: