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

Re: 960411: "ncvarput: xdr_NC_fill"

> 
> John,
> 
> >From: address@hidden (John Sheldon)
> 
> In the above message you wrote:
> 
> > > Please let me know if this fixes your problem.
> > 
> > I made that change and it did the trick! -- can't say as I have a solid
> > understanding of where things went wrong, but at least things are up
> > and running.  Thanks!
> > 
> > Now, the bad news (sorta) - remember I mentioned a while back that I
> > saw a large increase in CP time with prefill turned on?  Well, that's
> > still happening.  Here's an example:
> >                                         From "time":
> >                                       ----------------
> >       NETCDF_FFIOSPEC                          CP     Sys   Wall     ls -l
> > ------------------------------          ------- ------- ----    --------
> > cache:32:66 (With prefill)        123.8174u 6.6852s 2:43    46659904
> > 
> > cache:32:66 (No prefill)            2.2253u 0.7482s 0:26    46659792
> > 
> > Any intuitive leaps about this one??
> 
> Sorry, no.  I'm not a CRAY expert (or novice even) and must defer to 
> people like Kuehn.  I've CC'd him on this message.  Hopefully, he'll
> have something to say.


At this point, I have no idea why prefill is so expensive.  if you can
provide a small test case, we can try an few performance analysis runs
with flowtrace, procstat, and the EIE event layer.  That may shed some
light on the problem.


> > > FYI, our UNICOS 8 CRAYs handle the value -32768.
> > 
> > That *really* puzzles me! Any idea what could be causing that?  We're
> > running UNICOS 8.0.4 - do you have a later version?
> 
> (I thought you were running UNICOS 7?)
> 
> Anyway, I spoke too soon.  I based my pronouncement on the fact that the
> CRAYs can represent -32768 in a short.  In actuality, your CDL file
> causes our ncgen(1) to crash just like yours.
> 


There is a Cray library bug (again, in at least our UNICOS 8) which causes
the value -32768 to be incorrectly converted to -32767 in some cases.  I
missed the earlier part of this discussion, but if you can fill me in I'll
see if i can help on this one too.


--Jeff Kuehn,  Group Head
  Technical Consulting Group
  Scientific Computing Division
  National Center for Atmospheric Research
  PO Box 3000
  Boulder, Colorado 80307-3000
  http://www.ucar.edu/consweb/TCG/kuehn/HomePage.html