[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 11:22:32 -0700 (MST)
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/
> ****************************************************
>