Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!munnari.oz.au!labtam!graeme
From: graeme@labtam.labtam.oz (Graeme Gill)
Newsgroups: comp.arch
Subject: Re: Let's pretend
Message-ID: <5823@labtam.labtam.oz>
Date: 28 Dec 90 08:29:51 GMT
References: <3066@crdos1.crd.ge.COM> <5813@labtam.labtam.oz> <3853@bnr-rsc.UUCP>
Organization: Labtam Australia, Melbourne, Australia
Lines: 32

In article <3853@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes:
> In article <5813@labtam.labtam.oz> graeme@labtam.labtam.oz (Graeme Gill) writes:
> > /* omitted to save space */
> 
> 
> Hmm, 208 MBit/sec = 26 MByte = 26 MPixel of 8 bits each.
> 
> How do you do 26 million byte writes per second on a 80960? What speed are you
> running it at? How is your frame buffer organized?
>
    This is our slow machine, and it runs at 20 Mhz. We have a new model that
runs at 25 Mhz. The Frame store is packed 4 pixels per 32 bit word. A burst
write instruction takes 2 + 4 * 2 + 1 clock cycles per 16 pixels of bus time.
At 20 MHz that equates to a theoretical rate of 29.1 Mbytes/sec (ignoring
refresh overhead, interrupt routine overhead, Ethernet DMA overhead etc.)
The measured rates using x11perf for 500x500 filled areas is 26 Mpixels/sec.
    Since it has a 3 deep write queue and scoreboarded reads, the internal
CPU operation proceeds in parallel with the bus cycles.

> 
> Also, how much CPU is left for the user applications?
> 
    None, Its an X terminal :-) the application runs on the host. This sometimes
makes it a faster system than a workstation that has to both draw and run
the application. There are the usual tradeoffs of centralized vs. distributed
computing.

> Stanley Chow        BitNet:  schow@BNR.CA

Graeme Gill
Electronic Design Engineer
Labtam Australia