20020730: 20020730: LDM latency problem - followup

>From: Mike Voss <address@hidden>
>Organization: SJSU
>Keywords: 200207302019.g6UKJL905705 IDD latency

Mike,

>I have the master of support, I feel my luck could change!!

Man, is that a lot to live up to, or do I feel smoke creeping up my leg ;-)

>OK...I have been splitting the feed for months, here a a snip of my ldmd.conf:
>
>------
>#request NEXRAD "^SDUS5." aeolus.ucsd.edu 
>#request NMC3 ".*" aeolus.ucsd.edu
>#request NEXRAD "/pN0R" typhoon.atmos.ucla.edu
>
>#request (DDPLUS|HDS)
>#        ".*"
>#        typhoon.atmos.ucla.edu.
>request DDPLUS
>        ".*"
>        aeolus.ucsd.edu. 
>request HDS
>        "^Y.*"
>        132.239.114.58
>#request MCIDAS "^pnga2area Q[01]" typhoon.atmos.ucla.edu        
>request MCIDAS "^pnga2area .*" aeolus.ucsd.edu
>request NLDN ".*" striker.atmos.albany.edu
>-------------

Which is:

request DDPLUS ".*"            aeolus.ucsd.edu. 
request MCIDAS "^pnga2area .*" aeolus.ucsd.edu
request HDS    "^Y.*"          132.239.114.58
request NLDN   ".*"            striker.atmos.albany.edu

(easier for my tired eyes to read)

The upshot of this is that you are feeding DDPLUS and MCIDAS using one
rpc.ldmd; HDS on another rpc.ldmd; and NLDN on a third rpc.ldmd.  The
reason that there are not 4 rpc.ldmds is that all request lines
specifying the same host are accumulated into a single rpc.ldmd
invocation.

>Is there another way I should be splitting this up?

Well, your original message seemed to indicate that you would see large
latencies on all feeds, but that DDPLUS and MCIDAS would catch up.  I
take this to mean that the HRS (HDS, same thing) feed would not catch
up.  Please let me know if I am wrong on this.

>One other reason this "seems" like a network/connectivity issue to me is
>that when I feed one of my internal machines, methost8 for example, from
>rossby the data just pours in until the que is caught up. But I tried
>feeding this same machine from aeolus, as mentioned in the previous email,
>and it drags along.

Did you ever check to make sure that the data was timely on aeolus?
The times you are comparing are the time of injection of a product into
the IDD with your clock time.  If there is slowness somewhere up the
line, then you will be affected by it.  The way I check for this condition
is by running two simultaneous notifyme commands, one for the local
host and one for the upstream feed site.  Since notifyme will tell you
when the host in question receives a product, you can judge how long
it takes for a product seen on the upstream host to make it to your
machine.  I just ran this to your machine and Larry's machine at UCSD,
and the outputs from each are in virtual lockstep.  At the moment, however,
there is no HRS data coming in to either.

>Let me know what other info you might need. Thanks!

How about a login as 'ldm' on rossby?

Tom
**************************************************************************** <
Unidata User Support                                    UCAR Unidata Program <
(303)497-8643                                                  P.O. Box 3000 <
address@hidden                                   Boulder, CO 80307 <
---------------------------------------------------------------------------- <
Unidata WWW Service                        http://www.unidata.ucar.edu/      <
**************************************************************************** <