Initial tests were performed on the target machine using an unmodified 4.4-stable kernel while undergoing SYN flooding. The size of the listen socket backlog was varied from the default 128 entries to 1024 entries, as permitted by kern.ipc.somaxconn. The results of the test are presented in Figure 2.
In this test, with a backlog of 128 connections, 90% of the 2000 connections initiated to the target machine complete within 500ms. When the application specifies a backlog of 1024 connections in the listen() call, only 2.5% of the connections complete within the same time period.
The dropoff in performance here may be attributed to the fact that the sodropablereq() function does not scale. The goal of this function is to provide a random drop of incomplete connections from the listen queue, in order to insure fairness.
However, the queue is kept on a linear list, and in order to drop a random
element, a list traversal is required to reach the target element.
This means that on average, 
of the total length of the queue must be
traversed to reach the element; for a listen queue backlog of 1024 elements,
this leads to an average of
, or 768 elements
traversed for each incoming SYN.
Profiling results show that in this particular case, the system spends 30% of its time in sodropablereq(), and subjectively, is almost completely unresponsive. Examining the graph, we see that there is a considerable dropoff in performance between the backlog cases of 768 entries and 1024 entries, the reason of which is unclear. It is likely that there is a 'knee' in the performance curve is between these points, and system may have reached a point of saturation.
For the rest of the paper, a listen queue backlog of 1024 entries is used, as this is a realistic value used on production systems[4]. It also serves to illustrate the performance gains from a syncache or syncookie implementation.
