In a previous message to me, you wrote:
>Pete,
>
>There are several options that feed back from the users would be helpful
>in moving forward:
Steve,
Thanks for getting back to me on this so quickly. My thoughts below:
>
>One pending action item from Last June was to remove the ETA
>awip20 (grid 215) files when ETA218 was available. Does anyone
>rely on these files from CONDUIT? Would the ETA218 grids in
>NOAAPORT (GRIB2 format in DVB-S) eliminate the need for
>grid 215 in CONDUIT?
We (UWisc-AOS) could definitely live w/o the 215 grids. We're currently
not using them at all. That doesn't really reduce the data stream
all that much though, compared to the increase from the 0.5 deg GFS,
does it?
>
>As an alternative to removing the 0.5 degree GFS, would it be useful
>to keep the highest resolution grids available for f000-f084 and
>remove the 1 degree grids for the period of time where the two sets
>overlap?
This is a good idea, however I suspect many of us are using software
that does not yet read the GRIB2 format files. How easy or hard would
it be to come up with a conversion utility that would read the 0.5 deg
grib2 data and convert into either 0.5 deg GRIB (with similar format,
parameters that we currently have) or to average out to a 1 deg format
in the same format as the current 1 deg files? Is this even feasible?
>
>There are a number of data sets which users have expressed interest
>in adding, though clearly it is not advisable to be adding with the
>current limitations.
I agree, adding anything at this point would only make things worse.
Would having multipile ingest boxes, each doing different parts of
the conduit feed make any difference, or would that just pass the
delay and backlog downstream to the top level relays?
How about another "experimental" conduit feed, or one for new, or
GRIB2 formatted data that the new data could be tested on without
any expectation of regular timely delivery? I guess CONDUIT does
not 'guarantee' timely delivery, but it has been so reliable over
the past couple of years that many of us have come to depend on
the products in it, and pretty much expect it to be reliable.
It seems to me that the problem we are seeing, or trying to get
around, is that there are short periods where LOTS of data becomes
available, and while we'd all like to get the data as soon as it is
available, the current latency of the network and/or ldm is just not
capable of handling the large bursts in a reliable and predictable
manner.
My rambling thoughts.. Personally, I'd still vote to remove the 0.5 deg
gfs data from the CONDUIT stream for now..
Pete
>
>Steve Chiswell
>Unidata User Support
>
>On Fri, 4 Feb 2005, Pete Pokrandt wrote:
>
>>
>> All,
>>
>> 06 UTC GFS didn't start coming in here until after 12 UTC this AM.
>> It's just now finishing up at 14:31 UTC.
>>
>> I'd like to second Robert's suggestion from a few weeks ago that
>> we back out of the 0.5 deg GFS data until we can resolve these
>> speed issues.
>>
>> I haven't had time to even look at the 0.5 GFS data yet; is anyone
>> using it?
>>
>> Pete
>>
>> --
>> +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
>> ^ Pete Pokrandt V 1447 AOSS Bldg 1225 W Dayton St^
>> ^ Systems Programmer V Madison, WI 53706 ^
>> ^ V address@hidden ^
>> ^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
>> ^ University of Wisconsin-Madison V 262-0166 (Fax) ^
>> +<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
>>
--
+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
^ Pete Pokrandt V 1447 AOSS Bldg 1225 W Dayton St^
^ Systems Programmer V Madison, WI 53706 ^
^ V address@hidden ^
^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
^ University of Wisconsin-Madison V 262-0166 (Fax) ^
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
