[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Netcheck.log file
- Subject: Re: Netcheck.log file
- Date: Thu, 29 Nov 2001 13:49:55 -0700 (MST)
Hey Patrick,
Although there are a few more hops, it appears to be much quicker.
However, this is just a snapshot.
I believe Anne sent you a script or informed you to netcheck that can be
run via a cron process...I would like to see if the connect to stokes
remains good before we go ahead and make the change.
How do you feel on this?
I suppose since you have not seen much latency in your NNEXRAD feed, it
probably remains as a good connect, but we may wish to be prudent and run
netcheck for a 24 hour slot.
But if you are anxious to switch I can contact Mark at OU and we can maybe
get the change made today. Just would hate to change back..or again to
some other site...this way we would just put papagayo as your failover and
use stokes as your primary.
Thoughts...
-Jeff
____________________________ _____________________
Jeff Weber address@hidden
Unidata Support PH:303-497-8676
NWS-COMET Case Study Library FX:303-497-8690
University Corp for Atmospheric Research 3300 Mitchell Ln
http://www.unidata.ucar.edu/staff/jweber Boulder,Co 80307-3000
________________________________________ ______________________
On Thu, 29 Nov 2001, Patrick O'Reilly wrote:
> Jeff,
>
> Here's Take Two. Blizzard > Stokes. And, may I add, its pretty good
> reading.
>
> Patrick
>
> ----- Original Message -----
> From: "Jeff Weber" <address@hidden>
> To: "Patrick O'Reilly" <address@hidden>
> Cc: <address@hidden>
> Sent: Thursday, November 29, 2001 1:40 PM
> Subject: Re: Netcheck.log file
>
>
> > Patrick,
> >
> > OK, lets see the route your NNEXRAD data is taking.
> >
> > If it also is out of the CHE/CHI loop, it may be best to feed all from
> > stokes....
> >
> > Would you be so kind as to traceroute stokes.metr.ou.edu
> >
> > and we may just want to get all feedtypes from stokes, it is also a top
> > tier site with a robust machine.
> >
> > Thank you,
> >
> > -Jeff
> > ____________________________ _____________________
> > Jeff Weber address@hidden
> > Unidata Support PH:303-497-8676
> > NWS-COMET Case Study Library FX:303-497-8690
> > University Corp for Atmospheric Research 3300 Mitchell Ln
> > http://www.unidata.ucar.edu/staff/jweber Boulder,Co 80307-3000
> > ________________________________________ ______________________
> >
> > On Thu, 29 Nov 2001, Patrick O'Reilly wrote:
> >
> > > Jeff,
> > >
> > > I am feeding from papagayo for UNIDATA and NMC3, and stokes for NNEXRAD.
> Let
> > > me know if you need any other info.
> > >
> > > Patrick
> > >
> > > ----- Original Message -----
> > > From: "Jeff Weber" <address@hidden>
> > > To: "Patrick O'Reilly" <address@hidden>
> > > Sent: Thursday, November 29, 2001 1:31 PM
> > > Subject: Re: Netcheck.log file
> > >
> > >
> > > > Patrick,
> > > >
> > > > My records are incomplete...
> > > >
> > > > Who are you feeding NNEXRAD from?....stokes?...thelma?
> > > >
> > > > This will help me diagnose where we may get good connects.
> > > >
> > > > It looks as if when we go to Missouri we avoid that Cheyenne/Chicago
> loop.
> > > >
> > > > Still investigating...
> > > >
> > > > -Jeff
> > > > ____________________________ _____________________
> > > > Jeff Weber address@hidden
> > > > Unidata Support PH:303-497-8676
> > > > NWS-COMET Case Study Library FX:303-497-8690
> > > > University Corp for Atmospheric Research 3300 Mitchell Ln
> > > > http://www.unidata.ucar.edu/staff/jweber Boulder,Co 80307-3000
> > > > ________________________________________ ______________________
> > > >
> > > > On Thu, 29 Nov 2001, Patrick O'Reilly wrote:
> > > >
> > > > > Jeff -
> > > > >
> > > > > Your wish is my command. Attached is what you requested. Hopefully
> > > it's
> > > > > just a Papagayo > Blizzard thing, and maybe a new feed will fix me
> up.
> > > The
> > > > > NNEXRAD feed we get comes in right on time, so that's what I'm
> hoping.
> > > > > Thanks!
> > > > >
> > > > > Patrick
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Jeff Weber" <address@hidden>
> > > > > To: "Patrick O'Reilly" <address@hidden>
> > > > > Cc: <address@hidden>
> > > > > Sent: Thursday, November 29, 2001 12:22 PM
> > > > > Subject: Re: Netcheck.log file
> > > > >
> > > > >
> > > > > > Hi Patrick,
> > > > > >
> > > > > > Ball is back in my court.
> > > > > >
> > > > > > Until we can get away from Sprint:
> > > > > >
> > > > > > http://www.sprintesolutions.com/resources/maps/bb_map2_popup.html
> > > > > >
> > > > > > I think we may want to find someone close to the KC hub,
> eliminating
> > > > > > Cheyenne and, the ever problematic, Chicago.
> > > > > >
> > > > > >
> > > > > > Just out of curiousity, would you please perform:
> > > > > >
> > > > > > traceroute bergeron.snr.missouri.edu
> > > > > >
> > > > > > and attach the results back to me.
> > > > > >
> > > > > > I am seeing if we can avoid the che/chi loop from sprint.
> > > > > >
> > > > > > Thank you,
> > > > > >
> > > > > > -Jeff
> > > > > > ____________________________
> _____________________
> > > > > > Jeff Weber address@hidden
> > > > > > Unidata Support PH:303-497-8676
> > > > > > NWS-COMET Case Study Library FX:303-497-8690
> > > > > > University Corp for Atmospheric Research 3300 Mitchell Ln
> > > > > > http://www.unidata.ucar.edu/staff/jweber Boulder,Co
> 80307-3000
> > > > > > ________________________________________
> ______________________
> > > > > >
> > > > > > On Thu, 29 Nov 2001, Anne Wilson wrote:
> > > > > >
> > > > > > > Hi Patrick,
> > > > > > >
> > > > > > > We're doing some shuffling around here, and I will passing your
> > > latency
> > > > > > > problem over to Jeff to handle. Were you able to increase the
> > > default
> > > > > > > accepable latency value? I realize that that does not help you
> with
> > > > > > > your script problem, but I was just wondering if you had tried
> that.
> > > > > > >
> > > > > > > Jeff, I'll send you Patrick's netcheck results in a separate
> > > message.
> > > > > > >
> > > > > > > Anne
> > > > > > >
> > > > > > >
> > > > > > > Patrick O'Reilly wrote:
> > > > > > > >
> > > > > > > > Hi Anne,
> > > > > > > >
> > > > > > > > I was just checking back with you about our latency issue.
> Once
> > > in a
> > > > > while
> > > > > > > > it runs okay all day, but usually during the daytime hours we
> run
> > > from
> > > > > 30-60
> > > > > > > > minutes late while papagayo is right on time. I am starting
> to
> > > try to
> > > > > > > > implement some scripts that run automatically and create
> gempak
> > > > > images, and
> > > > > > > > with the latency, it's difficult to get them to run properly.
> > > > > Basically,
> > > > > > > > time is a variable in the script to input into the gempak
> > > programs,
> > > > > and the
> > > > > > > > current computer time is used by the script. But if we don't
> have
> > > > > data for
> > > > > > > > the current hour or the previous one, the scripts won't create
> any
> > > > > graphics,
> > > > > > > > as no data is there. I am eventually going to create these
> images
> > > > > hourly
> > > > > > > > and ftp them to a web server. If you can find any time to
> > > investigate
> > > > > with
> > > > > > > > Jeff about connection options, that would be great. Thanks
> again
> > > for
> > > > > your
> > > > > > > > help.
> > > > > > > >
> > > > > > > > Patrick
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Anne Wilson" <address@hidden>
> > > > > > > > To: "Patrick O'Reilly" <address@hidden>
> > > > > > > > Cc: <address@hidden>; <address@hidden>
> > > > > > > > Sent: Tuesday, November 13, 2001 6:32 PM
> > > > > > > > Subject: Re: Netcheck.log file
> > > > > > > >
> > > > > > > > > > Patrick O'Reilly wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Anne -
> > > > > > > > > >
> > > > > > > > > > Well I ran netcheck hourly for a couple days and have
> attached
> > > the
> > > > > log
> > > > > > > > > > file as a text file. Seems that from 16-22Z each day,
> lots of
> > > > > packet
> > > > > > > > > > loss, sometimes 40%, and long times showing on traceroute.
> > > Less
> > > > > busy
> > > > > > > > > > times (i.e. overnight) seem much better from what I see.
> If
> > > you
> > > > > could
> > > > > > > > > > take a look at the file and tell me what you think we
> should
> > > do,
> > > > > > > > > > that'd be great. Since we have latencies just over an
> hour at
> > > > > times,
> > > > > > > > > > we are losing data.
> > > > > > > > > >
> > > > > > > > > > Thank you...
> > > > > > > > > >
> > > > > > > > > > Patrick
> > > > > > > > > >
> > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > > > > Patrick O'Reilly Support
> > > Scientist
> > > > > > > > > > The STORM Project address@hidden
> > > > > > > > > > 208 Latham Hall ph:
> 319-273-3789
> > > > > > > > > > University of Northern Iowa
> > > > > > > > > > Cedar Falls, IA 50614
> > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > > > >
> > > > > > > > > > Name: netcheck.log
> > > > > > > > > > Type: unspecified type
> > > > > > > > > > netcheck.log (application/octet-stream)
> > > > > > > > > > Encoding: quoted-printable
> > > > > > > > > > Download Status: Not downloaded with
> message
> > > > > > > > >
> > > > > > > > > Hi Patrick,
> > > > > > > > >
> > > > > > > > > Your connection to papagayo does look rather bad. I will
> talk
> > > to
> > > > > Jeff
> > > > > > > > > Weber about the situation. I'm not sure if finding you
> another
> > > feed
> > > > > is
> > > > > > > > > the thing to do, or maybe we need to talk with the UNL
> people.
> > > > > > > > > Traceroutes that show times in the thousands of milliseconds
> are
> > > > > pretty
> > > > > > > > > bad. Actually, times over 100 ms aren't that good. And the
> > > packet
> > > > > loss
> > > > > > > > > doesn't help, especially if you're getting large products as
> the
> > > LDM
> > > > > > > > > will resend the whole product if a packet is lost. That
> just
> > > adds
> > > > > to
> > > > > > > > > the conjestion.
> > > > > > > > >
> > > > > > > > > In the meantime, you can change your default time to reject
> > > products
> > > > > > > > > from an hour to something greater. In ldmadmin, in the
> > > subroutine
> > > > > > > > > start_ldm, find the line that looks like this:
> > > > > > > > >
> > > > > > > > > $cmd_line .= " -q $pq_path $ldmd_conf > $pid_file";
> > > > > > > > >
> > > > > > > > > and change it to something like this:
> > > > > > > > >
> > > > > > > > > $cmd_line .= " -o 5400 -m 5401 -q $pq_path $ldmd_conf >
> > > > > $pid_file";
> > > > > > > > >
> > > > > > > > > See the man page for more info about the -o and -o arguments
> to
> > > > > > > > > rpc.ldmd. The -o and -m options use units of seconds. This
> > > > > particular
> > > > > > > > > line will keep products younger than 90 minutes and reject
> the
> > > older
> > > > > > > > > products. You can adjust these arguments according to your
> > > needs.
> > > > > You
> > > > > > > > > can see how old products are that are being skipped by
> looking
> > > in
> > > > > the
> > > > > > > > > logs for the 'skipped' messages, and set the arguments in
> the
> > > > > command
> > > > > > > > > line according.
> > > > > > > > >
> > > > > > > > > Let me know if you have any questions about this. In the
> > > meantime,
> > > > > I'll
> > > > > > > > > explore the UNL connection issue and get back to you.
> > > > > > > > >
> > > > > > > > > Anne
> > > > > > > > > --
> > > > > > > > > ***************************************************
> > > > > > > > > Anne Wilson UCAR Unidata Program
> > > > > > > > > address@hidden P.O. Box 3000
> > > > > > > > > Boulder, CO 80307
> > > > > > > > > ----------------------------------------------------
> > > > > > > > > Unidata WWW server http://www.unidata.ucar.edu/
> > > > > > > > > ****************************************************
> > > > > > >
> > > > > > > --
> > > > > > > ***************************************************
> > > > > > > Anne Wilson UCAR Unidata Program
> > > > > > > address@hidden P.O. Box 3000
> > > > > > > Boulder, CO 80307
> > > > > > > ----------------------------------------------------
> > > > > > > Unidata WWW server http://www.unidata.ucar.edu/
> > > > > > > ****************************************************
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>