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

[IDD #TMZ-743033]: Help? Our LDM Miami radar latency is too long

Hi Brian,

> Can someone at Unidata suggest how we might reduce latency in our Miami
> KAMX radar feed?

I assume that you are referring to the NEXRAD Level 2 data from
KAMX, correct?

If yes, then given that the indicated latencies for the NEXRAD2 feed
that weather2.rsmas.miami.edu is reporting are reasonably low:


one would assume that the volume scan pieces from KAMX would be received
as with no more delay than for other radars.

If you are referring to NEXRAD Level 3 products, then the latencies being
reported by weather2 are even lower than for the Level 2 products:



- how are you judging the latencies?

  For example, are you looking at the LDM measured latency which is the
  time difference between when a product was inserted into an LDM queue
  and when it is received on weather2?

  Or, are you looking at the disk time stamp when the full volume scan
  has been reconstituted into a full product on weather2.

Since the LDM latencies indicated in the real-time stats being reported
by weather2 do not look to be excessive (they are, in fact, low), the most
likely reasons for the product looking like it is being received late are:

- the products insertions at the radar are late

  There is nothing we can do about this.

- something is holding up the reassembly of the pieces back into a full
  volume scan

> Does the LDM have any prioritization possibilities?

No, at least not in the sense that you may be thinking of.  Again, the
latencies being reported by weather2 in the real time stats it is
sending back to us do not show any large latencies for either Level 2
or Level 3 radar products.

> Thanks for any advice (or direct interventions in the system at
> weather.rsmas.miami.edu!

Have you compared the availability of the KAMX radar volume scan on
your TDS and on Unidata TDSs?  If our times are comparable to yours,
it should mean that the volume scans sends are being delayed at the
radar (meaning that the products are not being inserted the LDM
queue on the radar in a timely manner).  If the times are way off,
then there is likely some sort of a reassembly delay on weatherw2.



> On Mar 1, 2018, at 8:14 AM, McNoldy, Brian Daniel 
> <address@hidden<mailto:address@hidden>> wrote:
> Unfortunately, I don't know the first thing about LDM server admin, but
> I have poked around in the THREDDS directories. Looks like some satellite
> stuff, radar stuff, surface station, NCEP models, and FNMOC models.
> I would assume that the more one pulls in, the greater the latency of any
> given product.  Thing is, you never know what someone might want!  For a
> real-time radar loop from a single station, latency matters (2 minutes
> is much preferred over 10+ minutes!).  But, not sure how to accomplish
> that. (can commands be prioritized... like specifically ask for KAMX
> Level 2 data first thing in the script then grab everything else?)
> I noticed the server maintains two copies of the same Level 2 NEXRAD data
> (though perhaps one is simply a link to the other?):
> http://weather.rsmas.miami.edu/thredds/catalog/nexrad/level2/KAMX/20180301/
> http://weather.rsmas.miami.edu/native/radar/level2/KAMX/20180301/
> Amazon Web Service also hosts real-time NEXRAD data, but I'm not sure
> how to access that in IDL.
> Brian


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: TMZ-743033
Department: Support IDD
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.