Porovnání propustnosti NATu mezi Linuxem a pfSense/FreeBSD
Napsal: 11 Apr 2016 14:08
Ahoj,
jako v minulém příspěvku (Porovnání propustnosti NATu mezi Linuxem a MiktoTik RouterOS) jsem provedl měření propustnosti implementace NATu na Linuxu (Debian 8.3, kernel 4.3.0), pfSense 2.2.6 (založen na FreeBSD 10.1) a FreeBSD 10.2. Oproti minulému případu, kdy jsem musel kvůli technickým potížím použít starší stroj, nyní používám nejlepší počítač, který mám k dispozici. Konkrétně se jedná o počítač s procesorem Intel Core i7 6700 @ 3.40 GHz, 2x8 GB RAM DDR4, základní deska ASUS Z170I PRO GAMING a síťová karta stejně jako minule Intel Ethernet Server Adapter X520-DA2.
Každý testovaný OS byl nastaven tak, aby každé jádro mělo přístup ke "své" frontě paketů na síťovém adaptéru. Stejně jako minule jsem použil NAT 1:M (PAT) a generoval provoz s 10 000 UDP toky s pakty o velikosti 128 B. Výsledky jsou na grafech níže (osa X je počet generovaných paketů, osa Y je počet paketů zpracovaných NATem, hodnoty jsou v milionech paketů za sekundu).
pfSense 2.2.6:
FreeBSD 10.2:
Linux Debian 8.3, kernel 4.3.0:
Maximální propustnost pfSense a FreeBSD je prakticky stejná a pohybuje se kolem 1,2 milionů paketů za sekundu. Oproti tomu Linux zvládá odbavit až 4 miliony paketů za sekundu. Toto měření opět ukazuje, že Linux má velmi dobře implementovaný NAT.
Možná některé zarazilo, proč jsem nepoužil výchozí kernel dodávaný s Debianem. Důvod je takový, že spojení Linux verze 3.16 (+patche od Debianu) a procesoru Intel i7 Skylake se objevil zákeřný problém. Po nastavení pravidel pro NAT a následném spuštění generátoru provozu operační systém skončil s kernel panic. Stack trace vedl do funkcí spojených se souborovým systémem, tak jsem pro jistotu vyměnil celý disk a provedl čistou instalaci Debianu. Jenže i po tomto zásahu se projevoval stejný problém. Vzhledem k tomu, že řada procesorů Skylake je poměrně nová a jádro 3.16 poměrně staré (srpen 2014), tak jsem zkusil nasadit jádro 4.3.0. Po zvýšení verze kernelu se problém přestal projevovat.
Na základě výše uvedeného problému mě napadá provést měření na kernelu 3.16 a 4.3 a zjistit jak moc se liší propustnost. To však znamená připravit další stroj, kde budou fungovat obě verze kernelu, takže výsledky budou v dalším příspěvku.
jako v minulém příspěvku (Porovnání propustnosti NATu mezi Linuxem a MiktoTik RouterOS) jsem provedl měření propustnosti implementace NATu na Linuxu (Debian 8.3, kernel 4.3.0), pfSense 2.2.6 (založen na FreeBSD 10.1) a FreeBSD 10.2. Oproti minulému případu, kdy jsem musel kvůli technickým potížím použít starší stroj, nyní používám nejlepší počítač, který mám k dispozici. Konkrétně se jedná o počítač s procesorem Intel Core i7 6700 @ 3.40 GHz, 2x8 GB RAM DDR4, základní deska ASUS Z170I PRO GAMING a síťová karta stejně jako minule Intel Ethernet Server Adapter X520-DA2.
Každý testovaný OS byl nastaven tak, aby každé jádro mělo přístup ke "své" frontě paketů na síťovém adaptéru. Stejně jako minule jsem použil NAT 1:M (PAT) a generoval provoz s 10 000 UDP toky s pakty o velikosti 128 B. Výsledky jsou na grafech níže (osa X je počet generovaných paketů, osa Y je počet paketů zpracovaných NATem, hodnoty jsou v milionech paketů za sekundu).
pfSense 2.2.6:
FreeBSD 10.2:
Linux Debian 8.3, kernel 4.3.0:
Maximální propustnost pfSense a FreeBSD je prakticky stejná a pohybuje se kolem 1,2 milionů paketů za sekundu. Oproti tomu Linux zvládá odbavit až 4 miliony paketů za sekundu. Toto měření opět ukazuje, že Linux má velmi dobře implementovaný NAT.
Možná některé zarazilo, proč jsem nepoužil výchozí kernel dodávaný s Debianem. Důvod je takový, že spojení Linux verze 3.16 (+patche od Debianu) a procesoru Intel i7 Skylake se objevil zákeřný problém. Po nastavení pravidel pro NAT a následném spuštění generátoru provozu operační systém skončil s kernel panic. Stack trace vedl do funkcí spojených se souborovým systémem, tak jsem pro jistotu vyměnil celý disk a provedl čistou instalaci Debianu. Jenže i po tomto zásahu se projevoval stejný problém. Vzhledem k tomu, že řada procesorů Skylake je poměrně nová a jádro 3.16 poměrně staré (srpen 2014), tak jsem zkusil nasadit jádro 4.3.0. Po zvýšení verze kernelu se problém přestal projevovat.
Na základě výše uvedeného problému mě napadá provést měření na kernelu 3.16 a 4.3 a zjistit jak moc se liší propustnost. To však znamená připravit další stroj, kde budou fungovat obě verze kernelu, takže výsledky budou v dalším příspěvku.