As a less-than-two-year old cygwin/GRASS user, I have never seen virtual memory going over 1 GB while doing intensive computations with GRASS (e.g., v.surf.idw interpolation). I haven't found much on the topic in the web so I tried the following to increase virtual memory available to cygwin: http://sources.redhat.com/ml/cygwin/2003-02/msg00234.html
but noticed no difference and so I am wondering whether cygwin/GRASS gets compiled with the -mno-cygwin flag that apparently allows programs to allocate up to 1920 MBytes: http://sourceware.org/ml/cygwin/2005-04/msg01309.html
There are ongoing issues with various windows incarnations of GRASS. Cygwin has had some issues with large files and higher memory addressing pretty much since its incarnation (I wrestled with this quite a bit a few years back). You might want to try the new grass binary that relies on mingw, I've seen my memory spike higher than 1gb during some analyses... or, install unix someplace!
--j
Luigi Ponti wrote:
Hello,
As a less-than-two-year old cygwin/GRASS user, I have never seen virtual memory going over 1 GB while doing intensive computations with GRASS (e.g., v.surf.idw interpolation). I haven't found much on the topic in the web so I tried the following to increase virtual memory available to cygwin: http://sources.redhat.com/ml/cygwin/2003-02/msg00234.html
but noticed no difference and so I am wondering whether cygwin/GRASS gets compiled with the -mno-cygwin flag that apparently allows programs to allocate up to 1920 MBytes: http://sourceware.org/ml/cygwin/2005-04/msg01309.html
--
Jonathan A. Greenberg, PhD
Postdoctoral Scholar
Center for Spatial Technologies and Remote Sensing (CSTARS)
University of California, Davis
One Shields Avenue
The Barn, Room 250N
Davis, CA 95616
Cell: 415-794-5043
AIM: jgrn307, MSN: jgrn307@hotmail.com, Gchat: jgrn307
As a less-than-two-year old cygwin/GRASS user, I have never seen virtual
memory going over 1 GB while doing intensive computations with GRASS
(e.g., v.surf.idw interpolation). I haven't found much on the topic in
the web so I tried the following to increase virtual memory available to
cygwin: http://sources.redhat.com/ml/cygwin/2003-02/msg00234.html
but noticed no difference and so I am wondering whether cygwin/GRASS
gets compiled with the -mno-cygwin flag
No. That flag lets you use Cygwin's gcc to compile native Windows
binaries rather than Cygwin binaries. The Cygwin version of GRASS
requires Cygwin, so that flag won't work.
As a less-than-two-year old cygwin/GRASS user, I have never seen virtual
memory going over 1 GB while doing intensive computations with GRASS
(e.g., v.surf.idw interpolation). I haven't found much on the topic in
the web so I tried the following to increase virtual memory available to
cygwin:
[http://sources.redhat.com/ml/cygwin/2003-02/msg00234.html](http://sources.redhat.com/ml/cygwin/2003-02/msg00234.html)
but noticed no difference and so I am wondering whether cygwin/GRASS
gets compiled with the -mno-cygwin flag
No. That flag lets you use Cygwin's gcc to compile native Windows
binaries rather than Cygwin binaries. The Cygwin version of GRASS
requires Cygwin, so that flag won't work.
Thanks Glynn – sorry for misunderstanding the post.
As a less-than-two-year old cygwin/GRASS user, I have never seen
virtual memory going over 1 GB while doing intensive computations
with GRASS (e.g., v.surf.idw interpolation).
Have you been getting out-of-memory errors or are you concerned that
you are not making best use of all available resouces? If the latter,
you don't see grass using much memory because it is fairly efficent
most of the time and doesn't need to- especially the core GIS and
raster parts of it. When you consider the amount of RAM+CPU power
typically available back when that code was written, it isn't
surprising that it was done in such a way.
A nice side effect of being built under those constraints is that now
with more computing resources available it scales to huge datasets
quite well.
So only worry if you are getting out-of-memory errors, otherwise just
enjoy. It won't use any more or less memory than just the amount it
needs.
As a less-than-two-year old cygwin/GRASS user, I have never seen
virtual memory going over 1 GB while doing intensive computations
with GRASS (e.g., v.surf.idw interpolation).
Have you been getting out-of-memory errors or are you concerned that
you are not making best use of all available resouces?
Yes: the latter.
If the latter,
you don't see grass using much memory because it is fairly efficent
most of the time and doesn't need to- especially the core GIS and
raster parts of it. When you consider the amount of RAM+CPU power
typically available back when that code was written, it isn't
surprising that it was done in such a way.
Thanks Hamish, I see your point. What I don’t quite understand is why CPU usage always goes up to 100% when running GRASS commands, while allocated memory is always about 25% – flat, no peaks.
A nice side effect of being built under those constraints is that now
with more computing resources available it scales to huge datasets
quite well.
That’s something I never considered – interesting.
So only worry if you are getting out-of-memory errors, otherwise just
enjoy. It won't use any more or less memory than just the amount it
needs.
So in my case the CPU is very busy because of the Cygwin overload but the memory usage doesn’t go up because of GRASS efficiency?
> If the latter,
> you don't see grass using much memory because it is fairly efficent
> most of the time and doesn't need to- especially the core GIS and
> raster parts of it. When you consider the amount of RAM+CPU power
> typically available back when that code was written, it isn't
> surprising that it was done in such a way.
Thanks Hamish, I see your point. What I don't quite understand is why
CPU usage always goes up to 100% when running GRASS commands, while
allocated memory is always about 25% -- flat, no peaks.
Any process will use 100% CPU unless either it can process the data
faster than the OS can provide it or it has to contend for the CPU
with other active processes.
The only time the CPU will be idle is if no process is ready to run,
i.e. if all processes are blocked waiting for input, whether user
input or data from a disk, network connection, external device, etc.
Any process will use 100% CPU unless either it can process the data
faster than the OS can provide it or it has to contend for the CPU
with other active processes.
The only time the CPU will be idle is if no process is ready to run,
i.e. if all processes are blocked waiting for input, whether user
input or data from a disk, network connection, external device, etc.
OK: I will take some notes!
Thanks very much for addressing this off-topic.
Kind regards,
Luigi