This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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