20051004: IDS DDS problem? (cont.)

>From: =?ISO-8859-1?Q?Christian_Pag=E9?= <address@hidden>
>Organization: UQAM
>Keywords: 200510041834.j94IYLG7018300 IDD

Hi Christian,

re:
>Thank you very much for your very thorough explanation of what happened.

No worries.

>I discontinued the use of Lyndon state relay.

Very good.  I will be contacting Lyndon today to investigate further.
I do know, however, that they are running their own NOAAPORT ingest
system, and I believe that it is not compatible with the IDD.  Given
this, they can not be used as a relay in the IDD.

>The options I have for alternate feeds, given ldmping stats and
>traceroute, are either:
>unidata3.bgsu.edu
>vortex.esc.brockport.edu
>atm.geo.nsf.gov

Since unidata3.bgsu.edu feeds from atm.geo.nsf.gov, there would be no
redundancy in feeding from both.  As far as vortex.esc.brockport.edu,
they occasionally have problems.  atm.geo.nsf.gov is a toplevel relay
that we manage, so I am most comfortable with you feeding from it.

>The ldmping and traceroute shows that the network response is very
>fast, and that goes through Internet2 (canet4 in canada), which is the
>best for us, since there are no restriction on the bandwidth.
>
>Here are the stats:
>
>ldmping unidata3.bgsu.edu
>Oct 05 00:24:56 INFO:      State    Elapsed Port   Remote_Host        
>  rpc_stat
>Oct 05 00:24:56 INFO: RESPONDING   0.176873  388   unidata3.bgsu.edu
>
>ldmping vortex.esc.brockport.edu
>Oct 05 00:24:59 INFO:      State    Elapsed Port   Remote_Host        
>  rpc_stat
>Oct 05 00:24:59 INFO: RESPONDING   0.088093  388   vortex.esc.brockport.edu
>
>ldmping atm.geo.nsf.gov
>Oct 05 00:25:24 INFO:      State    Elapsed Port   Remote_Host        
>  rpc_stat
>Oct 05 00:25:24 INFO: RESPONDING   0.048863  388   atm.geo.nsf.gov
>
>ldmping flood.atmos.uiuc.edu
>Oct 05 00:29:30 INFO:      State    Elapsed Port   Remote_Host        
>  rpc_stat
>Oct 05 00:29:30 INFO: RESPONDING   0.081019  388   flood.atmos.uiuc.edu

These are all very good.  By the way, if you let ldmping run for
awhile, the Elapsed numbers should get smaller.  The initial number is
most typically the worst.

>nsf is the fastest one, but brockport follows closely, as well as
>uiuc. I guess that any of them are ok.

Yes, any are OK.

>Maybe I should choose the one
>that has a feed which comes from a different master server,

This is a good plan.

>but I am
>not sure which master server are feeding through these possible
>alternate feeds.

You can always use the real time stats pages to determine the path the
data goes through to get to a node.  Simply go to the real time stats
page for the upstream host you are interested in and click on the
'topography' link for the feed you want to receive.  You will get a
listing that shows how the data in that stream gets to that server.

>Is there any preferences among these servers?

Since we operate atm.nsf.geo.gov, I can personally vouch for its
reliability.  In the future, Penn State University will be coming
online as a toplevel relay for the east coast.  At that time we may
be asking you to switch to it, but for the time being you can feed
from atm.

>Generally I have no problem with uiuc for primary feed, but I will
>monitor more closely if there are recurrent problems.

I am not suggesting dropping your feed request(s) to UIUC.  I
am suggesting switching your redundancy away from Lyndon over
to a machine that is not fed by NOAAPORT ingest system that
is incorrectly identifying IDD products.

>Many thanks,

No worries.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.