NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
ldm-users
archives: