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

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