Measurement Procedures and Testbed Configuration

A simple test was designed using a user level application that utilized the putpmsg() and getpmsg() system calls. In a default system, these are the only two system calls that allow a user level application to define priority band data. Therefore user application must use a protocol stack consisting only of the Stream head and the Ethernet driver. No intermediate processing modules can be used. This is because putpmsg() and getpmsg() make no sense in the context of Sockets or TLI. In order to conduct the priority test over a TCP/IP stack, the Sockets library would need to be modified to add a library function that defines a priority sendto() or write() function as well as their corresponding receive functions. In this manner, a user application could use Sockets to send and receive priority information from application level to application level.

Figure 5.2: This figure shows STREAMS stack used in the priority band tests.

The result of having a stripped down stack (Stream head and driver only) means there is little area for contention within any STREAMS queue (Figure 5.2). The Ethernet driver itself does not have a service procedure. Instead it simply calls canputnext() in order to pass the STREAMS message directly to the next processing module. In this case it happens to be the Stream head. Therefore, the Stream head is the only area for queue priority processing. The test results follow.