The proper configuration of both MachTen and an attached modems is important
in getting the most effective data transfer speeds for PPP data. Mis-configuration
of MachTen or a modem, unfortunately, can result in what appears to be successful
data transfer. However, mis-configuration can result in "slow"
or only partial setup of a link.
For an understanding of the kind of transfer performance that should be
available to a MachTen system, a few transfer measurements were performed
with different modems under different conditions. See MachTen
PPP Performance for more information.
Below are some of the known mis-configurations, how to recognize them and
what to do to reconfigure your system to remove them.
"Slow" Effective Data Transfer
Mis-configuration of modem flow control in both the modem and MachTen can
result in data loss and what looks like "slow" operation. The
slow operation is due to the need to retransmit data that has been lost.
If flow control is not set up properly, effective data transfer can sometimes
only approach one-half of the bit signaling rate. For example, if a modem
is configured to run a 28.8K bits-per-second and a PPP link has been successfully
established. During heavy data transfer, the data is received at between
11K and 12K bits-per-second. It is probable that data is being lost and
that the MachTen and modem configuration should be investigated.
When MachTen is to use a modem operating at more than 14.4K bits per second,
MachTen should be configured to use the "/dev/ttyfa" or "/dev/ttycfa"
for modems connected to the Macintosh modem port or MachTen should be configured
to use the "/dev/ttyfb" or /dev/ttycfb" for modems connected
to a Macintosh printer port. This will cause MachTen to use the RTS/CTS
hardware flow control signals to "pace" data transfer between
the attached modem and MachTen.
The attached modem should also be configured to use hardware (RTS/CTS) flow
control. This setting varies with different modem manufacturers and the
modem reference manual should be consulted to verify the proper setting.
In standard Hayes modem command terms, the &K3 command should be included
in the attached modems opreational setting. See Modem
Configuration for more information about viewing an existing modem configuration
and for resetting parts of that configuration from MachTen.
Mis-configuration can also result during what appears to be good data transfer
at good effective data rates, but the link will be reset during heavy data
This can be caused by the modem mistakenly interpreting a modem control
as a request from a MachTen system to reset the connection.
The attached modem should be confitured to ignore DTR (Data Terminal Ready)
with the use of the &D0 Hayes modem command. In many Macintosh-to-modem
cables, the DTR signal is tied to the HSKo (pin 1) of the Macintosh. The
HSKo signal is used by a Macintosh to flow control data from a Macintosh
to a modem. If this signal is mistakenly interpreted as a request to "enter
command mode" or to "hang up", a modem will work very well
setting up a PPP connection and even initializing the first few commands
necessary to make a PPP link operational. However, when data is to be transmitted,
even in modest quantity, a Macintosh may change the state of the HSKo pin
to indicate a Request to Send since a change in state of that signal may
cause DTR to be interpreted as changing in state, a mis-configured modem
may hang up or simply enter command state. Either situation interrupts an
ongoing transfer and looks to an end user as if the link went down.
See Modem Configuration for more information
about viewing an existing modem configuration and for resetting the &D0
configuration from MachTen.
Carrier (DCD) Reset
DCD mis-configuration can result in partial success in configuring a modem
and in even dialing and establishing a remote conversation. However, when
the "chat" portion of the link setup is complete no further data
is received from the remote side. When debug information is printed with
the /etc/pppclient debug flag, the link appears to connect, dial and configure
the modem properly. It even converses with the remote server to login and
establish PPP operations. However, when the first PPP specific command is
sent, the LCP ConfReq command, no communication is returned from the remote
end. The link behaves as if the remote end has gone deaf to local modem
In MachTen any change in the DCD Carrier signal is used to signal the termination
of a session with a modem. In many Macintosh-to-modem cables the Macintosh
input, the GPi input (pin 7), is left unconnected and does not reflect the
true state of the modem DCD signal. MachTen misinterprets transitions on
this unconnected signal and at random time can cause a connection to be
There are two courses of action in this situation. First a Macintosh-to-modem
cable can be obtained for about $15 that has the GPi to DCD signal connected
and therefore modem DCD signalling will be properly transmitted to MachTen.
See GPi Serial Cable for more information.
Second, MachTen can be reconfigured to use "/dev/ttyfa" or "/dev/ttyfb"
instead of "/dev/ttycfa" or "/dev/ttycfb". Using "/dev/ttyfa"
or "/dev/ttyfb" will cause MachTen to ignore transitions of the
GPi input and treat the status of the DCD as if it were always active. See
Serial Device Files for more information.