It's difficult to quantify wrt to how ATM plays a role in end-to-end
performance on the Internet. There is very little research to support how
ATM affects the overall performance. Even Ameritech and PacBell restricted
the majority of their performance evaluation on performance in the switch,
and only extended their scope if they leased an ADSU to a customer. Even
with the improved buffering, if you fill your pipe into the ATM switch,
your ATM switch still becomes a packet shredder, compared to the more
graceful packet drops seen on a clear channel line.
It depends on what you mean when you say 'performance'. I think
there is more and more interest being vested in ATM inefficiency,
and alternate technologies to better efficiency in the long-haul.
Recall Jerry Scharf's numbers; they're indicative of the issue.
[snip]
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
Sender: owner-nanog@merit.edu
In an attempt to reduce the signal to noise ratio of NANOG, I felt like
ATM should get equal time with registry policy for unending discussion of
week award. In Bob Melcalfe's concept that all we care about is working
code, I have included a PERL program for your benefit.
The programs reads a histogram file like the ones kc generates from
mae-west (http://www.nlanr.net/NA/Learn/packetsizes.html) and computes
the overhead for various framing methods. Hopefully taking
empirical data from the internet and giving people code will reduce
the discussions of what the "cell tax" for real traffic is. Don't
like my traffic, collect your own. Fighting over conclusions will
be left to others.
Jerry
Here's the output from the 15 minute collection run on Feb 10th, '96:
% packettax.pl < packetsizes.data
total packets seen = 11708789, total payload bytes seen = 3010380871
HDLC framing bytes = 3080633605 HDLC efficiency = 97.72
ATM framing bytes = 3644304857 ATM efficiency = 82.61
ATM w/snap framing bytes = 3862101043 ATM w/snap efficiency = 77.95
[snip]
- paul