[Support #TOL-308327]: statistics

> Dear Tom/Jeff,
> 
> I really could not solve the problem yet. The atm77 time
> was set in using our GPS system time and the statistics
> was shown with what you have mentioned (lag of about 3000
> seconds).  Now I made a set to a local time (1 hour
> difference during summer )and the statistics does not show
> the negative value anymore. But the problem is still the
> same.

Yes, we see that INPE and CPTEC are also having the same problem:

Please see:

http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?CONDUIT+moingobe.cptec.inpe.br


For test purposes could you please request IDS|DDPLUS (as well as CONDUIT) from:

idd.cise-nsf.gov


This will allow us to see if lower volume products are able to get through to 
you without latency.


We have some information about the router at idd.cise-nsf.gov, and it may be 
part of the problem (we are investigating).

Let us know when you have begun to request the IDS|DDPLUS feed, you can pipe it 
to dev/null or whatever you desire.

We suspect the problem to be bandwidth related, either throttling somewhere on 
the network, or it could be limited capacity of the router at idd.cise-nsf.gov.


Apologies for any inconvenience,

Jeff




> 
> I have been looking at the problem with help of computer's
> department guys and it seems that the problem is not
> related to the university network system. So that I wonder
> if there is some other possible check which can be made to
> solve the problem.
> 
> Just for forther information : Since I receive the e-mails
> from IDD brasil I noticed that someone from Sao Paulo
> University sent one e-mail facing similar problem (conduit
> flux data --> incomplete).
> 
> Best regards,
> 
> yyamazaki
> 
> 
> Em Fri, 26 May 2006 10:30:36 -0600
> "Unidata IDD Support"
> <address@hidden> escreveu:
> > 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
> >
> 
> 

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

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