Tom et al,
Thanks for your assistance, we have fixed our network problem, which turned out
to be a "gummed up" router for lack of a better explanation. I basically ran
two tests to convince our network folks that "my" problem was "our" problem, 1)
I ran ping statistics to show that dropped packets did not happen until I got
to the router, and 2) I showed them ftp download times from machines before and
after the router, which indicated download speeds of ~1000 Kbytes/sec as
opposed to the terrible ~35 Kbytes/sec I was getting after the router (this is
why I was asking people to ftp to motherlode, so I would have some bench
marks). Anyhow, were back in business, thanks again,
-Mike
At 02:34 PM 8/25/2003 -0600, Tom Yoksas wrote:
>>From: Mike Voss <voss@xxxxxxxxxxxx>
>>Organization: SJSU
>>Keywords: 200308251458.h7PEwJLd022746 IDD packet shaping
>
>Mike and IDD Users:
>
>IDD data reception at SJSU recently and abruptly transitioned from
>excellent to unacceptable. The time series traces of IDS|DDPLUS
>and HDS latencies on the SJSU IDD node, rossby.met.sjsu.edu, can
>be seen in the following links:
>
>IDS|DDPLUS:
>http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?IDS|DDPLUS+rossby.met.sjsu.edu
>
>HDS:
>http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?HDS+rossby.met.sjsu.edu
>
>For reference, Mike split his original WMO feed request into separate
>IDS|DDPLUS and HDS requests sometime between 16Z and 17Z this morning.
>The traces listed in the links above show that virtually all of the
>latency that Mike is seeing is being cause by HDS product ingestion.
>His IDS|DDPLUS latencies has fallen to near zero, while those for HDS
>continued to be very high, climbing to over 8000 seconds even after the
>split.
>
>We believe that the latency time series listed above depict a "classic"
>volume limitation on data flow. We (Unidata Support) have seen this
>kind of volume-limiting at several universities that implemented "packet
>shaping" to control data volumes.
>
>If the cause for Mike's poor HDS data ingestion turns out to be the same
>as for others, the only thing that can be done is to contact the campus
>networking folks to see if they are willing to allow port 388 traffic
>to flow unimpeded.
>
>>I'm trying to convince my campus network folks that we have a serious network
>>bandwidth/congestion problem. This problem does not seem to be related to
>>total campus traffic. I have supplied them with several pieces of evidence,
>>but I'm looking for more and that's where you can help.
>>
>>I occasionally download data from motherlode.ucar.edu as a backup to lost IDD
>>data. Currently, when I download I'm getting speeds of around 35 Kbps, which
>>is just horrible. However when I retrieve the file on my local network I get
>>7500 Kbps. The difference is poor network performance going through all the
>>switches and firewalls between my network and UCAR. Could some of you (who
>>have access) download some data from motherlode via ftp or http and tell me
>>what kind of transfer speeds you get? This would be interesting info in is
>>own right, but might also provide me with some more ammunition for my case
>>with my network folks.
>>
>>Thanks for your help,
>>-Mike
>>--------------------------
>>Mike Voss
>>Department of Meteorology
>>San Jose State University
>>One Washington Square
>>San Jose, CA 95192-0104
>>
>>408.924.5204 voice
>>408.924.5191 fax
>
>Tom
>--
>+-----------------------------------------------------------------------------+
>* Tom Yoksas UCAR Unidata Program *
>* (303) 497-8642 (last resort) P.O. Box 3000 *
>* yoksas@xxxxxxxxxxxxxxxx Boulder, CO 80307 *
>* Unidata WWW Service http://www.unidata.ucar.edu/*
>+-----------------------------------------------------------------------------+
--------------------------
Mike Voss
Department of Meteorology
San Jose State University
One Washington Square
San Jose, CA 95192-0104
408.924.5204 voice
408.924.5191 fax
