--- Tommy Thorn wrote:
The 34010 might be good if it simplifies the design and helps bring the price
down, but I worry over the affect on video performens (and complexity of the
software). One can do quite well with a dumb frame buffer with high
bandwidth. Joel McCormack's article ("Writing Fast X Servers for Dumb Color
Frame Buffers. Software: Practice and Experience 20(S2):83-108, October 1990)
shows this (using a R3000 BTW).
--- end of quoted material ---
I suggest reading this article before going off the deep end. It is
available as PostScript from DECWRL. Here's info on how to get to the DECWRL
server, and an index of articles. The mentioned article is # 91/1.
Date: Fri, 9 Apr 93 07:19:03 -0700
Subject: How to use the WRL Tech Report Service
From: WRL Tech Report Service <wrl-techreports@pa.dec.com>
In-Reply-To: message from steven.d.ligett@dartmouth.edu (steven d. ligett)
To: steven.d.ligett@Dartmouth.EDU (steven d. ligett)
This message comes to you from the WRL Tech Report Service,
wrl-techreports@decwrl.dec.com. It received a message from you asking
for help.
The technical reports server is a mail-response program. That means
that you mail it a request, and it mails back the response.
The server is a very dumb program. It does not have much error
checking. If you don't send it the commands that it understands, it
will just answer "I don't understand you".
The server has 7 commands. Each command must be the first word on a
line. The server reads your entire message before it does anything,
so you can have several different commands in a single message. The
server treats the "Subject:" header line just like any other line of
the message. You can use any combination of upper and lower case
letters in the commands.
The technical reports are organized into a series of directories and
subdirectories (Abstracts, PS, Status).
Technical notes are for rapid distribution of technical material.
Usually this represents work in progress. Our technical reports may
include large portions of prior technical notes.
Network notes are a new addition to the server. They are for rapid
distribution of network related material. Network notes are usually a
means of sharing network expertise and experience.
---------------------------------------------------------------------------
If you are bored with reading documentation and just want to try
something, then send the server a message containing the line
send index
When you get the index back, it will give you the names of all of the
Tech-notes and Net-notes in the archive; send the server another
message asking it to send you the abstracts that you want:
send abstracts 86/3 87/4 prospectus.87
If you are using a mailer that understands "@" notation, send to
wrl-techreports@decwrl.dec.com. If your mailer deals in "!" notation,
try sending to {someplace}!decwrl!wrl-techreports, e.g.
ihnp4!decwrl!wrl-techreports. If your mailer deals in "::" notations,
try sending to decwrl::wrl-techreports. For other mailers, you're on
your own.
---------------------------------------------------------------------------
Here is some more documentation. The server has 7 commands:
"help" command: The command "help" or "send help" causes the server to
send you the help file. You already know this, of course,
because you are reading the help file. No other commands are
honored in a message that asks for help (the server figures
that you had better read the help message before you do
anything else).
"index" command: if your message contains a line whose first word is
"index", then the server will send you the index of the
contents of the archive.
You can then send back another message to the server, using a
"send" command (see below) to ask it to send you the files
whose name you learned from that list.
If your message has an "index" or a "send index" command, then
all other "send" commands will be ignored. This means that you
cannot get an index and data in the same request. This is so
that index requests can be given high priority.)
"send" command: if your message contains a line whose first word is
"send", then the server will send you the item(s) named on the
rest of the line. To name an item, you give its directory and
its name. For example
send abstract 87/5
or
send postscript 87/3
Once you have named a category, you can put as many names as
you like on the rest of the line; they will all be taken from
that category. For example:
send abstract 86/3 86/4 87/1 87/2
Each "send" command can reference only one directory. If you
would like to get one abstract and one postscript file, you
must use two "send" commands, one beginning "send abstract"
and the other beginning "send postscript".
You may put as many "send" commands as you like into one
message to the server, but the more you ask for, the longer it
will take to receive. See "FAIRNESS", below, for an
explanation. Actually, it's not strictly true that you can put
as many "send" commands as you want into one message. If the
server must use uucp mail to send your files, then it cannot
send more than 100K bytes in one message. If you ask for more
than it can send, then it will send as much as it can and
ignore the rest.
"add" command: if you are not already on the mailing list, send a
message with the line
add
in the body of your message, followed by your mailing address.
Human intervention is required to add someone to the mailing
list, so this will take a little while. When you've been
added, you'll get an acknowledgement message back, and you'll
receive future announcements of new technical reports as they
become available.
"order" command: while we make PostScript source for many of our
technical reports available, most are larger than you might
like to send through the electronic mails. We expect most
people would like hard copy, and the order command allows you
to do that.
Send a line of the form
order Prospectus.87
or
order 86/4 87/3
and the server will queue an order request. The
acknowledgement message will contain an ID number that
identifies the order; you can use the "status" command to
inquire into what's taking so long.
Orders are filled by hand as quickly as possible, but
sometimes there are delays. If several of the reports that
you've ordered are out of print, we'll hold the order until we
can ship everything. The "status" category of the "send"
command is available to let you find out about which orders
are out of print.
We find your address in a database that's keyed by your name
as it appears in our mailing list; if that doesn't
automatically appear somwehere in the header of your message,
please include it somewhere in the body. If you're not on our
mailing list yet, include your entire postal address.
"status" command: once you have an order ID in hand, you can find out
how it's progressing through the mill. Send the server a line
like
status 573350661.19909
and the server will respond with what's been done so far with
the order.
If you don't know the order number, just send
status
and the server will tell you about all pending orders from you.
"path" command: The "path" command exists to help in case you do not
get responses from the server when you mail to it.
Sometimes the server is unable to return mail over the
incoming path. There are dozens of reasons why this might
happen, and if you are a true wizard, you already know what
those reasons are. If you are an apprentice wizard, you might
not know all the reasons but you might know a way to
circumvent them.
If you put in a "path" command, then everything that the
server mails to you will be mailed to that address, rather
than to the return address on your mail. For example, if you
say
path pyramid!rutgers!zakkaroo!jj
then all mail sent by the server will be sent to that address.
Note: decwrl does NOT have a uucp link to seismo. A command
like
path seismo!someplace!name
will guarantee that you do not receive the response. We do
have a link to seismo.css.gov (and all other Internet sites),
permitting
path seismo.css.gov!someplace!name
If you would like the server to determine a uucp path for you,
using the most recent pathalias data, then put in a "path"
command with yourname@site.uucp, e.g.:
path person@place.uucp
As you probably know, the pathalias data is sometimes wrong,
but it is often right.
EXAMPLES:
1) Find out the list of reports that are in the archive. Send this message:
To: wrl-techreports@decwrl.dec.com
Subject: hi there
send index
2) Get the abstracts of reports about networking from the server (you have
learned their file names from the list that was sent to you in step 1).
To: wrl-techreports@decwrl.dec.com
send abstracts 87/2 87/3
send abstracts 87/4 87/7
3) Order the compiler reports, and send the responses over the best
path to my site:
To: seismo.css.gov!decwrl!wrl-techreports
path myname@site.uucp
order 86/3 87/1 87/5
NOTES:
The server acknowledges every request by return mail. If you don't get
a message back in a day or two (depending on how close you are to
decwrl on the network) you should assume that something is going
wrong, and perhaps try a "path" command. If you aren't getting
anywhere and you don't know a wizard to help you, try putting
path myname@site.uucp
in your message, where "myname" is your mailbox name and "site" is the
uucp name of your machine.
The delays in sending out large items from the archives are
intentional, to make it difficult to get copies of everything in the
archives. If you are new to the network and would like to get all
back issues of everything, you should use order instead of send.
Don't send mail with long lines. If you want to ask for 10 reports in
one request, you don't need to put all 10 of them in one "send"
command. The server is quite able to handle long lines, but before
your mail message is received by the server it might pass through
relay computers that will choke on long lines.
The server does not respond to requests from users named "root",
"system", "daemon", or "mailer". This is to prevent mail loops. If
your name is "Bruce Root" or "Joe Daemon", and you can document this,
I will happily rewrite the server to remove this restriction. Yes, I
know about Norman Mailer and Waverley Root. Norman doesn't use
netmail and Waverley is dead.
FAIRNESS:
The server contains many safeguards to ensure that it is not
monopolized by people asking for large amounts of data. The mailer is
set up so that it will send no more than a fixed amount of data each
day. If the work queue contains more requests than the day's quota,
then the unsent files will not be processed until the next day.
Whenever the mailer is run to send its day's quota, it sends the
requests out shortest-first.
If you have a request waiting in the work queue and you send in
another request, the new request is added to the old one (thereby
increasing its size) rather than being filed anew. This prevents you
from being able to send in a large number of small requests as a way
of beating the system. If you request 10 reports together, you will
get substantially higher priority than if you make 10 requests for 1
report each.
The reason for all of these quotas and limitations is that the
delivery resources are finite, and there are many people who would
like to make use of the server.
Date: Fri, 9 Apr 93 08:19:04 -0700
Subject: INDEX - per your request
From: WRL Tech Report Service <wrl-techreports@pa.dec.com>
In-Reply-To: message from steven.d.ligett@dartmouth.edu (steven d. ligett)
To: steven.d.ligett@Dartmouth.EDU (steven d. ligett)
Index of top level from WRL Tech Report Service (updated Apr 2 17:15)
-----------------------------------------------------------------
=== TECHNICAL REPORTS ===
Key Author(s) Size (KB)* Title
=======================================================================
Prospectus.87 36 WRL Prospectus 87-88
86/1 Nielsen 497 Titan System Manual
86/3 Wall 136 Global Register Allocation at Link Time
86/4 Hamburgen 279 Optimal Finned Heat Sinks
87/1 Wall/Powell 126 The Mahler Experience: Using an Intermediate
Language as the Machine Description
87/2 Mogul et al. 161 The Packet Filter: An Efficient Mechanism for
User-level Network Code
87/3 Kent/Mogul 137 Fragmentation Considered Harmful
87/4 Kent 544 Cache Coherence in Distributed Systems
87/5 Wall 129 Register Windows vs. Register Allocation
87/6 Asente Editing Graphical Objects using Procedural
Representations
87/7 Reid 103 The USENET Cookbook: and Experiment in
Electronic Publication
88/1 Dion Fast Printed Circuit Board Routing
88/2 Bartlett 220 Compacting Garbage Collection with Ambiguous
Roots
88/3 Mogul 64 The Experimental Literature of The Internet:
An Annotated Bibliography
88/4 Boggs et al. 596 Measured Capacity of an Ethernet: Myth and
Reality
88/5 Estrin, Mogul, 264 Visa Protocols for Controlling Inter-
Tsudik, Anand Organizational Datagram Flow: Extended
Description
89/1 Bartlett 115 SCHEME->C A Portable Scheme-to-C Compiler
89/2 Turrini 755 Optimal Group Distribution in Carry-Skip
Adders
89/3 Hamburgen 244 Precise Robotic Paste Dot Dispensing
89/4 Mogul 133 Simple and Flexible Datagram Access Controls
for Unix-based Gateways
89/5 Srinivasan, 419 Spritely NFS: Implementation and Performance
Mogul of Cache-Consistency Protocols
89/7 Jouppi, Wall 220 Available Instruction-Level Parallelism for
Superscalar and Superpipelined Machines
89/8 Jouppi, et al. 146 A Unified Vector/Scalar Floating-Point
Architecture
89/9 Jouppi 164 Architectural and Organizational Tradeoffs in
the Design of the MultiTitan CPU
89/10 Jouppi 62 Integration and Packaging Plateaus of
Processor
Performance
89/11 Jouppi, Tang 757 A 20-MIPS Sustained 32-bit CMOS
Microprocessor
with High Ratio of Sustained to Peak
Performance
89/13 Jouppi 323 The Distribution of Instruction-Level and
Machine Parallelism and Its Effect on
Performance
89/14 Borg, et al. 924 Long Address Traces from RISC Machines:
Generation and Analysis
89/17 Wall 113 Link-Time Code Modification
90/1 Tang,Yang 528 Noise Issues in the ECL Circuit Family
90/2 Larrabee 568 Efficient Generation of Test Patterns Using
Boolean Satisfiability
90/3 Larrabee Two Papers on Test Pattern Generation
90/4 Nelson 131 Virtual Memory vs. The File System
90/5 Mogul 273 Efficient Use of Workstations for Passive
Monitoring of Local Area Networks
90/6 Fitch 135 A One-Dimensional Thermal Model for
the VAX 9000 Multi Chip Units
90/7 Mayo, et al. 1990 DECWRL/Livermore Magic Release
90/9 McGillis et al. 282 Pool Boiling Enhancement Techniques for Water
at Low Pressure
91/1 McCormack 286 Writing Fast X Servers for Dumb Color Frame
Buffers
91/3 Stark 144 Analysis of Power Supply Networks in VLSI
Circuits
91/4 Boggs 248 TurboChannel T1 Adapter
91/5 McFarling 203 Procedure Merging with Instruction Caches
91/6 Bartlett 739 Don't Fidget with Widgets, Draw!
91/7 McGillis et al. 543 Pool Boiling on Small Heat Dissipating
Elements
in Water at Subatmospheric Pressure
91/8 Yip 608 Incremental, Generational Mostly-Copying
Garbage Collection in Uncooperative
Environments
91/9 Hamburgen 119 Interleaved Fin Thermal Connectors for
Multichip
Modules
91/10 Wall 509 Experience with a Software-Defined Machine
Architecture
91/11 Mogul Network Locality at the Scale of Processes
91/12 Jouppi 382 Cache Write Policies and Performance
92/1 Hamburgen et al. 244 Packaging a 150W Bipolar ECL Microprocessor
92/2 Mogul 725 Observing TCP Dynamics in Real Networks
92/3 Wall 163 Systems for Late Code Modification
92/5 Kao 1719 Piecewise Linear Models for Switch-Level
Simulation
92/6 Srivastava, Wall 183 A Practical System for Intermodule Code
Optimization
at Link-Time
93/1 McCormack et al. 303 A Smart Frame Buffer
=== TECHNICAL NOTES ===
Key Author(s) Size(KB)* Title
=======================================================================
TN-4 Reid, Kent 65 TCP/IP PrintServer: Print Server Protocol
TN-7 Kent 88 TCP/IP PrintServer: Server Architecture and
Implementation
TN-9 McCormack 227 Smart Code, Stupid Memory A Fast X Server
for a Dumb Color Frame Memory
TN-11 Ousterhout 64 Why Aren't Operating Systems Getting Faster
As Fast As Hardware?
TN-12 Bartlett 81 Mostly-Copying Garbage Collection Picks Up
Generations and C++
TN-15 Wall 353 Limits of Instruction-Level Parallelism
TN-16 Mogul, Borg 227 The Effect of Context Switches on Cache
Performance
TN-17 Goldberg 198 MTOOL: A Method For Detecting Memory
Bottlenecks
TN-18 Wall 184 Predicting Program Behavior Using Real or
Estimated Profiles
TN-19 Wall 129 Systems for Late Code Modification
TN-21 Srivastava 98 Unreachable Procedures in Object-oriented
Programming
TN-22 McFarling 152 Cache Replacement with Dynamic Exclusion
TN-23 McGillis, et al 542 Boiling Binary Mixtures at Subatmospheric
Pressures
TN-24 Fitch 61 A Comparison of Acoustic and Infrared
Inspection Techniques for Die Attach
TN-26 Boggs 119 TurboChannel Versatec Adapter
TN-27 Mogul 119 A Recovery Protocol for Spritely NFS
TN-29 Boyle Electrical Evaluation Of The BIPS-0 Package
TN-30 Bartlett 336 Transparent Controls for Interactive Graphics
TN-32 Dion, Monier 265 Design Tools for BIPS-0
*(NOTE: Not all of the above reports and notes are available in
Postscript form. Only, those with a size listed are available in
Postscript.)
Technical notes are for rapid distribution of technical material. Usually
this represents work in progress. Our technical reports may include large
portions of prior technical notes.
To see the abstract for any report or note, send the server a message saying
"send abstract 90/4" or "send abstracts 91/3 TN-7 NN-2", etc. Capitalization
does not matter.
To retrieve the PostScript for any report or note, send the server a message
saying "send postscript 90/4" or "send postscript 91/3 TN-7 NN-2", etc.
Capitalization does not matter.
Send server requests to wrl-techreports@decwrl.dec.com, or
{ihnp4,decvax,ucbvax,hplabs,allegra}!decwrl!wrl-techreports,
or DECWRL::WRL-TECHREPORTS.
|