20021119: UFRJ as a primary IDD redistribution point for Brazil (cont.)

>From:  David Garrana Coelho <address@hidden>
>Organization:  UFRJ
>Keywords:  200211131628.gADGSZL18316 IDD-Brazil LDM 5.2.2

Hi David,

>All changes made and ldmd restarted succesfully. I made the
>changes in request lines too. What we want to receive is all observational
>data covering our country, and it to be decoded by GEMPAK.

The observational data for the world is contained in the DDPLUS|IDS
datastream. You will be receiving all of that now, and the latencies
should be small.

>I believe those
>lines didnt changed what we had received as usual, am i wrong?

You are correct.  The splitting of the feed was done to get around a
design limitation in the current version of the LDM.  The new version
of the LDM that we are working on -- and will begin testing today --
should not have that limitation, so the splitting of the feeds into
multiple small parts should be unnecessary.

>I also restarted network daemons to assure hosts file was read.

This wasn't necessary, but it won't hurt.

I logged onto brisa immediately after seeing your email, and I found
a problem.  Evidently, you original LDM installation did not completely
follow the guidelines that we make in:

http://my.unidata.ucar.edu/content/software/ldm/ldmPreInstallList.html

In particular, you were not using the runtime link scheme that allows
one to roll a new LDM version into use with the simple switch of
a runtime link.  Here is what I did on brisa to change your setup
so it will be much easier to upgrade in the future:

<login as 'ldm'>
ldmadmin stop
mkdir tmp
mv bin man lib include src tmp
ln -s runtime/bin bin
ln -s runtime/man man
ln -s runtime/src src
ln -s runtime/lib lib
ln -s runtime/include include

Now, since you already setup the runtime link to point at LDM 5.2.2:

ln -s ldm-5.2.2 runtime

the change was complete.  With this setup, the ~ldm/bin directory is always
a link to the bin directory of the distribution you are using.  Upgrading
to a new version is as simple as downloading the new version, building
it, installing it, editing the version of ldmadmin that comes with it,
and then changing the runtime link in the ~ldm directory.

Since you were not using the runtime link scheme, the old (5.1.2)
version of LDM executables were being used when you deleted and remade
the queue and restarted your LDM.  I repeated the steps I sent you
last evening so that they would be created with the 5.2.2 executables:

<LDM was stopped above>
ldmadmin delqueue
ldmadmin mkqueue
ldmadmin start

Now, the 5.2.2 executables are running, and logging to the ~ldm/logs/ldmd.log
file is working (the logging was not working when I logged on to brisa).
Also, after making the change, brisa is reporting realtime statistics
back to our office.  You can see the realtime statistics plots through:

Real Time Statistics
http://www.unidata.ucar.edu/staff/chiz/latency/stats
  Statistics by Host
  http://www.unidata.ucar.edu/staff/chiz/latency/rtstats/index2.shtml
    brisa.meteoro.ufrj.br
    
http://www.unidata.ucar.edu/staff/chiz/latency/rtstats/index2.shtml?brisa.meteoro.ufrj.br

As time goes on, these plots will contain more data (represent several
days of data ingestion).  In about an hour, the latencies represented
in the plots should drop to near zero.

By the way, are you running ntp to set your system clock?  If not,  you
should, otherwise the latency times represent in the realtime statistics
plots will be off.

I will continue to monitor brisa throught the day today.

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+