Subject: latency and load

From: John Dawson <[email-masked]>
Date: Tue, 24 Aug 1999 10:15:16 -0700

Although I do like Bob's suggestion of grabbing many measurements from a
single test pass, I am very much against any latency process that runs at
100% load for more than a couple milliseconds.  Clock tolerance build-up is
going to play with the test results in an uncontrolled fashion.  Any
background traffic such as spanning tree hello's or topology discovery
packets will further send the load beyond 100% which will skew results even
more.  I am also not in favor of a test process that requires default
topology processes to be disabled.

Although the 'trombone' test process has been used by many it doesn't fit
into many switch architectures.  If run at Layer2 then VLANS are needed to
force the packets through the desired paths.  However, not all switches can
handle the same source MAC address appearing at multiple ingress ports even
though the MAC address may be on a different VLAN - duplicated MAC
addresses can really mess up the address learning on many switches.  If run
at Layer3 then a router needs to tricked into using the loopback pipes
rather than going right to the final end destination which is another port
also on the same router.  I don't see how this type of test would be
applicable in an Ethernet space -- Sorry, but I believe there is no
substitute for having lots of test ports (something that I am sure Netcom
and Ixia will be glad to hear).

I would consider Bob's process valid if the load is dropped below 100% and
if the load is structured strictly as pairs of stations talking to one
another (no mesh tests for latency).  However, I might read other factors
into the results:

> a maximum latency value which would give an appreciation of the total
> buffer depth available on the DUT.

I am sure that I am twisting Bob's meaning, but I believe this assumes that
the buffers actually do saturate.  If the buffers don't saturate, then the
maximum latency is more likely just a random number for any given port --
it is going to vary all over the place in a multi-port test scenario.

I think that Jim's discussion of multiple latency regions should be
considered further.

John
=================================================================
>Per the ongoing discussion on latency, a possible approach is as
>follows:
>- run a single latency test at 100% load for selected packet sizes
>- use send and receive timestamps and sequence numbers on all packets
>- report the minimum, average and maximum latencies on a thirty second
>test
>run.
>
>The advantages of this approach are:
>- a single test run to provide a complete set of latency results
>- a minimum value for latency of the first few packets going through the
>DUT
>before buffers fill up. This time would correspond to
>the low load latency that Jim rightly wants to see.
>- a maximum latency value which would give an appreciation of the total
>buffer depth
>available on the DUT.
>The average latency would give some indication of how quickly the buffer
>fills
>up. Jitter or latency variation could also be calculated as standard
>deviation of the
>delta values of per packet in and out timestamps.
>Bob
>
>

---

From: "Robert Mandeville" <[email-masked]>
Date: Tue, 24 Aug 1999 14:25:25 +0200

see comments in-line below

[email-masked]
usa +1-949-400-44-44
europe +33 (0)6 07 47 67 10

----- Original Message -----
From: John Dawson <[email-masked]>
To: bmwg <[email-masked]>
Sent: Tuesday, August 24, 1999 7:15 PM
Subject: latency and load

> topology processes to be disabled.

I always turn such software off when running latency tests. What load level
avoids the clocking issue you raise?

> if the load is structured strictly as pairs of stations

I agree that one to one pairs is a necessary condition for latency tests.
Latency tests on meshed traffic produce uninteresting results.

talking to one
> it is going to vary all over the place in a multi-port test scenario.

You are right that a DUT's buffers may not fill up at a 100% after thirty
seconds. So my comment does not apply in such cases nor in any cases where
the DUT is able to run at wire rate without buffering. An easy check on
buffer depth can be performed by aiming inbound traffic at a load greater
than 50% from each of two ports to a single output port and measuring
maximum latency. I always go through the motions of back-calculating the
buffer size from the packet length and latency information. I generally get
a credible value but rarely if ever an exact value for the buffer size.

> I think that Jim's discussion of multiple latency regions should be

I agree that Jim's approach is "richer" than mine but requires more work.