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

Re: 20011004: COMINGSOON and DBUFMAX

Unidata Support wrote:
> 
> ------- Forwarded Message
> 
> >To: address@hidden
> >From: Gregory Grosshans <address@hidden>
> >Subject: COMINGSOON and DBUFMAX
> >Organization: UCAR/Unidata
> >Keywords: 200110042202.f94M24113626
> 
> I'd like to make sure I correctly understand an aspect of LDM.  In LDM
> DBUFMAX is defined as 16384.  For example, sites A and B each  receive
> radar imagery locally and insert it into LDM.  The LDMs at each site are
> also configured to request radar data from each other via LDM.  Is it
> correct the LDM at each site will send a COMINGSOON, but if both sites
> inserted the radar product from the local feed the LDMs will know its a
> duplicate product and not request the remainder of the radar product?
> In particular, the radar imagery is over 300,000 bytes.
> 
> Doesn't this mean  as long as a product is over 16K the entire product
> is not sent if the downstream LDM has already received the product, only
> the first block of data is sent?
> 
> Thanks,
> Gregg Grosshans
> SPC
> 
> ------- End of Forwarded Message

Hi Gregg,

Yes, it's true that if site A is fed by site B and if site A already got
the product locally, then it will determine that it already has the
product when B either tries to send it or actually sends it.  Like you
said, which action actually happens depends on the size of the product. 
If the product is less than 16K site B will send the product regardless
and site A will drop it. But if the product is greater than 16K site B
will send a COMINGSOON, and site A will tell B that it that it already
has the product, and B won't send it.  The first 16K may get sent along
with the COMINGSOON message, I'm not sure.  But it would make sense if
the packet size is 16K.

You can confirm this by turning on verbose logging in the appropriate
rpc.ldmd process, that is, the rpc.ldmd process that exists to feed from
site B.  You can get that info from the logs if you can find lines in
there making the last connection to your upstream feed.  (If the
connection is old enough that info might be expired from your logs.)  

From the log you'll need the PID for that appropriate rpc.ldmd
process.   To cycle the logging, send that process a USR2 signal, 'kill
-USR2 <PID>'.  Sending this command successively will cause that
rpc.ldmd process to cycle through: quiet, verbose, and debug level
logging in that order.  Verbose should be plenty for this purpose.  

These additional logging levels will make your log very large very fast,
so I would advise you not to run very long in this manner.  But it is
interesting to see what is going on.  You can see the block sizes as
they arrive, and rejections as well, presumably.  I guess I haven't
actually seen such a rejection as it's never happened while I'm running
in verbose mode.

Anne
-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                  P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************