A systematic Characterization of Application Sensitivity to Network Performance

32
calls a handler in the pseudo-Ethernet driver, at (5). At this point, the pseudo-Ethernet driver allo-
cates a STREAMS message structure and copies the packet into it. Next, the driver calls the read-put
procedure of the IP module, and the messages eventually reaching the stream head. So far, all the
receive processing has taken place inside the interrupt handler. Finally, when the application calls
the
read
call, the message is copied into the application’s memory.
Encapsulation is relatively straightforward. A Maximum Transmission Unit (MTU) of
3584 bytes (3.5K) was chosen because this represents the smallest unit that achieves the maximum
bandwidth. We shall explore bandwidth in the calibration section.
A number of problems occurred when layering the STREAMS framework on top of the
Active Message abstraction. The basic problem stems from interfacing the STREAMS notion of
queues on top of the request-reply model. Modifications to GAM include eliminating the request-
reply model and reliability guarantees. In addition, the GAM longevity model for medium messages
did not support the STREAMS abstraction well, therefore the pseudo-Ethernet driver makes copies
of the messages. The next paragraphs describe the request-reply semantics, reliability, longevity
problems and the workarounds.
Request-Reply Semantics
The basic problem with maintaining request-reply semantics is that the
matching of requests to replies is difficult because the STREAMS subsystem can send data in an in-
terrupt handler. The following example illustrates this problem. An Internet Control Message Pro-
tocol (ICMP) ping request arrives. In the interrupt handler, the IP module calls the ICMP routine.
Still in the interrupt handler, the ICMP routine responds to the ping request by calling the write-put
routine of the pseudo-Ethernet. All this happens before control is returned to the Active Message
module. In the STREAMS model, the higher-layers can send an arbitrary number of messages in
response to an incoming message, thus violating a semantic tenet of the GAM abstraction: that no
requests can be sent during the execution of a reply handler.
While there are different possible solutions to the problem, the easiest to implement and
most compatible with the STREAMS framework was to simply eliminate the request-reply model.
All messages become “requests”, and are deposited directly into the send queue of the LCP. The
notion of a “reply” message was eliminated from the code running on the host.
Reliability
Recall that reliability was built in the Active Message layer by a combination of request-
reply semantics linked to storage management. Once the request-reply model was discarded, main-
taining reliability was dropped from the system, primarily because the increase in storage manage-

---

33
ment complexities was not seen as worth the engineering effort required. Higher layers, such as TCP
and RPC, must be used to provide reliability semantics in the TCP/IP-GAM system.
In addition to the difficulties of storage management, blocking was also a problem with in-
corporating the user-level GAM implementation into the kernel. The reliability of GAM can require
blocking the current thread for extended periods. If the number of outstanding requests is too high,
GAM spin-waits until an incoming reply signals a request buffer is “free”. Although this blocking is
fine, even beneficial, for user-level programs, spin-waiting a thread for an arbitrary time is not per-
mitted inside the kernel—such behavior can crash the entire system. The kernel GAM layer was thus
modified to simply discard messages when outbound LCP queue is full. Although the STREAMS
system provides for a “queue-full” signal to be propagated to higher modules, the added complexity
of using this mechanism was judged to be not worth the engineering effort.
Data Longevity
Data longevity semantics in the GAM abstraction effectively placed enough re-
strictions that copies had to be made on both the send and receive sides. On the sending side, the
GAM model returns control to the sender once (1) the data area can be re-used for data storage and
(2) the system has enough buffering to accept the message. Although the previous changes to the
GAM layer eliminated these restrictions, the decision was made that the extra performance gained
from zero-copy (inside the kernel) sends was an excessive engineering effort needed for this appa-
ratus.
A second issue arises with attempting zero-copy sends on the Sun UltraSPARC worksta-
tion (the sun4u architecture). In a sun4u environment, I/O devices have their own address space;
they cannot access memory in an arbitrary fashion. Instead of mapping and unmapping STREAMS
buffers on every send, the AM driver copies the data into a fixed, I/O addressable region. Given
the very fast (180MB/s) rate of the UltraSPARC memory system, this copy is not too expensive (20

s for a 3.5 KB fragment).
On receives, the medium message data area is only valid for the life of the handler. This
clashes with the STREAMS notion that a STREAMS message buffer exists in a single address space
of the kernel independent of any particular queue. Thus, in order to implement zero-copy receives,
the active message layer code would require modification to not free buffers upon return of control
from the handler. As with the send case, the effort needed to construct a zero-copy apparatus was
deemed not worth the added development time and risk.

---

34
0
0.2
0.4
0.6
0.8
1
0
10
20
30
40
50
60
70
80
90
Bulk Gap (usec/byte)
Ž
Delay (usec)
Bulk Gap Calibration for the TCP/IP apparatus
TCP/IP
Parallel
Figure 2.7: Calibration of bulk Gap for TCP/IP-GAM apparatus
This figure shows the empirical calibration for bulk Gap for the TCP/IP apparatus. The dependent
variable shows the added delay in

s per 100 bytes of packet size. The independent variable is the
Gap expressed in

s per byte (1/bandwidth). The figure shows the TCP/IP-GAM apparatus for ad-
justing bulk Gap is quite accurate. The basic parallel program apparatus calibration is shown as
well, demonstrating that the two systems are near equivalent as to Gap adjustment.
Calibration
Because the LCP of the TCP/IP-GAM apparatus is taken from the parallel programming
apparatus, we know that

and a network-limited
‘
are identical, so we do not measure those param-
eters again. However, unlike the parallel programming apparatus,
’
is substantially different. As can
be seen from Figure 2.6, there are many software components involved in sending a message; the
result is a large software overhead.
Since we know

, we can compute
’
from a simple round trip time. Measurements show
a mean RTT of 340

s. With

at 5

s we can deduce
’
as roughly 82

s. Unlike in user-space,
calibration of the delay loop inside the kernel can be tricky because many floating-point math rou-
tines are not supported in the kernel. Fortunately, the Solaris Device Driver Interface (DDI) contains
a time-calibrated spin loop,
drv usecwait
. It was intended for short waits to slow devices, but
serves as a calibrated spin-loop quite well.
We must re-calibrate
“
, because the increases in
’
may affect the range for which changes
to the LCP bulk data handling loop affect
“
. We use the same methodology as the parallel apparatus.
We cannot control the fragment sizes used by the kernel, however. Our gap experiment thus sends
a single large block of data (10 MB), with each write call sending 8KB at a time. The observed

---