Date: Thu, 16 May 1996 15:07:44 +0600 (ESD) From: "Serge A. Babkin" <babkin@hq.icb.chel.su> To: dyson@freebsd.org Cc: hackers@freebsd.org Subject: Re: EDO & Memory latency Message-ID: <199605160907.PAA10321@hq.icb.chel.su> In-Reply-To: <199605160613.BAA07537@dyson.iquest.net> from "John S. Dyson" at May 16, 96 01:13:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have just tried lmbench and the numbers it gives are looking > > slightly strange for me. It shows memory latency upto 500ns while > > I have 60-ns EDO memory in a Pentium/75 box. Okay, its external > > clock is 25MHz, this gives 40ns, one wait state, it gives another 40ns, > > it gives 80ns, but why the overhead is over 400ns ? > > > > Can it go from some VM subsystem activity ? I have 16M of RAM in my box > > and I runned lmbench with 8M maximal buffer size. The latency grows > > with the size of buffer. Is it possible that when > > the size of buffer grows the VM subsystem moves the non-recently used > > pages to some pool and when they are accessed again it gets the VM fault > > and remaps them back to that process? > > > There are several things going on. One is that there is propagation > time through to the main memory, it is much worse than the memory cycle AFAIK all modern PCs have local synchronous "processor-memory" bus. The physical length of wires is not very big so, I think 40ns must be enough for it. Or not? The processor's internal conveyer size is at most 5 (?) steps, for 13ns cycle this give 65ns for the maximal processor overhead. The memory refresh can add about 15% of overhead, 60ns*0.15=9ns. In sum we get 80+40+65+9=~=295ns. But the remaining 200ns are a real mystery for me. > time. Of course, that does not account for all of the 400 nsecs that you > are seeing. BTW, the R4400 boxes that I used to work on reported about > 2usecs for large strides!!!! R3000's actually overflowed the counter :-). I got overflowed the counter when I tried to run lmbench with 8M of memory. I got intensive swapping during its work and negative numbers in results. May be you had a like problem ? It looks like lmbench counts the paging time in the cumulative time of test. So, if paging makes so big latency, may be some less time consuming actions of the VM system make a little addition to the latency ? > You likely are seeing TLB overhead intrinsic to the processor. Some processors > don't have microcode TLB management, and you'll see worse numbers, because the > TLB needs to be handled in normal machine/assembly code. (Of course, on those > processors, you can tune the TLB management more freely.) But I tried to run it on Pentium that has microcode implementation of TLB. -SB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605160907.PAA10321>