[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20031219: 20031218: 20031216: dcnexr2 cpu usage



That works much better.  Thanks.

Unidata Support wrote:
Larry,

I have a fix for the buffered read routine that dcnexr2 uses that
seems to fix your problem with Linux due to resetting of the read timeout
value in the C library select call.

Do you want to build locally (Im assuming since you have the other version
built with gmon profiling)?
You can download: http://www.unidata.ucar.edu/staff/chiz/bufread.c
and use this copy to replace that in $NAWIPS/unidata/ldmbridge/dcnexr2/.

Steve Chiswell
Unidata User Support





From: Unidata Support <address@hidden>
Organization: UCAR/Unidata


Larry,

It could be a problem within the BZIP2 library, and/or
a mismatch of the package supplied header/library with one you might already have on your system.
.
You probably have -lbz2 on your system already, so maybe you would have better luck using the system provided version rather than the version compiled under the $NAWIPS/unidata/ldmbridge/dcnexr2 tree. So, you could try: In $NAWIPS/unidata/ldmbridge/dcnexr2/Makefile, for the target all:, removing the BZIP2 dependency, and
editing the link line in the dcnexr2 target to remove the
-L./bzip2 location. Also, remove -I./bzip2 from CFLAGS.

I checked my fedora system and libbz2.a is in /usr/lib
and bzlib.h is in /usr/include/

Steve Chiswell






From: "Larry D. Oolman" <address@hidden>
Organization: University of Wyoming
Keywords: 200312182257.hBIMvKp2016896

Unidata Support wrote:

Larry,

I'd have to know what support question you are referring to.

I have not seen a problem with CPU usage getting out of hand,
but have seen that any decoder could get wedged and CPU intensive if the system were I/O backed up so that pqact starting firing off multiple instances of the PIPE and the output file became corrupted.

Steve Chiswell


I googled: dcnexr2 cpu usage site:unidata.ucar.edu

It suspect it is a compiler issue.  I tried multiple compilations
with various optimizations and with and without -g.  If I
specify -pg, there is no cpu problem.  If I don't specify -pg,
I get 100% cpu usage.  I even tried compiling
on a RH7.3 system (still run under RH9).  I'll live with the
gmon.out file that gets created.

--
Larry Oolman
Department of Atmospheric Science
University of Wyoming
address@hidden
http://www-das.uwyo.edu




**************************************************************************** <
Unidata User Support                                    UCAR Unidata Program <
(303)497-8643                                                  P.O. Box 3000 <
address@hidden                                   Boulder, CO 80307 <
---------------------------------------------------------------------------- <
Unidata WWW Service              http://my.unidata.ucar.edu/content/support  <
**************************************************************************** <


--
Larry Oolman
Department of Atmospheric Science
University of Wyoming
address@hidden
http://www-das.uwyo.edu