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

20030926: mesodata reorganization (cont.)



>From: Tom Yoksas <address@hidden>
>Organization: UCAR/Unidata
>Keywords:  200309201339.h8KDdPk1012811 LDM scour load average

Hi Gerry,

I got your voicemail yesterday, but I was so hammered that I was
unable to call you back.  This note is simply to let you know that
I have not shelved thinking about your situation.  I will try to
call later today.  I can't right now 'cause our phone service is
not allowing anything outside of the organization (when it rains,
it pours :-()

One quick idea that we have been kicking around here before I
dash off:

- looking through your dmesg log file, I see that the disk you are
  writing data to is running at UDMA 33.  This is most likely
  due to it being connected to the same ribbon cable that the CDROM
  is on, and/or it being connected with a non-80 pin cable.
  Since you are filing all NEXRAD data AND trying to scour it
  from this disk which is not running as fast as it perhaps
  could be, your problem may be simply that disk access is not
  fast enough to allow you to get and process all of the NEXRAD
  data.  The only thing that bothers me about this comment is
  my recollection that your problems started _before_ you changed
  your NEXRAD feed to atm.geo.nsf.gov and began getting all sites.
  Please let me know if your problem really began when you started
  requesting all NEXRAD data even when this was being requested
  from coriolis.  If it did, we have found the smoking gun: you
  disk is not fast enough to keep up with what you are trying
  to do.

Got to run for a bit...

Tom

>From address@hidden Fri Sep 26 15:08:22 2003

Looks like a weapon to me.  I'll see about fixing that.  Monday. I'm out 
sick today.  When it rains it pours.

Thanks.  Good catch.  One more reason I prefer SCSI...

gerry