Date: Wed, 26 Feb 1997 17:46:32 +1100 From: Bruce Evans <bde@zeta.org.au> To: asami@vader.cs.berkeley.edu, bde@zeta.org.au, jin@george.lbl.gov, mark@quickweb.com Cc: freebsd-hardware@freebsd.org, kuku@gilberto.physik.rwth-aachen.de, robsch@robkaos.ruhr.de Subject: Re: Memory speed of P6-200 (256k) Message-ID: <199702260646.RAA06491@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>*** The same machine with different FreeBSD ***
>
>% dmesg
>Copyright (c) 1992-1996 FreeBSD Inc.
>Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
>
>FreeBSD 2.2-970215-GAMMA #0: Wed Feb 19 15:22:41 PST 1997
> root@adv-pc-1.lbl.gov:/usr/src/sys/compile/MinMax
>Calibrating clock(s) relative to mc146818A clock ... i586 clock: 200455533 Hz, i8254 clock: 1193190 Hz
>CPU: Pentium (200.45-MHz 586-class CPU)
> Origin = "GenuineIntel" Id = 0x52c Stepping=12
> Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8>
>real memory = 67108864 (65536K bytes)
>avail memory = 62623744 (61156K bytes)
>
>% dd if=/dev/zero of=/dev/null bs=1m count=1000
>1000+0 records in
>1000+0 records out
>1048576000 bytes transferred in 7.591523 secs (138124591 bytes/sec)
>0.0u 7.5s 0:07.62 99.4% 71+2841k 0+0io 3pf+0w
>
># this result is better than the standard memory bandwidth, but worse than
>the maximum memory bandwidth.
>
>That is why I said "It is O.S. dependent."
That's what I said too. I mentioned this benchmark as a quick way to
see if you have the i586-optimized copy routines. It also happens to
expose many poorly tuned memory systems :-).
>The PCI is a 64-bit wide bus. The maxmimum memory speed you can get from
>this bus is 1000000000 * 8 / 60ns = 133333333 Bytes/sec (no inteleave).
>However, no memory sub-system in PC/UNIX O.S. uses 64-bit memory bandwidth
>currently because of the CPU bus.
The memory bandwidth has very little to do with this. Triton memory buses
are normally 60 or 66 MHz with burst access timing of x-2-2-2 or x-3-3-3.
A P5/133 can almost (*) sustain 6-2-2-2 timing provided the bursts are to
the same page and writes are done 64 bits at a time. Recent versions
of FreeBSD have copy routines tuned to avoid switching the page and to
write using the FPU. This gives a memory bandwidth of
1000000000 * 32 / ((6 + 2 + 2 + 2) * 15) = 177777777 Bytes/sec (4/3 times
the PCI bandwidth). In practice, the current and 2.2 FreeBSD bzero()
achieves 176725593 Bytes/sec for a block size of 4MB.
(*) Copying through the FPU takes a lot of CPU cycles. `fistpl' must
be used to write. It takes 6 cycles, so a burst of 4 of these takes 24
cycles - the same time for a 133 MHz CPU as for a 66 MHz memory system
with a 6-2-2-2 burst cycle. The CPU can't quite keep up, since it has to
do some loop control instructions too. The loop control instructions only
cost 2-3 cycles, but there is a larger penalty (about 10 more cycles?)
for not keeping up, so the FreeBSD copy routines unroll the loop a few
times so that there is only a penalty for every 256 bytes. A P5/166
should not have these problems, but a P5/100 is significantly slower
because it can't keep up within the loop.
>Another tip is even some motherboards are using same PCI shipset, the memory
>performance may vary.
>For example, compare ASUS Triton-{I, II} with three different Intel
>motherboards (EV2, PT-2000, ZAPPA) with Triton-II PCI chipset,
>the memory I/O speed does not have much different;
>however, ASUS motherboard can use 70ns memory chip v.s. Intel motherboards have
>to use 60ns memory chip. Very unbelieveable fact, right? This is hardware issue.
The burst timing is different. The software can sometimes do better if it
knows the precise timing (e.g., when combining writing with reading, it
best to do the reads as late as possible, but if they are too late then
you lose). This is more of an issue on slow CPUs. The FreeBSD routines
are tuned for the timing on the authors' systems.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702260646.RAA06491>