I have 64bit Debian and I did:
$ wget http://sagemath.org/SAGEbin/linux/64bit/sage-2.10.2-debian-64bit-intel-x86_64-Linux.tar.gz
$ tar xzf sage-2.10.2-debian-64bit-intel-x86_64-Linux.tar.gz
$ ln -s sage-2.10.2-debian-64bit-intel-x86_64-Linux/ sage
$ cd sage
| SAGE Version 2.10.2, Release Date: 2008-02-22 |
| Type notebook() for the GUI, and license() for information. |
The SAGE install tree may have moved.
Regenerating Python.pyo and .pyc files that hardcode the install PATH
(please wait less than a minute)...
Please do not interrupt this.
/home/ondra/ext/sage/local/bin/sage-sage: line 149: 18575 Alarm clock
Setting permissions of DOT_SAGE directory so only you can read and write it.
Exiting SAGE (CPU time 0m0.00s, Wall time 2m2.75s).
Exiting spawned Gap process.
Notice the "Alarm clock" line. What does that mean?
This is in sage-location:
This is *stupid*. It's doing a process that really really better not
get interrupted, and it's
interrupting itself if it takes more than 6 minutes. I can't imagine
what idiot wrote such
... oh wait, that was me. I think that was in there right when that
code was first written,
mainly for debugging purposes when I was doing some testing. Anyway... didn't
David Harvey say something in irc about all my old code being
"impatient" -- I guess
this is a prime example of that!
Anyway, fix up at trac #2311:
> > Setting permissions of DOT_SAGE directory so only you can read and write it.
> > sage:
> > Exiting SAGE (CPU time 0m0.00s, Wall time 2m2.75s).
> > Exiting spawned Gap process.
> > Notice the "Alarm clock" line. What does that mean?
> > Ondrej
Associate Professor of Mathematics
University of Washington
Evidently. sage-location opens and closes a *lot* of files, so on a
it could take a long time. Maybe he's using NFS over 10Mbps ethernet? :-)
T'ain't in the Sage source; it's in libc (it's been there since I was
a lad :-}). It means that someone called 'alarm(3)', and it sprung.
Justin C. Walker, Curmudgeon-at-Large
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email
Hey Michael - let's make a bet. I'll create an ssh account for you on
my box (well maintained Debian amd64 unstable running on Intel Quad
Core, it for example compiles the latest kernel in 10 minutes). You'll
investigate. If it's a stupidly misconfigured Debian on my side,
I'll write to my blog, that I am lame and I still have a lot of things
to learn from Michael. However, if it turns it's a bug in Sage,
you'll write you your blog, that you are lame. :) Which is a very
fair offer, because my blog is synced to planet.debian.org,
while your blog is only synced to planet.sagemath.org. :)
Well, I think I know where the problem is. XFS sucks. Badly.
I tried it on ext3, and it's like 15 seconds. I did experiment with
different kernels, and the
latest kernel that work reasonably fast with XFS is 2.6.16 or 2.6.17
and that's because of the
nobarrier option, which is used like this:
/dev/sda3 /home xfs defaults,nobarrier 0 2
This was default in older kernels. I have the nobarrier option on my
laptop with 2.6.24 and it is indeed faster, but not that much (like 3
minutes or something). I know I was discussing this with Michael on
IRC regardig unpacking a Debian base image, when I am testing Debian
It's super fast on ext3, and a lot slower on XFS with nobarrier and
extremely slow on XFS without nobarrier, which is the default on
Here are some pages I did half a year ago regarding this issue:
I think I'll have to blog about this to get it more publicity, because
this is a show stopper for XFS - it's 20x slower than ext3 by default.
Also this message gives some background about this problem:
They say it safer to enable barrier support.
Actually, it's not that bad for XFS (yet). This command fixes the
mount -o remount,rw,nobarrier /dev/sda3 /home/
Now the first "./sage" run takes 15s on that computer. Unfortunately,
on my laptop with nobarrier option, it still takes 5 minutes, don't
know why. "dstat" on my laptop shows that the write speed oscillates
between 15MB/s and 1MB/s, more the latter than the former (if it was
15MB/s all the time, all would be ok). Unfortunately, the only spare
partition on my laptop is the 2GB swap (yes I am lame indeed, I should
have created more), but I just reformatted it to ext3, tried "./sage"
on it and: 26s. Well, I am moving from xfs to ext3 on my laptop.
Anyway, I'll turn this into the blog. It's defenitely not a bug in
Sage. If it's a serious misconfiguratin on my side, that I am using
default settings with XFS, well, that's discutable too. :)