======================================================================
                    F A Q 
                    doc: Fri Apr 24 14:58:47 1992
                    dlm: Tue Aug 17 16:52:34 1993
                    (c) 1992 ant@ips.id.ethz.ch
                    uE-Info: 10 57 T 0 0 72 3 2 8 ofnI
======================================================================

Q: I get the message ``Warning: stderr is lost!'' in the messages file.
A: Recompile everything with the NOASYNCIO_QUIRK defined.

Q: When I issue an inetray or an inetray.ping I get a a dot every few
   seconds and the program does not seem to proceed.
A: There is either another process using the same socket running on your
   machine (another inetray, maybe), or the servers didn't terminate
   normally on your last session. You can check by issuing netstat -f
   inet.
   If there are still workers running on remote machines, you just have
   to wait roughly one minute to give them time to shut down orderly; if
   another program uses the same port, you have to add a resultport:
   definition to your ~/.inetrayrc.
   Note that inetray and inetray.ping will just continue trying on the
   port, printing a dot every few seconds until the problem disappears
   (which eventually will).

Q: Why does inetray need so much more memory than rayshade?
A: There are several reasons for this:
   a) The dispatcher needs a lot of memory since it has to buffer a
      whole frame. Rayshade does not have to buffer a whole frame since
      it renders strictly sequentially.
   b) The dispatcher furthermore reads the input file and builds up the
      geometry data. This feature allows printing of the error and
      warning messages before the rendering actually starts (and cloggs
      the syslogs on the worker machines). The memory could and should
      be freed after checking the input before allocating the frame
      buffer but this is not done at the moment.
   c) On every worker machine the inputfile is read and geometry built
      up for every used CPU - if you use more than one CPU you need more
      memory. This simplifies the handling of multiple CPUs greatly:
      every CPU can be viewed as simply another machine. No special code
      is required.
   d) The actual work is handled by a forked process. This process is a
      copy of the server process and contains all geometry data.
      Therefore, 2 copies of all data exist for each CPU used. This
      solution is quite ugly in terms of memory but very nice in terms
      of simplicity. Without forking a new process, process controls
      (basically sending remote signals) would be very hard if at all
      possible without changing the rayshade source. The parent must
      keep the memory because it will fork further workers later on.

Q: I don't seem to be able to ignore a host from my ~/.inetrayrc file.
A: add ignore: name, where name is the exact(!) string as printed by
   inetray.ping.

Q: I had problems in the last session and now there seem to still be
   servers/workers running and/or connections open.
A: Issue an inetray.kill in the same directory where you started the
   problem session. All what's left running after that should kill
   itself after roughly a minute anyway.

Q: I think Inetray is a great program and I want to send loads'a money
   to the author to thank him.
A: Do so: Andreas Thurnherr, Birkenstr 3, 8640 Rapperswil, Switzerland.
   
Q: When I trace, workers register correctly but suddenly I get a lot of
   messages about lost connections.
A: The workers terminated while reading and processing the input-files.
   Check for error messages in your syslog (or in your temp-directory if
   NOASYNCIO_QUIRK is set). Usually the files are not there or not
   accessible for the user under which the servers are running. Note
   that files like /tmp are usually there on every machine but they are
   different even on machines which share there filesystems.