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

[Support #AXO-576049]: LDM latency

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: [Support #AXO-576049]: LDM latency
  • Date: Tue, 04 Mar 2008 11:21:39 -0700
Robert,

> If I save the data off using a FILE directive, then compare time stamps,
> the latency is illustrated by the discrepancy.
> 
> -rw-rw-r--  1 ldm pdi 1298375 Mar  4 03:23 KVWX_20080304021924.dat.bz2
> -rw-rw-r--  1 ldm pdi 1298080 Mar  4 03:27 KVWX_20080304022540.dat.bz2
> -rw-rw-r--  1 ldm pdi 1298073 Mar  4 03:32 KVWX_20080304023202.dat.bz2
> -rw-rw-r--  1 ldm pdi 1298894 Mar  4 03:36 KVWX_20080304023818.dat.bz2
> -rw-rw-r--  1 ldm pdi 1301111 Mar  4 03:39 KVWX_20080304024436.dat.bz2

(I assume you're taking into account the facts that the file name
probably uses UTC; whereas the file-access time probably uses local
time).

While the comparison of the file-access and product-creation times indicates
that the "pqact" process is processing data-products much later than
they're created, it doesn't necessarily indicate a high arrival latency
because it's possible for the "pqact" process to be backed-up, as it were.

I suggest sending the downstream LDM that's receiving the NEXRAD2
data-products a USR2 signal to put it into verbose logging mode.  Do
this around the time that you notice a high latency in the file-access
times.  A comparison of the timestamps in the log messages will then
indicate the true product-arrival latency.

To return the downstream LDM to default logging mode, send it two (2)
more USR2 signals (the second one will put it into debug logging mode
and the third will return it to default logging mode).

> Normally the data is PIPEd to a decoder and we first noticed the latency
> from the decoded data. After looking at the incoming data with "ldmadmin
> watch -f NEXRAD2" it was obvious that the incoming data was getting
> older and older. Even after stopping and starting LDM the data appeared
> to be delayed.  The delay does not appear to originate at the radar
> sites, as we can verify that other sites are getting the data on time.
> Very frustrating issue.

If the latency holds up, then it could be that your network connection is
insufficient for the amount of data you're requesting.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: AXO-576049
Department: Support LDM
Priority: Normal
Status: On Hold