Gilbert,
(Sometimes it's amazing what a diagnostic message can show).
Gilbert Sebenste wrote:
I am also seeing this from my Level 2 (NEXRAD2) feed:
Jan 20 05:26:45 weather3 notam.atmos.uiuc.edu[6135] WARN: Product from
"bdds-kshv.nexrad.noaa.gov_v_notam.atmos.uiuc.edu" was created too far
in the future: 12c539f8fae232ec8713bb7dbd22a9e7 17330
20070120052835.334 NEXRAD2 193040 L2-BZIP2/KSHV/20070120052324/193/40
Jan 20 05:26:45 weather3 notam.atmos.uiuc.edu[6135] WARN: This will
degrade performance when downstream LDM-s reconnect. Ensure that local
and origination clocks are accurate.
And:
Jan 20 05:28:46 weather3 bigbird.tamu.edu[6136] WARN: Product from
"bdds-kcle.nexrad.noaa.gov_v_bigbird.tamu.edu" was created too far in
the future: 0bdef143c927acb2f0ac953075c0b901 14037 20070120054849.583
NEXRAD2 486022 L2-BZIP2/KCLE/20070120054547/486/22
Jan 20 05:28:46 weather3 bigbird.tamu.edu[6136] WARN: This will degrade
performance when downstream LDM-s reconnect. Ensure that local and
origination clocks are accurate.
NEXRAD-II stations KCLE and KSHV do, indeed, have inaccurate clocks,
which result in the warnings you see in the beta LDM. I'm currently
working with the Radar Operations Center to see what can be done.
The first machine is always the one whose time is incorrect, right?
The format of the "origin" member of a data-product's metadata is
<ingest _host>_v_<immediate_upstream_host> (where the angle brackets
aren't part of the format). So, yes, the first host is the one with the
bad clock.
In
this case, it would be bdds-kshv.nexrad.noaa.gov and
bdds-kcle.nexrad.noaa.gov. If the NWS sites are off from the level 2
data, (which at least two are), who do we contact?
And how far "off" is "off" before the LDM complains? 1 minute? 10 seconds?
The amount is arbitrary, but is currently set at 30 seconds (which is
comparable to other time intervals used by the LDM).
Regards,
Steve Emmerson
