[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030315: NLDN feed allow and LDM-6 upgrade
- Subject: 20030315: NLDN feed allow and LDM-6 upgrade
- Date: Sat, 15 Mar 2003 09:44:56 -0700
>From: Unidata User Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200303151644.h2FGivB2018646 IDD NLDN LDM-6
Hi David et. al.,
I have been working with Gilbert Sebenste of Northern Illinois
University <address@hidden> to get NIU upgraded to the
latest release candidate of LDM-6 (an as yet unannounced version of the
LDM).
During this process, I asked Gilbert to consolidate all of his IDD
ingest on a single machine so that only one machine from NIU would
report real time statistics back to the UPC. One result of this
is his request for weather2.admin.niu.edu to be allowed to receive
NLDN data:
From: Gilbert Sebenste <address@hidden>
Date: Fri, 14 Mar 2003 23:28:54 -0500 (EST)
To: address@hidden
"Also...I need to have striker.atmos.albany.edu allow
weather2.admin.niu.edu to feed NLDN from it. I can't remember who
controls this now...but if the responsible person reads this, can you
allow me in (I'm trying to feed from you now)? Thanks much!"
I figured that since Gilbert forgot who to send this request to, I should
chime in.
The second topic I wanted to discuss is SUNY Albany upgrading its LDM
servers to LDM-6. We have been running the latest release candidate,
LDM-6.0.2, _hard_ on several machines in the UPC and around the US and
world, and the results look very good. Until Steve Emmerson told me
about a problem with ldmsend, I was all set to announce LDM-6.0.2 to
the community this weekend. Now, I will wait until all known bugs are
fixed. Nonetheless, I want to encourage you to upgrade to LDM-6.0.2 _IF_
you do not use ldmsend for any activities. If you do, or if you would
rather wait until we have solved all known bugs, it would be wise to
wait.
The following is the note I have been sending to top level IDD relay
sites regarding upgrading to LDM-6. It will be included in the general
announcement of LDM-6 availability, so you will be seeing it again in a
few days:
Notes:
- The online documentation for LDM was just put on the my.unidata
web site yesterday. It may undergo some touching up in the next
few days.
LDM 6 offers a number of new ideas that we are excited about. Here's
an overview:
o request lines to the same host in ldmd.conf are no longer accumulated
into a single rpc.ldmd invocation. This allows a user to split feeds
without having to create machine name aliases in /etc/hosts.
o the size of the HEREIS - COMINGSOON "fence" is now user configurable.
In LDM-5, all products smaller than 16384 bytes would be sent using
the HEREIS protocol. In LDM-6, this "fence" is settable on a
per-request line basis. The default for the "fence" size is now
essentially infinity (actually, it is size of a uint). You specify
the "fence" size as the 4th parameter on an ldmd.conf request line.
LDM-6 understands a couple of mnemonics for minimim and maximum
"fence" sizes:
request IDS|DDPLUS ".*" my.upstream.site PRIMARY (or PRI)
request IDS|DDPLUS ".*" my.upstream.site ALTERNATE (or ALT)
or equivalently:
request IDS|DDPLUS ".*" my.upstream.site MAXIMIM (or MAX)
request IDS|DDPLUS ".*" my.upstream.site MINIMUM (or MIN)
We think that the PRI (uint_max) and ALT (zero) values are basically
all that a site will ever need/use, but the values are configurable
nonetheless.
o products sent with the COMINGSOON/BLKDATA protocol are sent in one
chunk after a transaction is made between the client and server in
which the client says that it wants the product. In LDM-5, the same
client/server transaction was made and then the product was sent in
16384 BLKDATA chunks.
o LDM-6 is backward/forward compatible with LDM-5. LDM-5 clients
can receive data from LDM-6 servers, and LDM-6 clients can receive
data from LDM-5 servers. When LDM-5 talks to LDM-6, it does so using
LDM-5 protocols. LDM-6 running LDM-5 protocols is more efficient
than LDM-5.
o LDM-6 can use the same product queue that LDM-5 uses. This allows
a site to install the new version and start running without remaking
the product queue.
o LDM-6 is much more capable of delivering data to electronically
remote sites. One site we have been using for testing is located on
the edge of the Amazon in Belem, Brazil.
o LDM-6's ldmadmin now does several things for you that you had
to do by hand in LDM-5:
o put you in the ~ldm directory at LDM startup
o create the ~ldm/logs/ldmd.log file if it does not already exist
o determine your machine's hostname using a 'uname -n'. If
this does not result in a fully qualified hostname, ldmadmin
will complain and not start the LDM. In this case, you
need to edit ldmadmin and set the hostname:
change:
chop($hostname = `uname -n`);
# $hostname = "your.hostname.here";
to:
# chop($hostname = `uname -n`);
$hostname = "yourown.hostname.edu";
o LDM-6's ldmadmin now waits until the rpc.ldmd processes have all
exited before returning you to the Unix command prompt
o LDM-6 now understands CONDUIT and CRAFT as the NMC2 and NEXRD2
streams.
o Some early tests using synthesized data showed that LDM-6 was capable
of moving 8.4 times more data than LDM-5. The increase in "efficiency"
using real data has, however, not yet been quantified, but qualitatively
we can assure that the increase in "efficiency" is real. For reference,
the early tests that showed the 8.4 times increase was conducted between
a machine here at the UPC, and a Linux PC running at the Universidade
Federal do Para in Belem, Brazil using synthetic products that were
each 200KB in size. Also, during the test, the client LDM did not
write into a product queue.
N.B. (nota bene/yo):
During stress testing of the LDM-6, we learned that there is a class of
"pathological" regular expressions that adversly affect the performance
of LDM servers. Steve sent a note to ldm-users explaining how to
identify pathological cases, and what to do to correct these.
Unfortunately, it is the client requesting data that has control over
these regular expressions, so if you find these in your ldmd.log files,
you will need to contact the downstream host's administrator and ask
him/her to correct the pattern. Steve has included a new function in
LDM-6, regex, that can be used to test regular expressions for
pathologicalness ;-). Check the regex man page for more information
after you install LDM-6.
To upgrade to LDM-6, then you should do the following:
1) make backup copies of your ~ldm/etc/ldmd.conf file(s). While
you are at it, you could make a backup copy of your ~ldm/etc/pqact.conf
file, but this is optional since it will not be affected by moving
to LDM-6.
2) FTP LDM-6 release candidate 6.0.2:
<login as 'ldm'>
cd ~ldm
ftp ftp.unidata.ucar.edu
<user> anonymous
<pass> your_full_email_address
cd pub/ldm/test
binary
get ldm-6.0.2.tar.Z
quit
zcat ldm-6.0.2.tar.Z | tar xvf -
3) build LDM-6. Note that LDM-6 is built with '-O' optimization
turned on. If you want to build otherwise, you will want to set
the Unix environment variable CFLAGS _before_ you run configure.
Also, you should define the Unix environment variable LDMHOME
_before_ you run configure:
setenv LDMHOME your_ldm_home_directory
cd ~ldm/ldm-6.0.2/src
./configure
make && make install
4) finish the LDM install as 'root':
sudo make install_setuids
5) adjust entries in ldmadmin to match those from your existing
ldmadin. This should boil down to you changing the product queue
size; the number of log files that you want to keep online (we keep
14 on our IDD machines); uncommenting out the entry for udunits if
you are running things like gribtonc; filling in your full hostname
if a 'uname -n' does not return a fully qualified hostname; etc.
6) shutdown your current LDM waiting for all LDM processes to exit.
This step is easier in LDM-6 since ldmadmin won't return you to
the Unix/Linux prompt before processes have exited.
7) add the execution of the real time statistics routine, rtstats
to your ~ldm/etc/ldmd.conf file:
add:
exec "rtstats -h rtstats.unidata.ucar.edu"
somewhere in the list of 'exec's at the top of ldmd.conf
8) change the runtime link to point at ldm-6.0
cd ~ldm
rm runtime && ln -s ldm-6.0.2 runtime
9) verify that your operating system has finished flushing the LDM
queue from memory to disk. I found that this was an important
step in getting things to work smoothly on thelma. I did
the verification by watching the iostat listing of top. As soon
as it quites down, you are ready to go. Our experience is that
the larger the queue, the longer this step takes. We even added
a 'sync' call from ldmadmin to tell the OS to sync to disk before
shutting down LDM processes.
10) start LDM-6:
rehash <- C shell only
ldmadmin start
I think I have covered all bases in this note, but you never know.
After your LDM-6 is up and running, and you are reporting real time
statistics, you can review latencies, datastream volumes, datastream
product numbers, and topology at:
http://www.unidata.ucar.edu/staff/chiz/rtstats
This web page will likely change in the future, but it is very useful
right now.
If you would help doing the upgrade or have any questions, just let us know.
Tom Yoksas