The response time requirements are important for insuring that T.30 protocol messages are received in a timely fashion. On a loaded system the protocol process may be preempted by other activities and not be scheduled fast enough to satisfy the protocol timing requirements. This can usually be guarded against by assigning the facsimile process a high scheduling priority. Unfortunately most UNIX systems do not support such facilities and so even if it is possible to receive serial line input with the minimum of delay, protocol timing requirements may not be met because of delays in scheduling the execution of the fax server process. For this reason the facsimile server processes attempt to raise their scheduling priority while actively sending or receiving facsimile. At other times, such as when doing queue management operations, processes run at a normal priority. On Silicon Graphics systems the ``high priority'' is a nondegrading scheduling priority that is above the priorities of the normal system processes. On SVR4-derived systems the ``high priority'' is a real-time scheduling priority. On other systems the server currently always runs at the same (normal) scheduling priority. For more details consult the setProcessPriority routine in faxd/ModemServer.c++.
In summary, If you want to use a Class 1 modem with this software and your system does not provide support for low latency serial line input you are likely to have troubles. If your system does not provide a mechanism for raising process scheduling priority (note that this is not the same as the UNIX ``nice'' parameter), then you may see problems when the server is under load. Exactly how much load will cause trouble is dependent on the system configuration and processing power.