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

[LDM #RJG-715043]: LDM feed configuration...suggestions for improving the LDM

Gilbert,

> A guy I know from a company is testing out a NNEXRAD feed; he's using Iowa
> State as a primary and testing with me as a backup. He sent me this and it
> offered what I think is constructive improvements that could better the
> LDM. What do you think?
> 
> ------------
> I was reading the LDM Email archive just now and found a post from Unidata
> that gives a brief overview of the switching. Here's what I understand
> happens when things are flowing smoothly:
> 
> 1) iastate.edu is the primary feed
> 2) niu.edu is the secondary feed
> 3) My LDM receives a product from iastate.edu
> 4) niu.edu later offers the same product
> 5) My LDM says to niu.edu "forget it", and no data is transferred
> 
> Now, we reverse this to where your server supplies products faster than
> iastate.edu:
> 
> 1) iastate.edu is still the primary feed
> 2) niu.edu is still the secondary feed
> 3) niu.edu offers a product to my LDM that iastate.edu hasn't sent already
> 4) My LDM says "thank you" and downloads the data
> 5) iastate.edu sends the same product
> 6) My LDM downloads the data but tosses it
> 
> 
> According to the Unidata post, if your server sends "enough" products faster
> than iastate.edu, my LDM will switch niu.edu to the primary and iastate.edu
> to the secondary. It's that "enough" part that isn't defined in the email
> archive.
> 
> In looking at the LDM 6.6.5 source, the critical file appears to be
> "autoshift.c". The switching code collects information for 2 times the
> pq_suspend sleep interval then uses a simple comparison of the number of
> products accepted vs. rejected. It's this comparison that's the problem. I
> guess they decided on the current implementation because the alternate feed
> mode is less efficient than the primary feed mode. If I understand
> everything correctly, the primary server sends a HEREIS containing the data.
> The secondary server sends a COMINGSOON notification to which my server
> replies with a YES or NO, depending on whether it's already received the
> product from the primary. It's this YES/NO interchange that they're trying
> to avoid by doing a simple check of the accepted/rejected numbers.
> 
> What I would recommend is that they:
> 
> a) Allow us to independently configure the switch time interval
> b) Allow us to set the percentage of the accepted/rejected products
> c) Add in product time deltas to the switching logic
> 
> Right now, a) is fixed at 2X the pq_suspend time (which is 30 seconds); b)
> is fixed at 50/50, and c) is absent.

Your friend's analysis is, for the most part, correct.

What's the "problem", however, that he's trying to solve?

> Gilbert
> 
> *******************************************************************************
> Gilbert Sebenste                                                     ********
> (My opinions only!)                                                  ******
> Staff Meteorologist, Northern Illinois University                      ****
> E-mail: address@hidden                                  ***
> web: http://weather.admin.niu.edu                                      **
> *******************************************************************************

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: RJG-715043
Department: Support LDM
Priority: Normal
Status: Closed