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

20050331: ldm on unidata2 now using dvb1 as primary (cont.)

>From: Jerrold Robaidek <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200503312042.j2VKgsv2027409 IDD feed requests

Hi again Jerry,

re: thanks for updating unidata2 to feed from dvb1

>No problem.  I wanted to get this done today, since we try not to make
>changes like this on a Friday.

I know the feeling...

re: request feed request realignments on unidata2

>Done .....

Thanks for the quick work!  This will also make the ETA grid 218 data
available to systems requesting data from unidata2.

Oops.  I see that even though the requests on unidata2 have been
changed, dvb1 is not configured to honor them:

% ssh address@hidden
Last login: Fri Mar 25 19:49:41 2005 from dcarchive.ssec.
$ notifyme -vxl- -f ANY -h dvb1.ssec.wisc.edu
Mar 31 23:04:37 notifyme[713]: Starting Up: dvb1.ssec.wisc.edu: 
20050331230437.096 TS_ENDT {{ANY,  ".*"}}
Mar 31 23:04:37 notifyme[713]: Connected to upstream LDM-5
Mar 31 23:04:37 notifyme[713]: NOTIFYME(dvb1.ssec.wisc.edu): 7: Access denied 
by remote server
^CMar 31 23:04:39 notifyme[713]: Interrupt
Mar 31 23:04:39 notifyme[713]: exiting

re: new version of LDM will have auto adjusting feed requests

>Wow!  Very cool.   So I can set my PRIMARIES and ALTERNATES to always be
>PRIMARY, and which path is fastest will be used?

You can already do that at the expense of network bandwidth (in fact,
this is what I just asked to you to do).  When one requests the same
feed from two or more different sources using the PRIMARY designator,
all upstreams will send the products without asking.  The first one
that is received will be put into the LDM queue; the others will be
thrown away by the duplicate product detection (through MD5 checksums)
that is built into the LDM.

The new feature that I was referring to is that you could start off
specifying that you wanted PRIMARY feed from multiple upstreams, and
the one that is consistently fastest will remain PRIMARY while the
other one(s) will change to ALTERNATE.  The idea is to get the data
from the fastest source available while still having a backup.  This
mode of operation will be much more sparing of network bandwidth
since an ALTERNATE feed results in the upstream asking the downstream
if it wants each product.  It does this by exchange of the product's
MD5 checksum and metadata, not by sending the product.

In the above scenario, if the connection to the PRIMARY feed goes down
(the backhoe option), then the ALTERNATE that starts getting the
majority of the products will transition to a PRIMARY request.  We
(Steve Emmerson) are working on the transition strategies currently.
What we want to insure is that the setup does not start "thrashing"
(flipping back and forth between feed strategies for upstreams that can
provide the desired data at essentially the same rates).

re: thelma feeds from mapmaker, so removing the feed from thelma loses you

>Also done.


>If you see anything I missed, go ahead and update it .... and let us know.

I am pretty sure that the feed requests on unidata2 have all been taken care of:

request ANY     ".*" dvb1.ssec.wisc.edu PRIMARY
request WMO|NGRID       ".*" thelma.ucar.edu PRIMARY
request NNEXRAD|FNEXRAD ".*" thelma.ucar.edu PRIMARY
request DIFAX   ".*" mapmaker.aos.wisc.edu PRIMARY
request NLDN    ".*" striker2.atmos.albany.edu PRIMARY

The thing that needs to be done is modify the allow lines in ~ldm/etc/ldmd.conf
on dvb1 to allow unidata2 to request data.


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.