Interesting feature on LDM 6.4.7.5

[Karen Cooper]

Steve,

I agree with Gilbert that this is a GOOD thing.  Incorrect clocks often 
go unnoticed, and I have seen them cause losses of data as well as other 
problems.  As Gilbert stated these error messages make it easy to 
diagnose the problem and correct it quickly. 

Steve Emmerson wrote:
> Gilbert,
>
> I wondered if you were going to comment on this beta release.  :-)
>
> Remember, people, this is a beta release: the 6.4.7 production version 
> isn't out yet.  A few kind soles are testing it for me (and then, of 
> course, there's Gilbert :-).
>
> While the beta version looks good, I'm of two minds regarding the new 
> log messages.  We've said for years (going on decades) that the system 
> clock of an LDM host must be accurate (this is actually an explicit 
> requirement in the LDM documentation).  Nevertheless, there appear to 
> be quite a few sites that do not run accurate clocks.  If I release a 
> version 6.4.7 that, by default, logs messages about inaccurate clocks, 
> then I expect to receive more than a few inquiries as people's disk 
> drives fill-up with log messages.  On the other hand, this most likely 
> is the best way to get people to finally synchronize their clocks.
>
> And in case you're wondering, significantly inaccurate clocks really 
> do degrade the performance of the LDM and can even result in incorrect 
> behavior (e.g., product loss!).
>
> Everyone, if you have a considered opinion on this matter, now might 
> be a good time to express it.
>
> With regards,
> Steve Emmerson
> LDM Developer
>
> Gilbert Sebenste wrote:
>> LDM-users,
>>
>> I see a problem tonight for some folks on the latest and greatest LDM 
>> beta. The new beta version demands that you and the upstream data site
>> from you has an accurate clock. Otherwise, if you look at your log 
>> files, you see something like this:
>>
>> Jan 19 06:02:12 weather 131.156.X.XXX[7869] WARN: Product from 
>> "mapmaker_v_131.156.8.XX" was created too far in the future: 
>> fc779d96a88d76bb68f8017aa6304a49   525926 20070119073112.751   DIFAX 
>> 000 85x11_sfcmap_06Z.ps.gz
>>
>> Jan 19 06:02:12 weather 131.156.X.XXX[7869] WARN: This will degrade 
>> performance when downstream LDM-s reconnect. Ensure that local and 
>> origination clocks are accurate.
>>
>> In the case of this machine, it makes it easy to see that this 
>> machine is about 90 minutes ahead of its time. :-) I'll have to ask 
>> Pete to see if he can fix this up at U-W Madison, but just be aware, 
>> if you don't have NTP
>> installed, prepare for a lot of warn messages in your logs! When this 
>> gets released to production, if this feature is maintained, be aware 
>> that your clock needs to be accurate, or else!
>>
>> Frankly, I like it because it lets me see exactly where the problem 
>> is. My clocks should always be spot on, since they are synced with 
>> NTP servers elsewhere. If they're not, I see error messages and I can 
>> quickly diagnose the problem, since I might also have data loss. Nice 
>> touch, UNIDATA!
>> (and yes, it works fine for me so far. I have it on 
>> weatherx.admin.niu.edu
>> running with no problems.)
>>
>> ******************************************************************************* 
>>
>> Gilbert Sebenste                                                     
>> ********
>> (My opinions only!)                                                  
>> ******
>> Staff Meteorologist, Northern Illinois 
>> University                      ****
>> E-mail: 
>> sebenste at weather.admin.niu.edu                                  ***
>> web: 
>> http://weather.admin.niu.edu                                      **
>> ******************************************************************************* 
>>
>>
-- 
Beware programmers who carry screwdrivers.

-------------------------------------------
Karen.Cooper at noaa.gov

Phone:  405-325-6982
Cell:	405-834-8559
SAIC/Systems Analyst
National Severe Storms Laboratory