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@xxxxxxxxxxxxxxxxxxxxx ***
web:
http://weather.admin.niu.edu **
*******************************************************************************
--
Beware programmers who carry screwdrivers.
-------------------------------------------
Karen.Cooper@xxxxxxxx
Phone: 405-325-6982
Cell: 405-834-8559
SAIC/Systems Analyst
National Severe Storms Laboratory
