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

[LDM #JZT-172247]: Ignoring too-old product for Only CONDUIT

Hi,

re:
> A couple weeks ago one of our LDMs, gale.db.erau.edu, stopped filing CONDUIT 
> but all
> other feed types are working.  This system's upstream LDM is 
> wxldm.db.erau.edu.
> 
> gale.db.erau.edu's logs show "WARN  Ignoring too-old product".  The clocks 
> are in
> sync to less than a second.  I've tried connecting to wxldm.db.erau.edu via 
> two
> different networks, one 10 Gbps, with no change in behavior.  The system load 
> is
> pretty reasonable, though I do have some concerns about I/O Wait hovering 
> around 2%.
> 
> Here's a quick snapshot of the system load:
> 
> load average: 4.61, 4.28, 3.70
> Tasks: 445 total,   1 running, 444 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 13.1 us,  3.0 sy,  0.0 ni, 81.7 id,  2.0 wa,  0.0 hi,  0.2 si,  0.0 
> st
> 
> Any suggestions would be greatly appreciated, I'm stumped.  Thanks!

It is most likely that the <max-latency> setting in the LDM registry files
is now being exceeded by the apparent latency associated with the CONDUIT
products.  The reason that this is likely the case is the clocks on the
CONDUIT source machines are not being maintained properly, so the
indicated latency on all products due to the clock drift is varying
between about 438 and 490 seconds.  We have informed NCEP about the need
to fix the clock problem on their machines multiple times over the past
2-3 months, and they have said this issue is supposed to be addressed
sometime this month.

What you should do is make some changes in your LDM registry, 
~ldm/etc/registry.xml:

- if <reconciliation-mode> is not currently 'do nothing' (without
  the quote marks), change it to 'do nothing' (without the quote marks)

- adjust the  <max-latency> setting in the <server> block to a number
  higher than at least 500

  We suggest setting this to 3600 (seconds)

- adjust the <time-offset> setting in the <server> block to match the
  <max-latency> parameter

After making the changes to the LDM registry, you will need to stop
and then start your LDM.


Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: JZT-172247
Department: Support LDM
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.