On Thu, 29 Nov 2001, Stonie R. Cooper wrote:
>
> Interesting approach; it would be a good mental game to see how much the SBN
> time differs from the internet provided atomic clock NTP.
>
> Certainly, NOAAPort receive paradigms differ from vendor to vendor -
> especially when it comes to injecting data from the SBN into an LDM. One
> reason that our time stamps on some of the first NEXRAD products for a volume
> scan are the same as the header - i.e. a 1730Z product being completely
> written by 1730Z on the system - is that our LDM injection facility streams
> the data directly to the queue, as opposed to buffering and pqing'ing. I
> can't say that one method is better than the other . . . just different. It
> does help explain differences in latency, though, when troubleshooting larger
> issues external to the NOAAPort receiver - such as NCF uplink issues,
> internet drops on IDD, etc.
>
> We've sufficiently beat that dead horse.
>
> Stonie
>
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.)
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!)
So, is my software out of whack or are the time sync frames that far off?
(It wouldn't surprise me if the NWS wasn't minding the clocks to the nth
degree.)
- Bryan
-----------------------------------
Bryan C. Hahn
Regional Weather Information Center
University of North Dakota
