Interesting feature on LDM 6.4.7.5

[Steve Emmerson]

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                                      **
> ******************************************************************************* 
> 
>