On 2 Oct 2014 at 18:15, Andy wrote: > Setup some queues and prioritise your ACK's ;) > > The box is fine under the load I'm sure, but you'll still need to > prioritise those TCP acknowledgments to make things snappy when lots of > traffic is going on..
All these (otherwise valid) suggestions are useless until we know more about the specific firewall in question -- information best delivered in the form of dmesg, 'pfctl -si' output and other statistics as indicated in Ville's response below. I recently struggled with a very similar problem until I noticed that the total number of states reported in pftop was "stuck" at 10,000 ... guess what? that is a default limit and (also by default) stateless traffic is *dropped*! Raising that particular limit _magically_ tripled the throughput. -Jacob. > > On 02/10/14 17:13, Ville Valkonen wrote: > > Hello Patrick, > > > > On 2 October 2014 17:32, Patrick <jum...@yahoo.de> wrote: > >> Hi, > >> > >> I use a OpenBSD based firewall (version 5.2, I know I should upgrade > >> but ...) between a 8 host cluster of Linux server and 300 clients > >> which will access this clutser via VNC. Each server is connected with > >> one gigabit port to a dedicated switch and the firewall has on each > >> site one gigabit (dedicated switch and campus network). > >> > >> The users complains about slow VNC response times (if I connect a > >> client system to the dedicated switch, the access is faster, even > >> during peak hours), and the admins of the cluster blame my firewall > >> :(. > >> > >> I use MRTG for traffic monitoring (data retrieves from OpenBSD in one > >> minute interval) and can see average traffic of 160 Mbit/s during > >> office hours and peaks and 280 Mbit/s. With bwm-ng and a five second > >> interval I can see peaks and 580 Mbit/s. The peak packets per second > >> is arround 80000 packets (also measured with bwm-ng). The interrupt > >> of CPU0 is in peak 25%. So with this data I don't think the firewall > >> is at the limit, I'm right? > >> > >> The server is a standard Intel Xeon (E3-1220V2, 4 Cores, 3.10 GHz) > >> with 4 GByte of memory and 4 1 Gbit/s ethernet cooper Intel nics > >> (driver em). > >> > >> Where is the problem? Can't the nics handle more packets/second? How > >> can I check for this? > >> > >> If I connect a client system directly to the dedicated system, the > >> response times are better. > >> > >> Thanks for your help, > >> Patrick > > In addition to dmesg, could you please provide the following > > information: $ pfctl -si $ sysctl kern.netlivelocks and interrupt > > statistics (by systat for example) would be helpful. > > > > Thanks! > > > > -- > > Regards, > > Ville
