[ANSS-netops] rtp2rtpd question

[Philip Crotwell]

Thanks for the advice, we will give that and the firmware upgrade a try and
see if things improve.

Philip

On Wed, Dec 15, 2010 at 12:55 PM, Mark E Meremonte <meremonte at usgs.gov>wrote:

>
> Phillip,
>
> Your problem sounds like a problem with the RT-130's TCP/IP stack's
> inability to detect a down, then up, network connection.   I use to get this
> problem much in the early history of the RT-130s.  I got around it by
> enabling continuous IP device power to the IP stack rather then toggle/auto.
>   And, to this day, I still always enable continuous IP device power as a
> matter of course to prevent the possibility of it happening especially when
> there is a radio in the IP link instead of a "hard" landline connection.
>
> Mark
>
>
> ******************************************************************************
> Mark E. Meremonte             Geophysicist    USGS/ANSS/NEIC
>
> U.S. Geological Survey      Work: 303-273-8670   Cell: 303-478-5766
> MS 966, Box 25046               Email: meremonte at usgs.gov
> Denver, CO  80225                Web: http://geohazards.cr.usgs.gov
>
> Ship:  U.S. Geological Survey, 1711 Illinois St., Golden, CO 80401
>
> ******************************************************************************
>
>
>  From: Philip Crotwell <crotwell at seis.sc.edu> To: mwithers at memphis.edu Cc:
> anss-netops at geohazards.usgs.gov
> Date: 12/14/2010 16:34 Subject:
> Re: [ANSS-netops] rtp2rtpd question
> Sent by: anss-netops-bounces at geohazards.usgs.gov
> ------------------------------
>
>
>
> I have not had much experience with rtp2rtpd except between two
> computers on the same local subnet, so I haven't seen this exact
> problem. However, we have seen lots of cases where a link to a single
> station (cell modem) goes down and comes back up, but the rtp
> connection doesn't. Sometimes it comes back eventually (hours to days)
> and sometimes we have to go out and push the power button. We also end
> up with data gaps even in cases of very short outages that should not
> exceed the local buffer. Lots of weirdness I just don't understand.
>
> Any chance your issue was with the station to rtpd link instead of the
> rtp2rtpd link? Not that I have anything useful in that case other than
> sympathy but at least you aren't alone. :(
>
> Philip
>
> On Tue, Dec 14, 2010 at 11:23 AM,  <mwithers at memphis.edu> wrote:
> >
> > We have rtpd running at a remote node and rtp2rtpd on that node
> transfering
> > the data to a central site via private microwave.  Inclement weather
> > frequently disrupts comm over the microwave link.  During a recent
> > disruption, when comm was restored, rtp2rtpd was successfully transfering
> > data for some stations but not others. So I stopped and restarted
> rtp2rtpd
> > and data transmission was restored.  I don't see anything significant in
> > the logs to suggest what the problem was.  Has anyone running rtp2rtpd
> > seen this sort of thing before and if so, what did you do to correct it
> > so that you resume data transmission without manual intervention?
> >
> > Mitch
> >
> > Center for Earthquake Research and Information (CERI)
> > University of Memphis                Ph: 901-678-4940
> > Memphis, TN 38152                   Fax: 901-678-4734
> >
> > _______________________________________________
> > ANSS-netops mailing list
> > ANSS-netops at geohazards.usgs.gov
> > https://geohazards.usgs.gov/mailman/listinfo/anss-netops
> >
> _______________________________________________
> ANSS-netops mailing list
> ANSS-netops at geohazards.usgs.gov
> https://geohazards.usgs.gov/mailman/listinfo/anss-netops
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geohazards.usgs.gov/pipermail/anss-netops/attachments/20101215/4ed50ed1/attachment.html>