Re: MAE West congested again?

[feldman () MFSDatanet COM (Steve Feldman)]

One of the two OC3c circuits between MFS and Ames was down for a while today,
resulting in the congestion you were seeing.  It is better now.

The 70 meg limit appears to be a measurement artifact, rather than a real
throughput limit, though we're still trying to confirm that.  We believe that
the OC3c interface should be capable of nearly the full 100 Mbps limit
of the Gigaswitch's crossbar, in each direction.

I'll fix the map so it reports correctly starting tomorrow.
        Steve

> From owner-nanog () merit edu  Thu Sep 19 14:50:38 1996
> From: booloo () cats ucsc edu (Mark Boolootian)
> Subject: MAE West congested again?
> To: nanog () merit edu
> Date: Thu, 19 Sep 1996 14:38:45 -0700 (PDT)
> X-Mailer: ELM [version 2.4 PL23]
> Content-Type: text
> Sender: owner-nanog () merit edu
>
>
> It looks to me as if MAE West may be congesting again.  While things look
> fine at the moment, earlier I was seeing congestion when transitting between
> CERFNET (134.24.9.115) and ESNET (198.32.136.41).
>
> My understanding of the topology of MAE West is that there is a Gigaswitch
> at Ames and a Gigaswitch at MFS (in San Jose) connected by a pair of
> OC-3 ATM circuits.  My belief is that CERFNET and ESNET have ports on
> different Gigaswitches.  MFS has changed the web page which lists MAE West
> connections such that I am unable to easily tell who is on which switch.
>
> In looking back at stats for the OC-3 link prior to the addition of the
> second circuit, I note the circuit maxes out around 70 Mbits/sec.  In
> discussing this around here, we concluded that data is probably clocked
> out the Gigaswitch at 100 Mbits/sec and ATM overhead accounts for the
> remaining loss of available bandwidth.  Can anyone confirm this for me?
>
> The graph for the OC-3 pair from yesterday indicates that it's time to 
> add more bandwidth between switches.  I'm real interested in knowing what 
> plans MFS has up its sleeves for alleviating congestion this time around.
> Provisioning an OC-3 and only burning half the available bandwidth doesn't
> strike me as a scalable solution.
>
> mb
- - - - - - - - - - - - - - - - -