Subject: Re: numbers...

From: [email-masked] (Neal Nuckolls)
Date: Wed, 15 May 1996 09:40:53 -0700

> sun4m SS10 115mhz hypersparc, 256k cache
> measure_csum_partial
> csum_partial: sz[1024] 10000 iterations takes 17009430 microseconds
> csum_partial: sz[1024] 1 iteration takes <1700 microseconds>==<332 nanoseconds>

Maybe I'm dense this morning but I don't understand the numbers.

You measure the realtime to do a sequential IP checksum on a 1K
buffer and you always invalidate the processor cache (I$, D$, and
Secondary$ or just some subset of these?) and don't include the
cost of doing the cache invalidate in the time above.  10000 of
these costs a hair over 17s, divide by 10000 gives 1.7ms per
iteration. This seems way high so must include the cost of the
cache invalidate or something?

What does the 332ns refer to?

My back of the envelope:
If I recall, the cacheline on a sun4m is 32bytes.  Assuming
something in the 300-600ns/secondarycachemiss range and a single
pending cachemiss at a time would put most any "touch the data"
operation on 1K of data in the 9.6-19.2us ballpark or 9-18ns/byte
range.

Does the hypersparc processor support multiple concurrent cache
misses? Or does it have a Viking-like sequential reference
detector and automatic cache prefetch logic?

> sun4m MicroSparcI, 40mhz, 16k icache 20k dcache
> ...
> Thats around 2.5us/Kbyte for csum, 

This must be hot$ that you're talking about?  Exactly when do you
invalidate the caches?

thanks.

neal

---

From: "David S. Miller" <[email-masked]>
Date: Thu, 16 May 1996 02:21:12 -0400

Date: Wed, 15 May 1996 09:40:53 -0700
   From: [email-masked] (Neal Nuckolls)

[NOTE: real lmbench results with the new checksum code in a bit, it's
       not as much of an improvement as I wanted and Solaris still
       gets better TCP bandwidth on localhost.]

The benchmark looks like:

	for(iter=0; iter < 10000; iter++) {
		for(inner=0; inner < 512; inner++) {
			csum(foo, bar, baz);
			flush_caches();
		}
	}

The 512 number is just imperical because for small buffers (less than
1k) doing just one iteration caused it impossible to measure anything
significant.

I am factoring in the time the cache flush takes.  I calculate how
long it takes to do the flush before the loop runs, then subtract that
value multiplied by (iter * inner) from the final time.

So the 17009430 microseconds is the time it takes to run the entire
loop structure minus the flushing overhead.

1700 microseconds is the time each run of the inner for loop took
again minus the flush overhead, 332 nanoseconds is the absolute time
each instance of the csum() took to run on the buffer once again this
is after subtracting the flush overhead.

Later,
David S. Miller
[email-masked]