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

[Support #TOL-308327]: statistics



Hello, 

Please see comments in text..


> Hi !,
> 
> Althoug I am receiving conduit's data, the problem now is
> related to the file size, since more them 50% of them are
> received with problem. Actually I am taking the file size
> directly form NCEP to check the integrit of the conduit's
> data.
> Is there any suggestion to improve my reception ?? Just
> for informatiom : before changing to idd.cise-nsf.gov I
> did not have similar problem

I see that you are also requesting from our machine:

idd.unidata.ucar.edu

I also see that it appears as if your clock on atm77 is off by about 3000 
seconds:

http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?CONDUIT+atm77.fis.ua.pt

Correct time on your LDM machine is critical for timely data reception.

It also appears as if there maybe some volume or packet shaping going on...this 
is often represented by the "sawtooth" pattern we are seeing on your stats.

Until the clock problem is resolved other diagnostics are "guesses"...


Please install NTP or some other time controlling software on atm77 so the 
clock does not drift, this will eliminate one variable and we can pursue others 
if correcting the clock does not clear things up.



> 
> Another problem is related to my log since there are 2
> itens which I do not undestand :
> 1.
> atm77 ldmping[1727]: SVC_UNAVAIL   0.000680    0
> localhost    RPC: Program not registered
> ...

This error messagen indicates thaty the LDM server you are trying to connect to 
is currently down.

> 2.
> 21 04:56:01 atm77 idd[1969]: ERROR: requester6.c:206:
> Connection to upstream LDM closed
> 
> 21 08:47:39 atm77 idd[1969]: ERROR: requester6.c:206:
> Connection to upstream LDM closed
> 
> 
The connection was closed by upstream, probably due to no data in range of 
request, this also could be part of the clock problem.


> It seems to me that the second one is because I am
> requesting data and it is not available yet (isnt' it ?)
> 

again, it is probably the clock on atm77 :)


Cheers,


Jeff Weber

> 
> Thank you for any help
> best regards,
> 
> yyamazaki
> 
> 
> 
> Em Tue, 09 May 2006 17:40:29 -0600
> "Unidata IDD Support"
> <address@hidden> escreveu:
> > Hi,
> >
> > re:
> >> After changing the ldm.conf (only chage made) [on my
> >> system - atm77.fis.ua.pt] to your new computer system:
> >>
> >> Request CONDUIT "MT.gfs_CY.00*|MT.gfs_CY.12*"
> >> idd.cise-nsf.gov  PRIMARY
> >> I am receiving data with no problem at all.
> >
> > Very good.
> >
> >> However my site does not seems to be conected and Ithere
> >> is no any statistical data anymore on
> >>
> >> http://www.unidata.ucar.edu/software/idd/rtstats/
> >>
> >> I also tested the system installed on pp42.fis.ua.pt
> >> (which I use for backup and SYNOP data reception) but
> >>also
> >> does not seem to be any connection, although data is
> >> received with no problem.
> >>
> >> So that I would appreciated if you provide me some
> >> information regarding my problem.
> >
> > We are not receiving any stats messages from either of
> >your machines.
> > The reason for this might be a DNS problem at your site
> >(so that
> > rtstats.unidata.ucar.edu is not resolved into an IP
> >address), or
> > some change in your firewall.  To test what may be
> >happening, please
> > do the following:
> >
> > <as 'ldm'>
> > ldmadmin ping rtstats.unidata.ucar.edu
> >
> > -- also --
> >
> > notifyme -vxl- -f ANY -h rtstats.unidata.ucar.edu
> >
> > Please report the results back to us.
> >
> > Additionally, you could increase the log level output
> >from your rstats
> > process:
> >
> > ps -eaf | grep rtstats           <- get the PID of the
> >running rtstats process
> > kill -USR2 <pid>                 <- sending the USR2
> >kill signal increases the
> >                                    log level by 1 which
> >is verbose
> > kill -USR2 <pid>                 <- put rtstats logging
> >into debug mode (very verbose)
> > kill -USR2 <pid>                 <- the third kill will
> >return rtstats to its normal
> >                                    logging level
> >
> > After each increase of the logging level, look at the
> >log messages:
> >
> > less ~ldm/logs/ldmd.log
> >
> > REMEMBER TO RETURN rtstats LOGGING BACK TO THE DEFAULT.
> > IF YOU DO NOT, YOUR
> > ldmd.log FILE WILL GET VERY LARGE!
> >
> >> best regards,
> >>
> >> yyamazaki
> >>
> >>
> >>
> >
> > Cheers,
> >
> > Tom
> > ****************************************************************************
> > Unidata User Support
> >                                   UCAR Unidata Program
> > (303) 497-8642
> >                                                P.O. Box
> >3000
> > address@hidden
> >                                  Boulder, CO 80307
> > ----------------------------------------------------------------------------
> > Unidata HomePage
> >                      http://www.unidata.ucar.edu
> > ****************************************************************************
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: TOL-308327
> > Department: Support IDD
> > Priority: Normal
> > Status: Closed
> >
> 
> 

Jeff Weber
Unidata User Support
http://www.unidata.ucar.edu

Ticket Details
===================
Ticket ID: TOL-308327
Department: Support IDD
Priority: Urgent
Status: Open