OPNET ITGURU ACE™ Uncovered: How ACE Analysis Really Works

Monday, August 27
09:00 - 12:00
1412 ACE™ Uncovered: How ACE Analysis Really Works - Atrium Ballroom B (Reagan)
---
8:36 AM 8/27/2007
just had a great continenal breakfast, the coffee was superb.
I am sitting now in the atrium ballroom waiting for session 1412 to begin.

I have been working for more than a year on ACE analysis, and this will be my

second OPNETWORK conference

There was a reception last night in the Willard Hotel, wonderful ambience, and

the light finger foods, and spinach stuffed ravioli was really really good.
9:04 AM 8/27/2007
technical assistants introduction.

think of it as the science behind ace.

not point and click, how to, this is the theory of how the numbers are

calculated.

explaining to app dev that he broke a underforming app. you must be able to

support your conclusions.

not blind acceptance of the math, but understanding what the math behind the

answers is.

pdf copy of the slides on the desktop.

going over two main analysis components.

the summary of delays.
where it has spent it's time

quick predict
where it will spend it's time

talk about the various source of delays...
finish with how simulation works.

components of delay:
where should i spend my energy on troubleshooting?
summary delay chart pinpoints the areas that need analysis.

review of network delays
network hops...
complexity can be simplified... analogy of resistors and circuits.
there is an equivalent network between the client and server. it's not crucial to

model the actual, reducing complexity to simplify analysis.

bandwidth is the easiest to understand. we all agree, basically bandwidth delay

is the time it takes to clock a certain number bits per second on to the wire.
varies with the size of the packet!

the longer the packet, the longer it takes to clock on to the circuit.

from start of the packet to the end... 2000 bit packet, on a 2000 bit/second

circuit equals 1 second from start to end of packet to hit the wire.

latency delay:
length of time that it takes the rising edge of the bit to transit the circuit.
thousand mile cable, with an electric cable, propgation delay, longer to reach

california, than bethesda.

opnet defines latency ONE WAY... ping would return round-trip latency...!!!!
remember to divide in half if using ping

the bottleneck link controls how much the bandwidth plays in the equation...
usually the slowest links are entry and exit of the circuit... t1 is three times

slower than a t3 because of throttling delay.

throwing more bandwidth at a problem, only solves one of the components of the

problem.

roads, bandwidth = how many lanes the road has...
latency is the distance of that road, one lane road to new york, four hours, four

lane road still takes four hours, but if i want to send a fleet of trucks, the

four lane road allows me to send more data.

***warehouse analogy... could be created here***

application turns
application will experience the latency of the circuit, for each application

turn.
latency delay = circuit latency * (turns +1)

CONGESTION DELAY
is queing delay on devices, not the wire, you can not store data on the wire.
this is variable based on congestion.

you have to calulate the congestion delay for every single packet.

calculating network delays
clocking data on to the wire, and latency delay. BUT then we see additional delay

due to congestion delays.

clocking the data off the wire will take the same amount of time... but it does

not matter as much...

40% of mistakes because they did not specify bandwidth on import. you MUST answer

to the extent that you can.
you can not change them once they are imported... import configuration, toggle it

to previous, and then tweak the numbers when you select bandwidth and latency.

packet trains
bundles of packets, an application may send a block of data, 10 k forinstance,

and tcp chops it up into chunks

calulating delay for packet trains
so we will treat packet trains like 1 big packet
we see how bundles act like small packets, but can experience the same congestion

delays.

turns + 1 = application turns
you always experience latency once

pie chart
is telling you the benefit you will get for fixing this thing... bandwidth,

latency, congestion.

calculating delays, advanced
take the mental image if you started increasing bandwidth, to infinity , the

whole thing would compress , squeezing out bandwidth, what do you have left...

lab excercise.
response time = 26.03
bandwidth delay = (3.199,760*8)/1544000 = 16.58
percentage of bandwidth = 16.58/26.03 = 63.7

user think time is a new feature of it guru 14.
you can specify anything greater than X time factor is user think time... telling

the user to wait five seconds between screen refreshes.

you must perform the sanity check to defend your results in ACE

key concept.
every packet has a time value when you look at it in wireshark
ace knows TWO time values for each packet, when it was received and when it left.

Trace merge:

based on lining up clocks this is trivial, packet left, packet received.

single side adjust
if you specify the latency too high, you would get packet crosses.

sending a packet train... 10 packets... the ack's come back...........big gap in

the ack's
either the packet was delayed, or that ack was delayed.

acknowledgements may delayed...
there are rules that govern how ack's get delayed.

key concept: if we graph the delays... packet size, packet delay... small packets

have small delays... large packets have large delays.
*
/congestion
/____
/bandwidth ^
/______
/latency ^
/ -------
never zero latency

tcp guarantees that a packet will cross the network, it also protects the

network.
prevents single users from hogging the network

what does protocol delay look like
it is delay added by the network layer, that is overhead on the packet train.

tcp protocol delay causesd by:
tcp windowing
slow start
notice the inflight data graph is ramping up...
http 1.0 would be susceptible to this issue

frozen window

nagle's window
sending one packet at a time is inefficient
bundling to prevent inefficiency in the network
can be a problem in mainframe communications

retranmission
tcp covers how long it takes to recover from packet loss

out of sequence packets

lab 2

summary of labs, conclusion
was a congestion problem
the trace file showed the effect of protocol congestion which was slowing down

the packets

how to explain parrallel effects
reading the paper while eating breakfast
another example, dessert in the oven, making steaks... things that happen at the

same time

two types of applications:

transactional
e.g. database queries
sequential
or
parallel
multiple calls with dependencies

asynchronous
voice calls...

so parallel effects are something you have to do TWO things to make them go away.

analysis vs experimentation

simulation, is recreating variables and tuning them for determining different

effects

use QuickPredict for experiments

barchart
sweep
multi-user quick predict