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

20030704: UGa upgrading to latest LDM-6 (cont.)

>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200307031521.h63FLfLd024002 LDM-6 rtstats

Hi Tom,

Now that  we are getting real time statistics from you, we can help
monitor the performance of not only the IDD delivery of data to you,
but also see things that may be amiss on your machine.

A quick look at the latency for the FNEXRAD feed:

http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?FNEXRAD+cacimbo.ggy.uga.edu

shows that the clock on cacimbo is drifting by up to 6 seconds between
synchronizations.  The plot makes it look like you are running ntpdate
at something like 4 and 16Z, or, at least, only twice per day.  The
recommendation that we make to all sites running PC OSes (e.g., Linux,
Solaris x86, and FreeBSD) is to run ntpdate once per hour (if you are,
in fact, running ntpdate and not xntpd).  This will help keep your
machine synchronized with the IDD relay machines.  I will also pretty
up the latency plots ;-)

Other than the time drift problem, your feeds are looking reasonable.
I am a little concerned about the latencies I am seeing for the
UNIWISC images (which go up to 80 seconds).  A plot of differential
latency between cacimbo and its upstream host pluto.met.fsu.edu:

http://www.unidata.ucar.edu/cgi-bin/rtstats/topolatency?cacimbo.ggy.uga.edu+pluto.met.fsu.edu+UNIWISC

shows that only a little of the latency is being caused by the connection
from cacimbo to pluto.  This is verified by looking at UNIWISC latency
plots on pluto:

http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?UNIWISC+pluto.met.fsu.edu

We are unable to trace the source of the latency before pluto, however,
since its upstream feed site, squall.atmos.uiuc.edu, is not reporting
real time statistics back to us.  I will contact UIUC to see if this
situation can be rectified.

Thanks in advance for your help in tuning your system clock...

Tom