[Top] [All Lists]

Re: Fast Video [was: More ramblings...]

To: riscy@pyramid.com
Subject: Re: Fast Video [was: More ramblings...]
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Date: 28 Jun 93 09:12:10 EDT
--- 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


                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


        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


                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

                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


        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

            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

            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),

            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.


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


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.


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
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
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
88/5    Estrin, Mogul,  264     Visa Protocols for Controlling Inter-
        Tsudik, Anand           Organizational Datagram Flow: Extended
89/1    Bartlett        115     SCHEME->C  A Portable Scheme-to-C Compiler
89/2    Turrini         755     Optimal Group Distribution in Carry-Skip
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
89/9    Jouppi          164     Architectural and Organizational Tradeoffs in
                                the Design of the MultiTitan CPU
89/10   Jouppi          62      Integration and Packaging Plateaus of
89/11   Jouppi, Tang    757     A 20-MIPS Sustained 32-bit CMOS
                                with High Ratio of Sustained to Peak
89/13   Jouppi          323     The Distribution of Instruction-Level and
                                Machine Parallelism and Its Effect on
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
91/3    Stark           144     Analysis of Power Supply Networks in VLSI
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
                                in Water at Subatmospheric Pressure
91/8    Yip             608     Incremental, Generational Mostly-Copying
                                Garbage Collection in Uncooperative
91/9    Hamburgen       119     Interleaved Fin Thermal Connectors for
91/10   Wall            509     Experience with a Software-Defined Machine
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
92/6  Srivastava, Wall  183     A Practical System for Intermodule Code
                                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
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
TN-17   Goldberg        198     MTOOL: A Method For Detecting Memory
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
TN-22   McFarling       152     Cache Replacement with Dynamic Exclusion
TN-23   McGillis, et al 542     Boiling Binary Mixtures at Subatmospheric
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

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


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Fast Video [was: More ramblings...], Steven D. Ligett <=