[developers] Re: [mt] updates on local Linux cluster

Stephan Oepen oe at csli.Stanford.EDU
Tue Apr 5 23:06:08 CEST 2005

hi again,

apparently running PET as an [incr tsdb()] client using Allegro CL 7.0
is, put mildly, unreliable.  dan reports:

> Thanks for setting up the PET machinery on the shiny new machines.  I made
> a few attempts to use ld for batch processing on the rondane data, but
> unfortunately the Lisp process eventually just goes into a terminal tail
> spin, silently spinning at full tilt for about three minutes and then
> dying equally silently.  I get about a third of the way through that
> data set, and it doesn't seem to matter whether I use one, two, or four
> CPUs (though I'm sure erik cared when I tried four) - same silent death.

i can reproduce the problem and believe that it is related to:


the foreign function wrapper to PVM manipulates static arrays at a very
low level.  specifially, it is using .array-total-size-limit. to check
for buffer limits.  i suspect what could be happening is exhaustion of
the (ACL) C heap, i.e. where with older ACL versions (and smaller array
limits) you would have seen the [incr tsdb()] error "PVM message buffer
overflow", you can now require up to 32 times more static space on the
Lisp side.  quite likely, our standard image layout (moving the C heap
way up to the top to allow maximum Lisp heap growth) is not up for such

i will want to look into this further, but for right now, a work-around
is to use Allegro CL 6.2 for another week or two.  dan, i have reverted
the copy in `/logon/acl' to 6.2 (with latest patches), and that appears
to allow me to go through Rondane (50,000 edges; 5,000 results) in some
twenty minutes (using four cpus).  that should be a little better than 
the laptop, i hope?

                                                          best  -  oe

+++ Universitetet i Oslo (ILN); Boks 1102 Blindern; 0317 Oslo; (+47) 2285 7989
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at hf.uio.no; stephan at oepen.net ---

More information about the developers mailing list