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

[Support #AXO-576049]: LDM latency


> 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

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.

Steve Emmerson

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

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.