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.
Hi Justin and Becky, re: latest metrics.txt file(s) > The latest version is available at: > http://www.ftp.ncep.noaa.gov/data1/nccf/com/tmp/metrics.txt Thanks for putting the metrics.txt file out for me to grab. The information it contains is _very_ useful. Now the good news: - plots of the information in the metrics.txt file show that things are working nicely on ncep-ldm2.woc.noaa.gov: - load averages are nice and low especially after you found and killed the stuck 'gribinsert' process - the smallest age of the oldest product in the LDM queue did not become smaller after the new parallel NAM/fire weather products were added to the test CONDUIT mix This is very important since it shows that there was no serious impact created when the additional data was added. NB: this did not create any problems because the parallel NAM data was (and continues to be) added at off peak times for the "operational" CONDUIT feed. If the timing of the addition of the parallel NAM data changes, problems could arise! - the plot of the number of bytes in the LDM queue vs time shows that the queue is volume limited. The change from being slots limited to being volume limited coincides with the mounting of all needed file systems so that 'gribinsert' had access to model output files that needed to be carved-up into individual products which would then be added to the LDM queue. Being volume limited is _not_ a problem for the queue. It shows, however, that addition of more volume at the "wrong" (existing peak times) could affect overall performance by lowering the smallest age of the oldest product in the queue further. - the trace of the age of the oldest product in the queue shows that there has been little/now effect on the smallest age, but there has been a decrease in the largest age (from 3.5 hours to ~2.7 hours). This is simply another way of saying that there is more data flowing through the queue now. - the number of products in the LDM queue with time trace shows a noticeable growth This is a reflection of all file systems being now correctly mounted and model output on those file systems being processed into the feed (a good thing). The volume plots from the real-time statistics for ncep-ldm2.woc.noaa.gov when compared against the volume plots for one of the "operational" CONDUIT top level machines, ncep-ldm0.woc.noaa.gov, graphically shows the large increase in data in the test CONDUIT datastream: ncep-ldm0.woc.noaa.gov http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?CONDUIT+ncep-ldm0.woc.noaa.gov ncep-ldm2.woc.noaa.gov http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?CONDUIT+ncep-ldm2.woc.noaa.gov Put each plot up in a browser tab and flip back and forth between the plots, and you will instantly see the large increase in volume and new bi-modality in the test CONDUIT feed. A quantitative listing of this difference can be easily gotten from the cumulative volume listings for each of the machines above: ncep-ldm0.woc.noaa.gov http://www.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume?ncep-ldm0.woc.noaa.gov Data Volume Summary for ncep-ldm0.woc.noaa.gov Maximum hourly volume 6612.373 M bytes/hour Average hourly volume 2429.549 M bytes/hour Average products per hour 64028 prods/hour Feed Average Maximum Products (M byte/hour) (M byte/hour) number/hour CONDUIT 2429.549 [100.000%] 6612.373 64028.304 ncep-ldm2.woc.noaa.gov http://www.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume?ncep-ldm2.woc.noaa.gov Data Volume Summary for ncep-ldm2.woc.noaa.gov Maximum hourly volume 6612.534 M bytes/hour Average hourly volume 3258.420 M bytes/hour Average products per hour 70480 prods/hour Feed Average Maximum Products (M byte/hour) (M byte/hour) number/hour CONDUIT 3258.420 [100.000%] 6612.534 70479.957 What I am most interested in is a comparison of the average volume from each feed: ncep-ldm2.woc.noaa.gov: 2429.549 M bytes/hour ncep-ldm2.woc.noaa.gov: 3258.420 M bytes/hour The increase in average increase (which is over a two day period) is on the order of 800 MB/hour. The maximum hourly increase in volume is up to 3.2 GB! Needless to say, this is _not_ an insignificant increase in data volume, AND it is something that will need to be explained and OKed by the current CONDUIT community. The good news is that there is enough information in the Product IDs for the fire weather products for the end-users to opt out of getting the data (i.e., not REQUEST the data in one's ~ldm/etc/ldmd.conf file) and/or not process the data (i.e., not process the data in an ~ldm/etc/pqact.conf pattern-action file). Example Product ID for a fire weather product: data/nccf/com/nam/para/nam.20110825/nam.t18z.firewxnest.hiresf12.tm00.grib2 !grib2/ncep/NMM_89/#000/201108251800F012/WTMP/0 - NONE! 001001 Wrap-up comments: - the test is proceeding nicely - the test machine is, from all appearances, not showing any detrimental effects of the increase in volume - the additions I made to the GEMPAK tables seems to be sufficient for creation of descriptive LDM/IDD Product IDs for all fire weather products. I am still checking to see if more additions need to be made for GRIB/GRIB2 messages in NOAAPort. The question is what do we do next? 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: SBB-325304 Department: Support CONDUIT Priority: Normal Status: Closed