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/
>
