The syncache tests were performed on the target machine by enabling the following sysctl
[fontfamily=tt, fontsize=\footnotesize]
net.inet.tcp.syncookies
and then performing the tests in the usual fashion. The results of the test are presented in Figure 4.
The results show that syncookies provides slightly better performance than syncache alone. This may be due to the fact that the syncache calls arc4random() for every SYN,ACK it sends, while the syncookie routines primarily call MD5(). Investigation into the reason for the performance disparity is ongoing, but the results are not available at this time.
There are also a few unusual results here: There does not appear to be a straightforward explanation for the jump in completed connections at 700 microseconds. This is not due to TCP retransmissions, as the first retransmission timeout is set at one second. A possible explanation is that the system is busy executing the interrupt handler for either of the Gigabit adapters, and is delayed in servicing the 100Mb adapter.
Also of interest to note is that while 100% of the syncache connections have completed in 1 second, the same isn't true for syncookies. This shouldn't happen, as no packet loss on the 100Mb segment was observed, and the system did not run out of mbufs. Upon further investigation, this turned out to be a minor bug in the VM system where the initial boot-time allocation request was rounded improperly, leading to a shortage of syncache structure entries. With the current code, at least one entry is always needed in order to send the SYN,ACK reply.