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.
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.
Blair, I'm shocked you are not getting any replies. I wish I could be of further help. Our NEXRAD2 and NEXRAD3 ingest LDM is not seeing any delays in retrieval or writing the last chunk to disk. I don't believe we ever experienced this issue, as I also went through our machines when you sent the original email and could not identify any problems. Let me know if there is any other way that I can help you. I'm more than willing to poke around our LDM machines and relay any information that might assist you. On Sun, May 11, 2014 at 2:39 AM, Blair Trosper < blair.trosper@xxxxxxxxxxxxxxxxxxx> wrote: > Specifically, we seem to be waiting on VERY the last chunk of each scan. > > So, for example, we have had the first 2,121,333 bytes of the 02:22:31 UTC > scan from KAMA, but didn't get the remaining 241,733 bytes until 02:32:09 > UTC. Total file size was 2,363,066 bytes. > > We were waiting exactly 9 minutes 38 seconds for the last 236KB of the > file on all three servers that pull down NEXRAD2 from three separate > providers. > > Same problem on all our (geographically and backbone diverse) servers that > pull in NEXRAD2 (from multiple providers who are similarly geographically > and backbone diverse)...and none of us is lagging. > > Am I losing my mind? Can someone please explain to me what's going on > here...and if we're the only ones still seeing this issue? > > > On Sat, May 10, 2014 at 9:20 PM, Blair Trosper < > blair.trosper@xxxxxxxxxxxxxxxxxxx> wrote: > >> We are still seeing this. I know the TOC was made aware of this issue >> two weeks ago, but despite all our servers being 0 seconds lagged on the >> NEXRAD2 feed tree, our data (from multiple providers who are also not >> lagged) is at least 10 minutes behind. >> >> Also, this page is a 500 internal server error and has been for months, >> and nobody has fixed it or seems to even notice: >> http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/rtstats_topogif?NEXRAD2 >> >> And this one takes over a minute to load: >> http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/rtstats_feedtree?NEXRAD2 >> >> ...but you can verify from the second link that we're not lagging (search >> for "tampa" or "chicago"). >> >> >> On Mon, Apr 28, 2014 at 7:33 PM, Blair Trosper < >> blair.trosper@xxxxxxxxxxxxxxxxxxx> wrote: >> >>> Am I crazy, or is anyone else seeing the 10+ minute lag on both feeds? >>> >>> It will occasionally come into sync, but then fall behind again. On one >>> of our servers that pulls the firehose of both, it's ingesting at 4.5 MB/s, >>> which is the highest I've ever seen. >>> >>> Perhaps an issue with NOAAPort or the data volume is too much for the >>> NOAA infrastructure? Or perhaps an issue with Internet2 itself? >>> >>> Then again, I might just be crazy, despite having excellent providers. >>> >>> ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ >>> ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ >>> Blair Trosper >>> Updraft Networks / Weather Data >>> NOC: 469-844-5440 >>> Early Watch Notifications: http://twitter.com/weatherwatches >>> >> >> >> >> -- >> >> ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ >> ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ >> Blair Trosper >> Updraft Networks / Weather Data >> NOC: 469-844-5440 >> Early Watch Notifications: http://twitter.com/weatherwatches >> > > > > -- > > ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ > ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ ∙ > Blair Trosper > Updraft Networks / Weather Data > NOC: 469-844-5440 > Early Watch Notifications: http://twitter.com/weatherwatches > > _______________________________________________ > ldm-users mailing list > ldm-users@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ >
ldm-users archives: