Bryan,
> One last whack on that poor horse.
>
> I'm kind of surprised that anyone would try to use the SBN Sync Timing
> Frames. Our ingest software keeps track of these frames, and this is what
> I see today:
>
> NWSTG: 52-53 seconds behind
> GOESE: 60-61 seconds behind
> GOESW: 31-32 seconds behind
>
> (I'm unsure of the fourth channel.)
It depends on what you are trying to do . . . especially for our remote
customers, it is the only time they have available. Our lab is a secured
facility because of our customer base . . . so that is almost the only time
available. You are correct, but it's actually compounded further.
The time sync messages are off by 51 seconds. The SBN applied time stamps
are actually off an additional 44 seconds.
The SBN field is queued separately. We've actually had a lengthy discussion
with NOAA, and then an explanation from the PRC lead developer for NOAAPort -
the "source" - and the latency is manufacturered, and not real. The reality
is the "real" latency on products is on the order of 3 to 5 seconds, in most
cases - but we see the same stats that you do because we are all bound to the
same SBN:
-------------------------------------------------------------------------------
Time on Queue Statistics - Units are in seconds, for both NCF and local.
-------------------------------------------------------------------------------
Channel - NCF Max - NCF Ave - NCF Max WMO - local Max - local Ave
-------------------------------------------------------------------------------
NWSTG Queue - 6855 - 51 - HHIE20 EGRR 300000 - 0 - 0
GOESEast Queue - 60 - 53 - TIGN05 KNES 011215 - 0 - 0
GOESWest Queue - 98 - 47 - TIGF05 KNES 301430 - 0 - 0
DCP Queue - 85 - 1 - YDYC98 KWBE 010000 - 0 - 0
-------------------------------------------------------------------------------
This is because the clock that assigns the SBN time stamp, as admitted by the
folks that maintain NOAAPort, has drifted and has not been corrected. In the
stats I show above, for instance, you also note maximum times on queue at NCF.
Well, these don't tell the whole story, either. The AWIPS sites
automagically monitor lost frames and send a request to retransmit via the
WAN . . . but when the product is retransmitted, it does not get a new SBN.
The 6855 seconds on the retransmit for HHIE20 that you see is not a real
delay, but rather the result of having the product retransmitted later by
request. And, if you average based off this info, your average will also be
scewed even further.
> And these times aren't attributable to latencies on our end. Our ingest
> software is looking at these frames as they arrive. The only lag would be
> in the device driver. (And I'll guarantee the driver isn't queuing 52
> seconds of NWSTG frames!)
As does ours - and we raised the issue with NOAA when the clock began to
drift this past summer. That is when we had an exchange with LeRoy Klet at
PRC and were educated to the whole issue. It hasn't solve the problem, as we
had hoped by raising it would, but they are aware that someone noticed . . .
> So, is my software out of whack or are the time sync frames that far off?
Again, they have admitted to the drift, and haven't done anything to correct
it. Interesting further, when NOAA does a failover to the secondary uplink,
the time is correct. The two NCF uplinks are not even synced.
We can dial into the Naval Observatory for time from the lab from time to
time (no play on words intended), and thus we know what the "real" time is.
It would help, possibly, if more people complained to NOAA about the SBN
being off.
--
Stonie R. Cooper,
Science Officer
Planetary Data, Incorporated
3495 Liberty Road
Villa Rica, Georgia 30180
ph. (770) 456-0700; pg. (888) 974-5017; fx. (770) 459-0016
