[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[LDM #MSE-433853]: Hourly Statistics of LDM feed
- Subject: [LDM #MSE-433853]: Hourly Statistics of LDM feed
- Date: Tue, 08 Aug 2017 16:39:38 -0600
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.