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

20030930: switch feed from squall to flood and upgrade to LDM-6.0.14

>From: "Bret D. Whissel" <address@hidden>
>Organization: FSU
>Keywords: 200309300045.h8U0jvk1023216 IDD LDM upgrade

Hi Bret,

>Thanks for the info, Tom.  I've changed the connections,

Thanks!  I see that pluto is now pointing at idd.nrcc.cornell.edu
for the feeds it was requesting from squall.atmos.uiuc.edu.  The
three machines that were incorrectly feeding from squall are now
pointed at other relay nodes, so David can remove the allows on
squall without affecting anyone's data feeds.

>and I'll upgrade pluto.met as soon as I have a chance.

OK.  We will be able to see the change as soon as the upgrade is
complete and you have stopped and restarted your LDM.  For reference,
we monitor your real time stats online at:

Real time stats site list
http://www.unidata.ucar.edu/staff/chiz/rtstats/siteindex.shtml

pluto.met.fsu.edu
http://www.unidata.ucar.edu/staff/chiz/rtstats/siteindex.shtml?pluto.met.fsu.edu

>We have also been feeding
>from idd.nrcc.cornell.edu, but they seem to have had several outages of
>late.

You can feed from flood.atmos.uiuc.edu.  It has been performing
well for an extended period of time (outside of a minor clock drift
that has been fixed).

>We typically split feeds so that WMO comes from Cornell, and FSL2
>& MCIDAS from UIUC.

OK.  Another approach possible with LDM-6 is to setup PRIMARY
and ALTERNATE feed requests.  Here is a simple example:

request WMO     ".*"    flood.atmos.uiuc.edu    PRIMARY
request WMO     ".*"    idd.nrcc.cornell.edu    ALTERNATE

and so on.

The difference between a PRIMARY and ALTERNATE feed request is the
PRIMARY request tells the upstream LDM to simply send the products
requested as soon as it has them.  The ALTERNATE request tells the
upstream to ask if a product is wanted before it is sent.  If the
answer is yes, then the entire product is sent in one transacdtion.
The ALTERNATE request is somewhat like that employed in LDM-5, but
there, products larger than 16KB were split up into a number of 16 KB
chunks and each of those were sent using a blocking RPC call.  LDM-6's
method of semi-LDM-5 delivery is much more efficient than LDM-5 was.
Its LDM-6 PRIMARY deliver is _WAY_ more efficient than either LDM-5 or
the ALTERNATE mode delivery.  The best indication of this assertion is
the latest stress test we ran on the top level IDD node,
thelma.ucar.edu.  We were able to relay 1.4 TB/day 
sustained over the last two days of the test.  Peak (unsustained) rates
reached 2.8 TB/day and we routinely exceeded a 2.2 TB/day rate.

>I inherited our ldmd.conf without an authoritative
>history of what our connections should be.  If you have other info about
>how we are supposed to be connected, I'd love to have it!

For now, keep feeding from flood.atmos.uiuc and idd.nrcc.cornell.edu.
As the reorganization of the IDD progresses, we will likely be
asking you to change your requests to other machines.  Stay tuned :-)

Thanks for the help!

Tom