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.
Manuel, > ECMWF is not sending old CMA data to NCAR. We are getting real-time data > via ftp as 1 tar file and then we are inserting it in LDM (for NCAR and > ECMWF to archive in their TIGGE databases). Sorry. Instead of "old" I should have said something like "data that is not currently being inserted into the LDM product-queue on the CMA computer". My bad. My point is still valid, however. The CMA data that ECMWF inserts into ECMWF's product-queue and that is sent to NCAR via the LDM makes interpretation of the volume time-series plots very difficult. We see NCAR receiving data created at ECMWF that is not received by CMA and are left to wonder if it should or should not have been received by CMA. > Last night, I did restart LDM, which activated Mike's 'balance' > mechanism. Since then, one of our work filesystem got full because we > have several cycles of data outstanding to be ingested in LDM. Does the > 'balance' cause any overhead ? The overhead from "balance" is negligible --- all it's doing is reading from port 8080 and writing to port 388 on the same computer. These operations are in-memory and very fast. I suspect that a much greater effect on throughput is the non-availability of the bandwidth being used to send CMA data from ECMWF to NCAR (bandwidth which would, otherwise, be used to send ECMWF data to NCAR). Regards, Steve Emmerson Ticket Details =================== Ticket ID: RFZ-122547 Department: Support IDD TIGGE Priority: Normal Status: Open