NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Gilbert, re: Level II latencies > Right now, I am uniformly 7 minutes behind. > > Mar 09 06:01:25 pqutil INFO: 1742 20060309060124.767 NEXRAD2 160013 > L2-BZIP2/KHDX/20060309055948/160/13 > Mar 09 06:01:25 pqutil INFO: 18089 20060309060124.648 NEXRAD2 424017 > L2-BZIP2/KSJT/20060309060009/424/17 > Mar 09 06:01:25 pqutil INFO: 44887 20060309060123.890 NEXRAD2 312019 > L2-BZIP2/KGRR/20060309055953/312/19 > Mar 09 06:01:25 pqutil INFO: 9074 20060309060124.742 NEXRAD2 989061 > L2-BZIP2/KARX/20060309055647/989/61 > Mar 09 06:01:25 pqutil INFO: 7388 20060309060125.015 NEXRAD2 635047 > L2-BZIP2/KRGX/20060309055826/635/47 > Mar 09 06:01:25 pqutil INFO: 29890 20060309060124.989 NEXRAD2 12026 > L2-BZIP2/KEAX/20060309055918/12/26 > Mar 09 06:01:25 pqutil INFO: 19138 20060309060124.972 NEXRAD2 819006 > L2-BZIP2/KLCH/20060309055951/819/6 > Mar 09 06:01:25 pqutil INFO: 8916 20060309060125.097 NEXRAD2 804015 > L2-BZIP2/KTWX/20060309060026/804/15 > Mar 09 06:01:25 pqutil INFO: 14192 20060309060125.080 NEXRAD2 52042 > L2-BZIP2/KGRB/20060309055601/52/42 > Mar 09 06:01:25 pqutil INFO: 13277 20060309060125.252 NEXRAD2 273032 > L2-BZIP2/KDAX/20060309055924/273/32 > > Level 3 data is beating this by 5-6 minutes. Five things: - the latencies your listing is showing are on the order of a second not 7 minutes. Remember that latency is time received minus the time the product was created. - I believe that the time included in the header of the Level II product is not the time that the volume scan finished or even the time when the piece of the volume scan finished. I _think_ (but am not positive) that it is more like the time the volume scan began. - A full volume scan takes on the order of 5 minutes to complete - we know that the NWS is _NOT_ introducing a delay into the relay of the Level II data. The have been working diligently to get the data out of the NEXRADs and to the toplevel relay nodes (IRaDS, Purdue, the MAX, and the ERC) as fast as possible. For the record, we know this because Steve Emmerson has been asked on occasion to logon to the LDM machine at several NEXRADs to troubleshoot some problem. It is our observation that the process by which data is injected into the LDM does not have any buffering. In fact, the NWS' design is to not even try to relay data if it is more than 15 minutes old (meaning that the LDM queue on the NEXRAD LDM is very small). - any toplevel Unidata relay can verify that the products being relayed to them are not being delayed by the toplevel relay by using: notifyme -vxl- -f NEXRAD2 -h toplevel_LevelII_relay You can verify that there is no latency being introduced in the sequence of relays to yourself by using the 'topology' links in the real time statistics pages. When a site's upstream host is reporting latency statistics, one can click on the upstream hostname listed in the 'topology' link page and see the differential latency from that indicated host to its immediate upstream. One last comment. There are still some NEXRADs/LDMs at NEXRADs where the system clock is not properly maintained. This inaccuracy will manifest itself in continuous latencies for that particular NEXRAD in the realtime statistics plots. I realize that this is not what you are referring to, but I wanted to add it here "for the record". 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: AYJ-610338 Department: Support Datastream Priority: Normal Status: Closed