MachTen PPP Performance
The performance of a PPP link depends on the speed of the slowest element
of the five segments of a PPP connection:
PPP Client - Client/Modem - Modem/Modem - Modem/Client - PPP
Server
If PPP Client, Client/Modem, or Modem/Client operations are slow, the
rest of the communications link will operate at the fastest a PPP Client
can operate. It is important then to configure each of the PPP link for
the most performance that can be gotten from the equipment. It is also important
to consider each element in a PPP connection as a potential problem source
if a link is giving poor performance or simply will not connect.
In order to have a correct expectation of MachTen PPP performance, this
section presents the results of a few rudimentry measurements between MachTen
connected PPP clients and servers. Before this section addresses specific
measurements, a discussion of the PPP link components is presented.
MachTen PPP Performance Components
A PPP Client, Client/Modem connection, Modem/Modem connection, Modem/client
connection and a PPP server all contribute to some element of the performance
of a PPP connection. An end user application communicating with PPP will
realize an effective bit rate and round trip delay consistant with the speed
of the slowest element(s) in a link.
Typically, Modem/Modem speeds will operate at the highest possible data
rate that two modems can negotiate between themselves. Since this is a matter
of industry wide standard, modems, generally, connect at as high a speed
as commonly possible. Therefore Modem/Modem performance is fairly predictable
and generally matches the bit rate of the modem connection.
It is possible though, that the Modem/Modem link can be affected by the
quality of a phone line used to connect two modems. Before Modem/Modem performance
is dismissed as a possible cause of a slow link, it is worth while to retry
a dialup a few times, possibly at different times of the day and average
the performace across several different connections.
Also PPP client and PPP server performance tend to be predictable within
the context of the performance of the computer that is used to support each
client and server. In general, PPP client and PPP server software is handed
data a packet at a time. Most modern microprocessors are able to support
PPP packet processing faster than the fastest readily available serial communications
links exchanging data with the smallest possible packet sizes. Typically,
although not always, PPP client and PPP server implementations are not the
limiting link in the performance of a PPP connection.
Which leaves the Client/Modem and Modem/Client connections of a PPP link.
These sections, far and away, are the most problematic to properly configure.
These two sections have the largest performance impact on any PPP connection.
Effort in these two locations leads to the most improvement in performance
and the most improvement in stability for any PPP connection.
Client/Modem and Modem/Client Components
The elements of Client/Modem and Modem/client components are:
- Macintosh-based serial device interface software,
- a cable connecting a Macintosh to a modem and
- the configuration of the host interface from within the modem.
See Macintosh modem cabling and
modem-based
host interface configuration for more information.
MachTen PPP Performance Measurements
Several different Macintoshes and different modem configurations were used
to measure effective data transfer performance of large blocks of data.
To measure what is considered a worst case measurement, relatively low speed
Motorola 68000 Macintoshes were used for the measurements.
One set of measurements was performed with a PowerBook 140 and an LCIII
Macintosh. Both the PowerBook 140 and the LCIII were configured with a SupraFax
14.4 modems. The systems were configured and connected for PPP operations.
Once the PPP link was established, all tests were performed by transferring
data using the FTP protocol over TCP/IP over the PPP link. When the PowerBook
140 was receiving data it consistantly received at an effective rate of
between 12K and 13K bits-per-second. In each transmission there were either
zero or one retransmitted packet indicating no link or character level loss
during the transfer. When the PowerBook 140 was transmitting to the LCIII,
the 140 was also able to transmit at between 12K and 13K bits-per-second.
Again there was minimal retransmission activity at the TCP level indicating
no link or character level lossage.
The second set of measurements was repeated with a TelePort Platinum 28.8
modem. In the second set of measurements, even though one of the modems
was capable of operating at 28.8K bit-per-second, it was limited to a bit
serial rate of 14.4K bits-per-second by the second SupraFax 14.4 modem.
This mis-match was deliberate to understand if Modem-Modem differences would
signifcantly limit end-to-end effective performance. When the PowerBook
140 was transmitting, effective data transfer at 11K bits-per-second was
achieved. However, the number of retransmissions varied from zero to 21
indicating significant loss at the character-by-character level while solid
effective communications was were still successfully achieved at the user
level. When the PowerBook 140 was transmitting, effective data rates in
the 12K to 13K bits-per-second were readily found. This time retransmissions
ranged from 0 to 7 retransmission so it is assumed that minimal amounts
of characters were lost and that the LCIII was able to receive without character-by-character
loss.
The last set of measurements was performed by exchanging a SupraFax 28.8
modem for the SupraFax 14.4 modem so that now the link could be setup at
28.8K bits-per-second and application level measurements performed. In this
case the link performed equally well in both transmit and receive directions.
The PowerBook 140 transmitted an effective data rate of 26K bits-per-second.
Retransmissions we minimal with 1 to 3 retransmissions. When the PowerBook
140 was receiving the data rate ranged from 24K to 26K bits-per-second again
with minimal 1 to 6 retransmissions.
In conclusion, it is demonstrated with these measurements that even a slow
Macintosh, properly configured, can effectively utilize a 28.8K PPP link
with good performance and minimal packet retransmission.
Performance Measurements with Power Macintoshes
To test the basic performance of Power Macintoshes with the latest version
of the Serial DMA device driver a Power Macintosh 6100/66 and a Power Macintosh
8100/80 were substituted for the PowerBook 140 and for the LCIII Macintosh.
Both Power Macintoshes were using the same 28.8K modems used in the last
68000 Macintosh measurement above.
The measurement results here were virtually the same as the results using
the slower 68000 Macintoshes. When the 6100/66 was receiving it received
data at a rate of 26K to 27K bits-per-second with no or one retransmission.
When the 6100/66 was transmitting, it achieved a data rate of 26K bits-per-second
with no or one retransmission. Indicating that as expected Power Macintoshes
correctly utilizing Serial DMA are quite capable of supporting 28.8 PPP
communications.
To round out the performance measurements, the modems were replaced with
a hardwire line and the data rates were increased to 115K bits-per-second.
The Power Macintoshes performed quite well obtaining 112K bits-per-second
on reception and 108K bits-per-second on transmission. In each case there
were virtually no retransmissions.
| Tenon Home |
Products |
Order |
Contact Us |
About Tenon |
Register |
Tech Support |
Resources |
Press Room |
Mailing Lists |
|
Copyright©2009 Tenon Intersystems, 232 Anacapa Street, Santa Barbara,
CA 93101. All rights reserved.
Questions about our website - Contact:
webmaster@tenon.com.
|