Re: new NOAAPORT NIDS products


> 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

  • 2001 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the ldm-users archives: