[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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