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 Carol, re: > Thanks so much for the detailed responses! I'll make sure that Steve gets the thanks. I want to clarify one comment that Steve made: You asked: >> I have a question about the volume graphs. Are these the total volume of >> products per hour? Steve replied: > Yes, for each feedtype. Each bar represents the number of bytes sent in an > hour. My comment is that the each bar represents the number of bytes _received_ in an hour, not sent in an hour. All numbers reported by rtstats are for what an LDM is receiving, not sending. re: > Is there anyway to fix the issue "data-products that were created on > Herbie and received by the LDM on Herbie from the immediate upstream > node Herbie"? It seems to be causing a strange spike in the graph of > almost 9 MBs in an hour. The only things I can think of that could cause the seemingly anomalous spike in volume received are: - hiccup in our rtstats reporting - receipt of 2nd trip products This would typically be accompanied by large latencies which I do not see in: http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?EXP+herbie-amrc.ssec.wisc.edu The other possibility is that the LDM queue size on the receiving machine is way too small to reject the products as being duplicates. Questions: - what is the size of the LDM queue on herbie-amrc.ssec.wisc.edu? - does herbie.usap.gov REQUEST EXP from herbie-amrc.ssec.wisc.edu? I assume that the answer to this one is yes. Observation: - the latency plot for EXP on herbie-amrc.ssec.wisc.edu shows that the clock on 157.132.119.135 is drifting and then apparently being reset by something like 'ntpdate' If you know who the system administrator for 157.132.119.135, you should contact them to let them know that they should probably be running 'ntpd'. re: > When I finish making my documents to send to the admins, I'll suggest > they specifically monitor the 388 port. It should be fairly easy to monitor the outbound traffic on port 388. If it were the case that the only outbound traffic is being generated by the LDM, then one could simply setup a cron job to run 'ifconfig' at regular intervals and then parse the output to get TX bytes numbers and calculate the transmit rate (the "poor man's" way of monitoring the traffic :-) re: > Thanks again for all your help! I'm sure that Steve has seen and appreciates your thanks. 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: MSE-433853 Department: Support LDM 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.