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