Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Overloading of MAX ethernet ports?
On Sun, Jul 12, 1998 at 10:20:51AM -0500, Marcel Brown wrote:
> I had a nearly identical problem with a Pipeline 130 and posted a question
> about it here. The recommendations were to turn off STAC and/or VJ
> compression. I turned off STAC, and the problem seems to have gone away. I
> haven't seen what turning of VJ will do. Kind of irks me that Ascend would
> sell a product that can't *really* do what it says it will do.
This may, actually, be unrelated problems. It appears clear that Stac LZS
and VJ Header Compression both make things worse on a line that has a
bandwidth > 1 Mbps. The processor in the Pipes is a poor little 68380 or
such embedded 68k, which is severly loaded by routing already. You may
say "but isn't Stac done with a chip ?" - yeah, right, but someone has
to feed this chip with data and control its operations. It appears that
the increased latency of either VJ or Stac on a Pipe destroys any gain
you may have from the compressions or worse. If > 1Mbps, switch them off.
VJ+Stac is great for ISDN bandwidth (64 or 128 kbps), were it can reach
up to 1Mbps virtual throughput (been there, measured that).
BTW, the original problem is a known old one. Maxen (1800 as well as 2k
or 4k) seem to go weird as soon as significant broadcast traffic is
seen on the ethernet. During a smurf attack you can see your Maxen crawl.
> That brings up a topic I never seem to have gotten a straight answer about.
> Is VJ compression any good at higher bandwidths? What are people's feelings
> about VJ compression? What if the same questions are asked about STAC?
That depends on what "higher bandwidth" means. Usually it means an uplink
that serves IP connectivity of a lot of end systems, probably going into
the >100 or even >1000 range. In these cases, neither standard VJ nor
Ascends LZS implementation are of any value. Standard VJ can deal with
at most 16 independent TCP states. LZS _could_ be used in a very smart
way (multiple history compression) and _could_ perform well even with
> 100 content-independent flows. All that this requires is smart imple-
mentation of multi history LZS on the peers. Ascend LZS does _not_ support
LZS multiple histories - so LZS is just beaten to death by trying to
squeeze white noise. Again, if you have _physical_ bandwidth >1Mbps,
forget about VJ or Stac. They would make sense only in very special
situations (f.i. wehn the link just shuffles gigabytes of PostScript prints
on one TCP connection from prepress to the printing house).
--
Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) AB10-RIPE Xlink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: