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@xxxxxxxxxxxxxxxxxxxxx ***
web: http://weather.admin.niu.edu **
*******************************************************************************
