A fent említett kártyával lennének gondjaim.
Dual portos, ennek okán fogtam mind a 2 10GbE bekötöttem, egyik a "bejövő" másik a "kimenő" forgalomra.
Viszont jelenleg az a helyzet, hogy annyi se jön ki rajta mint az alaplapi Gbites kártyákon, ugyanis az közös IRQ kerül az 1 kártyán lévő 2 interfész és ez leöli a masinát.
Amennyiben kézzel átettem az egyik kártya IRQ-ját másik CPU-ra, akkor a másik kari is átment.
Esetleg ez valami ixgbe driver trükk, vagy pci-e sín beállítás, vagy merre induljak el ?
- 3858 megtekintés
Hozzászólások
ui: Még ami felmerült bennem, hogy a szerver jelenleg 1 8magos opteronnal üzemel, elképzelhető, hogy ez okozná a közös IRQ-t ?
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
ACPI be van kapcsolva?
Az elég gáz, ha a két port azonos IRQ-t használ, lévén, hogy tisztességes szerver NIC eleve multi-queue azaz, 1 port használ 4-8 IRQ-t...
- A hozzászóláshoz be kell jelentkezni
Be van. Amit mondasz az igaz. de mivel 2 portos eth0-eth1 így mindekttőn van 8-8 queue, viszont eddig úgy tűnik közös :/
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Nem abba a gépbe való ... ez valami relatíve régebbi szerver lehet.
- A hozzászóláshoz be kell jelentkezni
Az ok, hogy a hp dl165G7 es masina nem mai, de az intel X520-as kártya se a legujabb modell.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Mindenképpen bár most leállítottam a masinát, és meglesem egy másikkal. Tippem szerint ott ez sokkal jobban fog menni.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Itt lesznek:
Hozzáteszem, hogy pppoe szerver lenne.
interrupts:
44: 423948 0 0 0 0 0 0 0 IR-PCI-MSI 2621440-edge eth4-TxRx-0
45: 0 845 0 0 0 0 0 0 IR-PCI-MSI 2621441-edge eth4-TxRx-1
46: 0 0 1192 0 0 0 0 0 IR-PCI-MSI 2621442-edge eth4-TxRx-2
47: 0 0 0 910 0 0 0 0 IR-PCI-MSI 2621443-edge eth4-TxRx-3
48: 0 0 0 0 645 0 0 0 IR-PCI-MSI 2621444-edge eth4-TxRx-4
49: 0 0 0 0 0 519 0 0 IR-PCI-MSI 2621445-edge eth4-TxRx-5
50: 0 0 0 0 0 0 617 0 IR-PCI-MSI 2621446-edge eth4-TxRx-6
51: 0 0 0 0 0 0 0 815 IR-PCI-MSI 2621447-edge eth4-TxRx-7
52: 2 0 0 0 0 0 0 0 IR-PCI-MSI 2621448-edge eth4
64: 351366 0 0 0 0 0 0 0 IR-PCI-MSI 2623488-edge eth5-TxRx-0
65: 0 513 0 0 0 0 0 0 IR-PCI-MSI 2623489-edge eth5-TxRx-1
66: 0 0 555 0 0 0 0 0 IR-PCI-MSI 2623490-edge eth5-TxRx-2
67: 0 0 0 546 0 0 0 0 IR-PCI-MSI 2623491-edge eth5-TxRx-3
68: 0 0 0 0 497 0 0 0 IR-PCI-MSI 2623492-edge eth5-TxRx-4
69: 0 0 0 0 0 498 0 0 IR-PCI-MSI 2623493-edge eth5-TxRx-5
70: 0 0 0 0 0 0 490 0 IR-PCI-MSI 2623494-edge eth5-TxRx-6
71: 0 0 0 0 0 0 0 516 IR-PCI-MSI 2623495-edge eth5-TxRx-7
72: 2 0 0 0 0 0 0 0 IR-PCI-MSI 2623496-edge eth5
dmesg ixgbe
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-0.bpo.3-amd64 root=UUID=4e7f6988-77c2-4cc4-a22c-1462e38c75da ro ixgbe.allow_unsupported_sfp=1 quiet
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-0.bpo.3-amd64 root=UUID=4e7f6988-77c2-4cc4-a22c-1462e38c75da ro ixgbe.allow_unsupported_sfp=1 quiet
[ 2.041359] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 4.4.0-k
[ 2.041360] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
[ 2.060735] ixgbe 0000:05:00.0 0000:05:00.0 (uninitialized): WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 2.207977] ixgbe 0000:05:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8
[ 2.208108] ixgbe 0000:05:00.0: PCI Express bandwidth of 32GT/s available
[ 2.208110] ixgbe 0000:05:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
[ 2.208441] ixgbe 0000:05:00.0: MAC: 2, PHY: 17, SFP+: 5, PBA No: G28774-000
[ 2.208443] ixgbe 0000:05:00.0: a0:36:9f:10:2a:3c
[ 2.212438] ixgbe 0000:05:00.0: Intel(R) 10 Gigabit Network Connection
[ 2.372026] ixgbe 0000:05:00.1: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8
[ 2.372156] ixgbe 0000:05:00.1: PCI Express bandwidth of 32GT/s available
[ 2.372157] ixgbe 0000:05:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
[ 2.372489] ixgbe 0000:05:00.1: MAC: 2, PHY: 12, SFP+: 4, PBA No: G28774-000
[ 2.372490] ixgbe 0000:05:00.1: a0:36:9f:10:2a:3e
[ 2.376409] ixgbe 0000:05:00.1: Intel(R) 10 Gigabit Network Connection
[ 7.538918] ixgbe 0000:05:00.1 eth5: renamed from eth2
[ 7.610864] ixgbe 0000:05:00.0 rename2: renamed from eth0
[ 7.726796] ixgbe 0000:05:00.0 eth4: renamed from rename2
[ 9.237222] ixgbe 0000:05:00.0: registered PHC device on eth4
[ 9.351500] ixgbe 0000:05:00.0 eth4: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 9.410493] ixgbe 0000:05:00.0 eth4: detected SFP+: 5
[ 9.528487] ixgbe 0000:05:00.1: registered PHC device on eth5
[ 9.699735] ixgbe 0000:05:00.1 eth5: detected SFP+: 4
[ 9.700016] ixgbe 0000:05:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 11.518271] ixgbe 0000:05:00.1 eth5: NIC Link is Up 10 Gbps, Flow Control: RX/TX
dmesg ethX
[ 2.223515] igb 0000:04:00.0: added PHC on eth1
[ 2.223521] igb 0000:04:00.0: eth1: (PCIe:2.5Gb/s:Width x2) 68:b5:99:b6:b0:f6
[ 2.223525] igb 0000:04:00.0: eth1: PBA No: Unknown
[ 2.410114] igb 0000:04:00.1: added PHC on eth3
[ 2.410119] igb 0000:04:00.1: eth3: (PCIe:2.5Gb/s:Width x2) 68:b5:99:b6:b0:f7
[ 2.410122] igb 0000:04:00.1: eth3: PBA No: Unknown
[ 2.596107] igb 0000:03:00.0: added PHC on eth4
[ 2.596111] igb 0000:03:00.0: eth4: (PCIe:2.5Gb/s:Width x2) 68:b5:99:b6:b0:f0
[ 2.596114] igb 0000:03:00.0: eth4: PBA No: Unknown
[ 2.779454] igb 0000:03:00.1: added PHC on eth5
[ 2.779458] igb 0000:03:00.1: eth5: (PCIe:2.5Gb/s:Width x2) 68:b5:99:b6:b0:f1
[ 2.779461] igb 0000:03:00.1: eth5: PBA No: Unknown
[ 7.489479] igb 0000:03:00.1 rename7: renamed from eth5
[ 7.518888] systemd-udevd[280]: renamed network interface eth5 to rename7
[ 7.519015] igb 0000:04:00.1 rename5: renamed from eth3
[ 7.538838] systemd-udevd[273]: renamed network interface eth3 to rename5
[ 7.538918] ixgbe 0000:05:00.1 eth5: renamed from eth2
[ 7.566825] systemd-udevd[271]: renamed network interface eth2 to eth5
[ 7.566864] igb 0000:03:00.0 rename6: renamed from eth4
[ 7.594798] igb 0000:04:00.0 rename3: renamed from eth1
[ 7.594801] systemd-udevd[272]: renamed network interface eth4 to rename6
[ 7.610864] ixgbe 0000:05:00.0 rename2: renamed from eth0
[ 7.610884] systemd-udevd[269]: renamed network interface eth1 to rename3
[ 7.634834] igb 0000:03:00.1 eth3: renamed from rename7
[ 7.634859] systemd-udevd[270]: renamed network interface eth0 to rename2
[ 7.654736] igb 0000:04:00.1 eth1: renamed from rename5
[ 7.654760] systemd-udevd[280]: renamed network interface eth5 to eth3
[ 7.674791] igb 0000:03:00.0 eth2: renamed from rename6
[ 7.674818] systemd-udevd[273]: renamed network interface eth3 to eth1
[ 7.702792] igb 0000:04:00.0 eth0: renamed from rename3
[ 7.702825] systemd-udevd[272]: renamed network interface eth4 to eth2
[ 7.726796] ixgbe 0000:05:00.0 eth4: renamed from rename2
[ 7.726807] systemd-udevd[269]: renamed network interface eth1 to eth0
[ 7.742767] systemd-udevd[270]: renamed network interface eth0 to eth4
[ 9.237222] ixgbe 0000:05:00.0: registered PHC device on eth4
[ 9.343139] IPv6: ADDRCONF(NETDEV_UP): eth4: link is not ready
[ 9.351500] ixgbe 0000:05:00.0 eth4: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 9.410493] ixgbe 0000:05:00.0 eth4: detected SFP+: 5
[ 9.528487] ixgbe 0000:05:00.1: registered PHC device on eth5
[ 9.634993] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready
[ 9.699735] ixgbe 0000:05:00.1 eth5: detected SFP+: 4
[ 9.700016] ixgbe 0000:05:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 9.700063] IPv6: ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready
[ 9.724082] 8021q: adding VLAN 0 to HW filter on device eth4
[ 9.724140] 8021q: adding VLAN 0 to HW filter on device eth5
[ 11.518271] ixgbe 0000:05:00.1 eth5: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 11.518435] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready
[ 572.615646] device eth5 entered promiscuous mode
[ 594.921177] device eth5 left promiscuous mode
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
az IRQ része nekem jónak tűnik (minden Queue külön IRQ-n ül) a másik részéről nem tudok nyilatkozni.
- A hozzászóláshoz be kell jelentkezni
Hát nekem pont, hogy nem, ugyanis ha megnézed ugyanazon a CPUn-n ül mindkét kártya queue-ja, látszik is azon a 2-n van a legnagyobb szám.
És mivel egyik bejövő másik kimenő ez így gáz.
Persze lehet én gondolom rosszul.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
én arra tippelek, hogy jelenleg nincs elég forgalom a rendes IRQbalance-hoz.
nálam ez kb így néz ki (1G adapterrel):
CPU0 CPU1 CPU2 CPU3
0: 1687546201 1689050352 1688188551 1688504187 IO-APIC-edge timer
64: 21092845 20979169 21004913 21140248 PCI-MSI-edge cciss0
68: 2038021832 2039664200 2039932115 2038897903 PCI-MSI-edge eth3
69: 430478184 523609722 613999477 518104624 PCI-MSI-edge eth2
70: 1564466799 1493024009 1438770587 1510392480 PCI-MSI-edge eth1
71: 1947709561 1923138495 1887506224 1912267220 PCI-MSI-edge eth0
- A hozzászóláshoz be kell jelentkezni
Az a vicces, hogy emlékeim szerint 2x1Gbiten jobb volt, mint most a 10GbE interfacen. Ha más nem holnap visszarakom a 2x1Gbitet és meglesem azzal ismét.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Hacsak, nem ez lesz a gond:
iperf egyik irányban:
[ 3] 0.0- 5.0 sec 1.46 GBytes 2.51 Gbits/sec
[ 3] 5.0-10.0 sec 1.47 GBytes 2.52 Gbits/sec
[ 3] 10.0-15.0 sec 1.47 GBytes 2.52 Gbits/sec
míg a dmesgnél ugye:
[ 2.406370] igb 0000:04:00.1: Intel(R) Gigabit Ethernet Network Connection
[ 2.406372] igb 0000:04:00.1: eth3: (PCIe:2.5Gb/s:Width x2) 68:b5:99:b6:b0:f7
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
no igen.
Akartam kérdezni, hogy hogyan van az, hogy az egyik port az eth1-eth4 és darabonként 2.5gbps...
- A hozzászóláshoz be kell jelentkezni
igen, az x2 slot keves lesz ehhez...
- A hozzászóláshoz be kell jelentkezni
ixgbe.allow_unsupported_sfp=1 quiet ??
Ez mire jó?
- A hozzászóláshoz be kell jelentkezni
Amit a neve is mondd, unsopported SFP modulokra. Mint pl a mikrotik :D intel drivernel van pár modell amit hivatalosan támogat, ha neked nem olyan modulod van akkor ezzel lehet próbálkozni.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Köszi
- A hozzászóláshoz be kell jelentkezni
cisco-ra forditva:
ena
conf t
service enable unsupported-sfp
vagy valami ilyesmi volt cisco-n is. eleg hasonlo nevvel. Hivatalos doksiban meg sem emlitve, de kis guglizassal megtalalhato :D
Mi is hasznaltunk ibm sfp-ket cisco-ban, mert gyakorlatilag egy marek aproert megkaptuk oket :)
- A hozzászóláshoz be kell jelentkezni
Hasznos info! Köszi!
- A hozzászóláshoz be kell jelentkezni
Érdekes probléma, feliratkozom.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Nekem az egesz leirasbol egy valami hianyzik nagyon:
A "nem jon ki annyi", na azt hogy mered? Mivel?
Jo lenne tisztazni mire lovunk.
- A hozzászóláshoz be kell jelentkezni
nem tűnik nagy találmánynak, de az iperf pont erre való
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Egy pppoe koncentrátor lenne. Jelenleg 1 db klienssel.
Ezenkívül van még egy másik szerver ami szintén 10GbE-n lóg. E két gép között megy az iperf.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Igen. Es ahol ideztel is teszt eredmenyeket, ott kijott 2.5Gbit/sec.
Az mar alaphangon tobb, mint amit egy gigabites interface-n ki tudsz hajtani, ergo... akkor hogy jott ki a nem jott ki annyi?
Leosztod meg a szamot a kartya nevleges elmeleti maximum sebessegevel, vagy milyen metrika menten nem jon ki?
- A hozzászóláshoz be kell jelentkezni
Olyan metrika mentén, hogy 10GbE full duplex a maximum elméleti sávszélesség, ebből 1500MTU-val 8Gbit full duplex simán kijön, pppoe-n meg 2-2.5 egy irányban.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Szoval van egy meresed, ahol 2.5Gbit kijott.
Akkor az megsem igaz, hogy gyengebb mint a Gbit-es kapcsolat.
Csak a szintetikus meresed nem hoz olyan savszelesseget, mint azt te szeretned / varod.
Szerk.: Bónuszkérdés: A te mérésed metodikája mennyire van szinkronban avval ahogyan a gyakorlatban lesz használva a doboz?
- A hozzászóláshoz be kell jelentkezni
Kb sehogy, azért még nem osztogatnak gigabiteket pppoe-n viszont valahogy tudni kell, hogy mennyit lehet kihozni, hol fogy el a masina. Könyebb mint mondjuk 2000 pppoe sessionnel tesztelni. Persze az is jó lenne.
Amúgy ma betettem egy erősebb gépet, azzal már jóval jobb sebesség jött ki.
Esetleg valami tipp/program hogyan lehetne szimulálni vagy 2000 kapcsolatot ?
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Na pont erre akartam utalni!
Hogy ha neked a "use-case"-d az, hogy sok parhuzamos pppoe sessionod lesz, es nem ket gep kozott akarsz pppoe-n kihajtani 10GE-t, akkor azt kellene lemerni.
Csak assumption, de az a tippem, hogy mivel ekkora sebessegnel mar a 10GE az a max throughput, de 1 szimpla pppoe-nel mar gyakorlatilag ethernet keretek kerulnek be a kartya pufferebe, osszegyulnek, majd ami befert, reagal ra. Pontosan nem ismerem a pppoe lelkivilagat, de az a gyanum, hogy pont ezt nem viseli jol.
TCP-nel pl. ugye a window size-t lehet novelni, meg vannak hasonlo trukkok arra az esetre ha nem akarsz minden egyes csomag utan ack-ot.
Itt kicsit mas a jatek.
A tobb kapcsolat tesztelesere hint:
xen, vagy vmware, (uram bocsa: virtualbox) vagy barmi olyan virtualizacios megoldas, aminel a provision-t egyszeruen le tudod scriptelni es egy for-ciklusbol tudsz csinalni sok gepet.
Akar valami buta alpine linux is lehet a vm-edben. Az tud ramdisk-bol futni, es amit boot-kor betolt tar.gz fajlt, ahol a perzisztenciat tartja... Azt meg le lehet szinten generalni a forciklusbol, ha kell valami elteres a vm-ek kozt. Raadasul eleg picire van vagva az eroforrasigenye, szoval ha van par giga memoriad egyik felol, es nem kell tul sok minden az alpine ramdiskjere (marpedig ott konnyetes hogy nem utolag kell kiherelni, hanem eleve rendesen herelve van), akkor konnyen belefer sok ilyen vm egy nagy fizikai vas-ra.
Ezt az egyik oldalon a teszteleshez megleped. A virt gepek mehetnek mind bridge-lve a kartyara. Bar ha nem akarsz 2000 gepet emulalni, csak mondjuk 60 eleg, akkor ennel a kartyanal ha jol remlik 64vf-et tudsz egy pf-re csinalni: minden vm-nek adsz pci-passthrough-val egy komplett vf-et az interface-rol.
Aztan egyszerre hajtod meg mind a 60 vm-bol az iperfet.
Vagy az is eleg, ha curl-el elkezdik letolteni a /dev/zero-t a szerveredrol, a szerver oldalon meg nezed a forgalmat, vagy az egyes pppoe session-ok tx/rx countereit, vegul az idovel normal kulonbsegeket osszegzed es maris van egy szep szamod arrol hogy szumma mekkora forgalmat hajtottal at.
Vica versa is lehet hasonlot: minden vm (pppoe kliens) indit egy iperf szervert is onmagan. A pppoe szerver oldalan meg script figyeli a logokat, ha bejott egy kliens, akkor az O ip-je fele inditasz egy iperf klienst a pppoe szerver felol, hogy vissziranyban is meg legyen hajtva.
Vannak itt remek legokockak, csak ossze kell rakni! ;)
- A hozzászóláshoz be kell jelentkezni
Nálam ugyan ez volt, a gyári xgbe driver helyett forgass frissebbet kézzel. Macera, meg minden, de nálam ez volt a megoldás
szerk.: közben megnéztem, az irq/interrupt ugyan az nálunk mint nálad, próbáld meg a stock xgbe driver helyett a kézit (ha kell, csináltam dkms-t belőle)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
+1 mindnekepp probald ki a gyari intel drivert a kerneles helyett.
ugyan nalunk X710 van, de a kernel driverrel meg a vlan kezeles is bugos volt, es random megallt a forgalom. az inteltol letoltheto driver forrasa nem is hasonlit a kernelben levore (a kerneles valami sok sok evvel ezelotti fork azota random patchelgetve).
- A hozzászóláshoz be kell jelentkezni
Hát meglesem, bár modinfo szerint 4.4
filename: /lib/modules/4.9.0-0.bpo.3-amd64/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
version: 4.4.0-k
Intel oldalán 5.1.3 van, meglesem azzal majd.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
meg a kartyan sem art egy firmware update
- A hozzászóláshoz be kell jelentkezni
Közben megtaláltam és megnéztem a régi mérések eredményét:
A két sfp+ porton párhuzamosan futtatva mindkettőre 9.9 -et mértem sebességre (jumbo frame + vlan)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Egyelőre úgy tűnik, hogy pppoe val tud ennyit a vas, sima ethernettel kijön 7-8Gbit full duplexben, 1500 MTU-val.
Szóval azon kell tákolni hogy pppoe-val is közelítse ezt az értéket.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
kernelben van pppoe support vagy userspace megy teljesen? pppd forditasnal asszem default hogy nem a kernelet hasznalja
- A hozzászóláshoz be kell jelentkezni
Az in-kernel PPPoE használatához az rp-pppoe.so modult kell betölteni a pppd-be.
A userspace-only PPPoE alig párszáz megabitet tud egy Core i5 vason is. A kernelben lévő PPPoE egy másik liga, de szerintem azzal sem nagyon fogsz tudni kitolni 10 gigabitet, legfeljebb, valami erőművön. Nem tudom, hogy mennyire skálázódik szét CPU magokra... ha egy szálon fut, akkor jönnek a hattyúk. (Hogy milyen hattyúk? Hát, a basz...)
- A hozzászóláshoz be kell jelentkezni
Mint irtam fentebb is, nekem olyan 5-600mbit jött ki roaringos pppoe val.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
rp-pppoe.so betoltve log szerint, kernel modul még sincsen használatban.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Nahh sikerült belőni a kernel modot, ugyanakkora sebesség jött ki mint az accel-ppp vel.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Ez userspace, orosz accel-ppp fejlesztés, egyelőre jóval jobb mint a régi roaringos pppoe.
Azzal kezdtem, hogy gigabiten a roaringos pppoe teszteltem alig jött ki 5-600mbit és a pppoe szerver process 100% on tekert, míg az accel-ppp vel 0% volt a cpu terhelés.
Amennyiben jól tudom a mikrotik is áttért már erre az accel-ppp re.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
pedig ezt irjak itt https://accel-ppp.org/
All PPTP, PPPoE, L2TP tunnels are kernel-mode so don't produce system overhead like user-space mode tunnels.
- A hozzászóláshoz be kell jelentkezni
Jól mondja, mert most csak sikerült összedobni a rp-pppoe-t kernel modullal, de ugyanannyi sebesség jön ki mint az accel-ppp vel.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
ahha, szóval eleve ezzel kezdted a tesztelést, Te kis hamis :-)
- A hozzászóláshoz be kell jelentkezni
Igen, kezdhettem volna ezzel, bár sejtettem, hogy fog menni ugyanis már régi hp microserveren ment ennyi.
Gigabiten kb 0% volt a cpu terhelés pppoe szerverként, ~ full duplex gigabites forgalomnál. Ebből gondoltam, hogy akkor 10GbE se lehet olyan nagy gond, aztán meg is lepődtem, hogy alig pár Gbitet tudtam kisajtolni.
A mikroik PC-n már felejtős, egyrész 10Gbit-es kártya se van hozzá, és még a gigabit is alig jött ki, 70% cpu használat mellett. Míg 36 magos CCR nél nem volt nagy cpu terhelés. Meglestem 10GbE -n is a CCR-t de ott is pár Gbit jött ki aggregálva. talán 3/1 vagy ilyesmi.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Amúgy a kártya rendbe megy amúgy a HP-ba? (sima tcp, 9k-s mtu-val hozza amit kell?)
- A hozzászóláshoz be kell jelentkezni
Szerintem igen, ugyanis 1500-as MTU-val routolva (a routeren már forgalom) 7-8Gbit kijött belőle.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Azert a 7-8Gbit kicsit sovanynak tunik nekem 1500-as mtu-val is.
Driver/firmware friss, ethtool -i szerint azokat hasznalja?
interrupt elosztas kezzel vagy irqbalance-al van?
Ez most rez vagy optika, interface error-ok nincsenek?
iperf3-al mered?
- A hozzászóláshoz be kell jelentkezni
iperf en merem, plusz a routeren amin at van routeolva a 10GbE van forgalom. SFP+ hol optika hol direct attach cable.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Kartya 2 portja kozott kijon a normalis sebesseg, hogy kizarjuk a mogottes eszkozok kepesseget?
Nem veletlenul kerdeztem iperf3-t, sima iperf 10G-nel mar erosen kuszkodik.
- A hozzászóláshoz be kell jelentkezni
Sima iperf-et több szálon is el tudod indítani. Nekem 100 giga méréshez jobban bevállt, mint az iperf3.
- A hozzászóláshoz be kell jelentkezni
100G-t meg nem volt szerencsem tesztelni, 10G-n sima iperf-el tobb szalon inditva is erzodott a kuzdes, mig iperf3 alapbol hozta az erteket. De lehet csak valami bug-ot fogtam ki amit azota javitottak, nem neztem alaposabban mert iperf3 megoldotta a gondot nalam.
- A hozzászóláshoz be kell jelentkezni
UDP-val is átmegy ennyi? latency milyen?
- A hozzászóláshoz be kell jelentkezni
Jelenleg így néz ki az interrupts tábla:
28: 21755129 0 1 0 0 0 0 0 PCI-MSI 3145728-edge eth4-TxRx-0
29: 0 42769 1 0 0 0 0 0 PCI-MSI 3145729-edge eth4-TxRx-1
30: 0 0 42843 0 0 0 0 0 PCI-MSI 3145730-edge eth4-TxRx-2
31: 0 0 1 43124 0 0 0 0 PCI-MSI 3145731-edge eth4-TxRx-3
32: 0 0 1 0 44857 0 0 0 PCI-MSI 3145732-edge eth4-TxRx-4
33: 0 0 1 0 0 42778 0 0 PCI-MSI 3145733-edge eth4-TxRx-5
34: 0 0 1 0 0 0 47058 0 PCI-MSI 3145734-edge eth4-TxRx-6
35: 0 0 0 0 0 0 1 42772 PCI-MSI 3145735-edge eth4-TxRx-7
36: 5 0 0 0 0 0 1 2 PCI-MSI 3145736-edge eth4
37: 21662629 0 0 0 0 0 1 0 PCI-MSI 3147776-edge eth5-TxRx-0
38: 0 43945 1 0 0 0 0 0 PCI-MSI 3147777-edge eth5-TxRx-1
39: 0 0 43620 0 0 0 0 0 PCI-MSI 3147778-edge eth5-TxRx-2
40: 0 0 1 43749 0 0 0 0 PCI-MSI 3147779-edge eth5-TxRx-3
41: 0 0 1 0 48220 0 0 0 PCI-MSI 3147780-edge eth5-TxRx-4
42: 0 0 1 0 0 43668 0 0 PCI-MSI 3147781-edge eth5-TxRx-5
43: 0 0 1 0 0 0 43629 0 PCI-MSI 3147782-edge eth5-TxRx-6
44: 0 0 1 0 0 0 0 43717 PCI-MSI 3147783-edge eth5-TxRx-7
45: 1 0 0 1 0 0 0 0 PCI-MSI 3147784-edge eth5
Azt honnan lehet tudni, hogy miért csak a txrx-0 valamint a hozzá tartozó cpu-0 dolgozik ?
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Folyamatos(an nagy) forgalom van? El tudom képzelni, hogy csak nagyobb terhelésnél indul be a round robin mechanizmus,
vagy kezd működni a multiqueue.
- A hozzászóláshoz be kell jelentkezni
Persze, most kézzel kicsit mahinálva az smp_affinity-t mintha jobb lenne. Viszont megint elértem egy bűvös határt, akárhogy csűröm csavarom, csakis ~5 Gbit jön ki aggregálva. PPPoE -n keresztül.
Olyan mintha pppoe-s ifacen csak 400e pps-t tudna feldolgozni.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
top mit mutat? Lehet, hogy egy szálon tud csak futni a ppp kód, ami elég CPU igényes (https://hup.hu/node/144314#comment-1940780), és ott lesz a szűk keresztmetszet.
- A hozzászóláshoz be kell jelentkezni
lspci -s 05:00.0 -vvv kimenet (vagy ha masik slotban van a kartya akkor arra nezve)?
- A hozzászóláshoz be kell jelentkezni
06:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01)
Subsystem: Intel Corporation 10GbE 2P X520 Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f7900000 (64-bit, non-prefetchable) [=1M]
Region 2: I/O ports at d020 [=32]
Region 4: Memory at f7b04000 (64-bit, non-prefetchable) [=16K]
Expansion ROM at f7a80000 [disabled] [=512K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00002000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend+
LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM L0s, Exit Latency L0s unlimited, L1 <8us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [e0] Vital Product Data
Product Name: X520 10GbE Controller
Read-only fields:
[PN] Part number: G73129
[MN] Manufacture ID: 31 30 32 38
[V0] Vendor specific: FFV16.0.24
[V1] Vendor specific: DSV1028VPDR.VER1.0
[V3] Vendor specific: DTINIC
[V4] Vendor specific: DCM10010081D521010081D5
[V5] Vendor specific: NPY2
[V6] Vendor specific: PMT12345678
[V7] Vendor specific: NMVIntel Corp
[RV] Reserved: checksum good, 3 byte(s) reserved
End
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-00-ff-ff-00-00-00
Capabilities: [150 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 1
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
IOVCap: Migration-, Interrupt Message Number: 000
IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
IOVSta: Migration-
Initial VFs: 64, Total VFs: 64, Number of VFs: 0, Function Dependency Link: 00
VF offset: 384, stride: 2, Device ID: 10ed
Supported Page Size: 00000553, System Page Size: 00000001
Region 0: Memory at 00000000df200000 (64-bit, prefetchable)
Region 3: Memory at 00000000df300000 (64-bit, prefetchable)
VF Migration: offset: 00000000, BIR: 0
Kernel driver in use: ixgbe
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
LnkCap: Port #0, Speed 5GT/s, Width x8
vs
LnkSta: Speed 5GT/s, Width x2
Mintha nem tudna a foglalat amit szeretne a kartya.
- A hozzászóláshoz be kell jelentkezni
Igen először én is ezt hittem, aztán teszteltem iperf-el és ethernettel kijött a 8-9Gbit full duplexben. PPPoE val meg aggregálva 5Gbit.
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Egyszerre a 2 porton vagy a kartya 2 portjat osszekotve egyikrol a masikra kuldve is tudja iperf-el azt a 8-9Gbit-et portonkent?
Csak mert pcie 2.0 x8 a 2 portos kartyaval full duplexben 40Gbps-t kell hogy elbirjon ha helyette 1 porton 1 iranyban tudja a kozel 10G-t arra eleg lehet az x2, de ha pl ugyanakkor pppoe-vel mar atmeno forgalmat generalsz mindket portot hasznalva akkor ez siman felezett savszelbe ferhet bele max.
- A hozzászóláshoz be kell jelentkezni
Most leteszteltem, hogy a kártya 2 portján mennyit tudok átroutolni, és sajna 5Gbit/sec jön ki aggregálva.
Folytatom a teszteket 2db kártyával és nem 1db 2 portossal :/
Fedora 25, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni