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

Re: Netcheck.log file

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Netcheck.log file
  • Date: Tue, 13 Nov 2001 17:32:11 -0700
> 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/
****************************************************