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

[no subject]

>From: Alex de Almeida Fernandes <address@hidden>
>Organization: INPE/CPTEC
>Keywords: 200602131310.k1DDArO7002344 IDD IDD-Brazil

Hi Alex,

>We are ingesting several cptec models in mopora.cptec.inpe.br.
>We would like to do some transfer tests to some machine in US.
>Can you make some requests for these models?

OK.  I have just configured yakov.unidata.ucar.edu to request
all products in the SPARE data feed from mopora.cptec.inpe.br:

entries from yakov's ~ldm/logs/ldmd.log file:

Feb 13 19:51:51 yakov rpc.ldmd[5558] NOTE: Starting Up (version:; built:
 Jan 23 2006 15:25:47)
Feb 13 19:51:51 yakov rpc.ldmd[5558] NOTE: Using local address
Feb 13 19:51:51 yakov mopora[5561] NOTE: Starting Up( mopora.cptec.inpe
.br:388 20060213185151.582 TS_ENDT {{SPARE,  ".*"}}
Feb 13 19:51:51 yakov mopora[5561] NOTE: LDM-6 desired product-class: 2006021318
5151.582 TS_ENDT {{SPARE,  ".*"}}
Feb 13 19:51:51 yakov rtstats[5560] NOTE: Starting Up (5558)
Feb 13 19:51:52 yakov mopora[5561] NOTE: Upstream LDM-6 on mopora.cptec.inpe.br
is willing to be a primary feeder

>These are the script and log lines for cptec`s global ensemble (same
>that will be provided for TIGGE).
>script: pqinsert -v -f SPARE -l /home2/ldm/logs/oens.log
>log:     pqinsert INFO: 13069178 20060213102605.804   SPARE 000
>cptec`s operational  global T213L42.
>script: pqinsert -v -f SPARE -l /home2/ldm/logs/t213.log
>log:     pqinsert INFO:  6260516 20060208112250.661   SPARE 000


>There are some more models that we will ingest soon: global T126 and
>global gpsas data assimilation.

If they are put in the SPARE feedtype, my request will get them.

>We are worried about our bandwith to distribute our products to idd and
>tigge, so we would like to do some tests with these big products.

Based on the data transfer tests that I ran with NCAR and ECMWF, I
am also worried about the bandwith to/from CPTEC.  I am suspicious
that there may be some sort of artificial limiting of the data flow.
My suspicion is based on the difference in the ability of moingobe
to ingest low volume data feeds like IDS|DDPLUS and high volume
datafeeds like CONDUIT.

moingobe IDS|DDPLUS latencies:

moingobe CONDUIT latencies:

If the cause of high CONDUIT latencies was limited bandwidth, then
we should see a similar rise in latencies in IDS|DDPLUS during the
peak of CONDUIT transfers, but we do NOT  see this pattern.  Instead,
the latencies seen remain very low for low volume feeds and increase
as a function of the volume of the feed.  Our experience is that
this kind of pattern is caused by artificial volume limiting which
we generically refer to as "packet shaping".

So, if there really is packet shaping being done in the flows to
CPTEC, who is doing it?  We need to find out who is doing the volume
flow limiting and work with them to get it removed.  The first step
in this process is someone at CPTEC (Waldenio?) working with the
CPTEC IT group to make sure that they are not the cause.  If they
are not, perhaps they can help to find out who is doing the volume


No worries.

>Alex Almeida
>            Alex de A. Fernandes
> Bacharel Computacao Cientifica  - CPTEC/INPE
> address@hidden - Tel. (012) 3186 8477


* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*