[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


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.