DIY-router, D2500CCE

Troligen så kommer du få ut bättre prestanda ur en linuxbaserad brandvägg istället för en som är baserad på FreeBSD.

Nätverksstacken i FreeBSD är tyvärr inte helt optimal längre.

Kan rekomendera dig att testa IPFire. Ganska trevlig. Utan tvekan den bäst presterande brandväggen jag har testat. Körde pfSense förr, men bytt ut den nu.

Ett annat stort plus är att IPFire har stöd för snort out of box. Även jättebra stöd för ESXi.

Mvh
Mattias

Troligen så kommer du få ut bättre prestanda ur en linuxbaserad brandvägg istället för en som är baserad på FreeBSD.

Nätverksstacken i FreeBSD är tyvärr inte helt optimal längre.

Kan rekomendera dig att testa IPFire. Ganska trevlig. Utan tvekan den bäst presterande brandväggen jag har testat. Körde pfSense förr, men bytt ut den nu.

Ett annat stort plus är att IPFire har stöd för snort out of box. Även jättebra stöd för ESXi.

Mvh
Mattias

A lot of sysadmins from companies that push a lot of data over lots of connections have blogs about tweaking your OS to handle stuff like 10gb+ of traffic and millions of connections. A lot of these people complain about Linux having strange problems under these loads, and FreeBSD just seems to work. Linux may be faster in some cases, but it still has stability issues that are hard to debug.

Then there's the whole thing about most network stack research happening primarily on FreeBSD because of licensing. There's a new zero-copy network API that was developed in FreeBSD that allows line rate 64byte 10gb traffic on a 450mhz quadcore cpu. Linux and old-api FreeBSD were about 1/10th the packets-per-second.

A new thread friendly socket API has just been pushed to FreeBSD 11. One of Netflix' engineers had a pet project that now allows near zero lock-contention thread scaling. He was able to done line speed 40gb/s with 150k TCP sessions. Instead of having one file descriptor with a single listening thread, you instead have one file-descriptor and listening thread per MSS queue from the NIC and you can lock your thread to the same CPU as the MSS queue, so the packet is already in L2 cache. No shared network state. This also means no share locks with nearly perfect linear scaling and virtually no cache trashing or bouncing.

They're starting work for extend the API to also allow the OS to better handle NUMA and to attach the MSS queues to the CPU to which the NIC is attached. This will virtually remove all cross-talk among the CPU cores trying to handle the network state.

They're looking into expanding this same concept to the Storage IO system.

FreeBSD is better on the network stack. I should know since I coded a networking library to use the best possible non-blocking mechanism on various OSes.

Just for a specific comparison, freeBSD has kQueue where Linux has epoll mechanism. Both are replacements for the ancient select call which is extremely inefficient when there's a huge amount of connections (see C10k problem).

kQueue is very smart in how it reports events happening on sockets and gives you the full list of "read" and "write" events in one go. That means one syscall/gateway per report batch in a scheduled slice.

epoll on the other hand can only report reads or writes in one syscall/gateway. The way to have "one" event reporting point with epoll is to epoll two epolls on top one for reads one for writes, which means it can go up to 3 syscalls. That IS 3x slower on linux, I have tested this.

This is just one part of the problem, I'm guessing they have other, deeper issues. I think it'd help if fanboys who know nothing of the systems stopped being so defensive.

Om man vil ha absolutt best ytelse så programmerer man logikken i berkeley packet filter (BPF).

BPF blir JITet i linux-kjernen og det finnes instruksjonsextensions for å route pakken til en spesifikk nettverkskø.

Bruker man denne teknikken så kommer pakken aldri til user-land.

Haha, vilken jävla gojja.

http://bsd.slashdot.org/story/14/08/06/1731218/facebook-seeks...

Vidare är pf typ en triljard gånger bättre än iptables från 80-talet.

Lite fördjupning:

Fina citat dock saknar dom källa.

Dom ser ut att komma härifrån
http://www.reddit.com/r/linux/comments/2d5wzg/linux_network_stack/

Om man vil ha absolutt best ytelse så programmerer man logikken i berkeley packet filter (BPF).

BPF blir JITet i linux-kjernen og det finnes instruksjonsextensions for å route pakken til en spesifikk nettverkskø.

Bruker man denne teknikken så kommer pakken aldri til user-land.