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

20031219: 20031218: 20031216: dcnexr2 cpu usage

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20031219: 20031218: 20031216: dcnexr2 cpu usage
  • Date: Tue, 06 Jan 2004 11:11:05 -0700
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
>>
>
>