Test for MHME Latency Improvements Using Priority Bands

A series of tests were then conducted using Application One (putpmsg()/getpmsg()) over a wide range of priority bands, in order to get an idea of whether the modified Ethernet Driver could improve performance for higher priority messages over the network. The latency results are shown in Table 5.3.

Table 5.3: This table shows the average application data (1000 bytes) RTT for a wide range of priority bands using the modified Fast Ethernet Driver MHME.

Priority Band Number	Application One Average RTT (microseconds)
1	82.19
2	82.01
20	82.32
40	82.60
50	83.12
60	82.87
80	88.54
100	95.22
120	100.42
140	99.69
160	103.62
180	106.27
200	109.07
255	117.98

These results show that by simply using band number 1 with the modified Fast Ethernet Driver (MHME), we see over a 550% latency improvement versus the standard unmodified Fast Ethernet Driver (HME). It is not clear whether the bulk of the improvement lies with the sender or the receiver. This would be difficult to test for. One can also see, that as we use subsequent bands, the cost grows. This is despite the fact that higher priority band numbers should take precedence over lower numbered bands. The reason for this lies in the lazy style data structure allocation which STREAMS adopts. If a message band has not been used, STREAMS does not allocate the data structures and queues associated with it. Recall that each priority band has a set of auxilliary data structures, and a separate queue. When a priority band is requested via a system call like putpmsg(), all structures and queues up to and including the one requested are allocated by the system. Thus, the cost is proportional to the band number. However, in a concurrent situation where two bands are competing to have their service routine empty their queues, the higher band number should always take precedence.