[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #MSE-433853]: Hourly Statistics of LDM feed

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.