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 Marcus, re: > Yes, there is definitely packet shaping going on, just as before; > we are just trying to find out how bad it is and > what limits we are working with. OK. re: > We want to make sure that the problems are solely due to the bottleneck > before taking mitigating action on this side. It looks like you have already done the easiest thing to mitigate somewhat the effect of packet shaping: splitting your feed requests into separate ldmd.conf REQUESTs. The next step (other than getting your network folks to ease up on the packet shaping) would be to determine what subset of each feed you want/need. re: > It looks like we are getting HDS data, but it is not getting processed; > so, could it be that we are always getting incomplete > files, The way the LDM works is that individual products are sent and they are either received or not. There should never be an instance of a part of a product being received. re: > or is it that we have something incorrect in the pqact...? This will take digging on our side. The better question is what do your log files say? For instance, are you seeing any indication of problems in the LDM log file (~ldm/etc/ldmd.conf), and/or are you seeing any indications of problems in the log file(s) for the GEMPAK decoders you are running (~ldm/data/gempak/logs/*.log)? re: > I also noticed that the rtstats output pages think we are using ldm 6.8.1, > but the main list of hosts > show us using 6.9.8 ... probably doesn't affect anything, but an fyi. Thanks for the FYI. Your surmise is correct, however: you would see no difference running LDM 6.9.8 than with 6.8.1. re: > We are hopeful that we can get a consistent 3Mbit/s or more soon...which > should be a small improvement. 3 Mbps should be enough to get the data you are currently requesting. Ideas: - think about what NEXRAD3 data you do _not_ want/need - think about what model output you can do without 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: GOK-818269 Department: Support IDD Priority: Normal Status: Closed