Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování (diskuse)

[Michal Kubeček]

Překládat "socket buffer" jako "vyrovnávací paměť soketů" je extrémně matoucí. A na ten "zásobník síťové vrstvy" už byl překladatel upozorněn dříve (možná i víc než jednou).

[Nikola Ciprich]

v překladu by se chybky našly, ale rozhodně se to lepší a jinak byl aspoň pro mně tento díl opravdu zajímavy.. dík!

[Václav HFechs Švirga]

+1

[Conscript89]

+1

[pet]

+1

Omlouvám se za to neoblíbené +1, ale překladatel (na rozdíl od mne) vládne angličtinou a má čas to překládat a já jsem mu za to vděčný a čas od času se to snažím dát najevo. Může si mé poděkování domyslet pod každým dílem kam je běžně nepíši. Díky.

[Petr Ježek]

Přesně tak. drobné chybky si většina z nás sama opraví a entropie může být zašlápnuta. Zaráží mne pouze, že se málokdo dosud zamýšlel nad režií na paket a zapomněl, proč se data v dřevních dobách posílala dávkově. Ignorance historie vede pouze k opakování starých známých chyb...

[Michal Kubeček]

Hlavní důvod je IMHO to, že problémy s výkonem se obvykle řeší až ve chvíli, kdy někoho začnou opravdu trápit. V situaci, kdy na svém počítači i s MTU 1500 a povypínaným LRO/GRO/TSO/GSO vytáhnu z netperfu 3.3 Gb/s a jakmile jedno z toho vrátím zpátky, tak ten 10Gb/s ethernet téměř nasytím, není až tak překvapivé, že dokud se 40Gb/s ethernet nestal realitou všedního dne (aspoň pro někoho) a 100Gb/s se neobjevil na horizontu, potřeba optimalizovat zpracování paketu "na krev" nebyla dost velká, aby vývojáři kvůli ní riskovali regrese.

[Jendа]

ale utrpěly pracovní zátěže, které jsou obzvláště citlivé na čekací doby

To je workload? Přeložil bych to jako typy zátěží.

[ncweohfnow]

A co nealokovat pamat vobec? Pristup ako pri http://fasterjava.blogspot.sk/2013/04/disruptor-example-udp-echo-service-with.html

[Bystroushaak]

Zajímalo by mě, proč není zamykání řešené přímo hardwarem. Když to žere docela dost prostředků, tak by bylo fajn mít pro to hardwarovou podporu, ne?

[Michal Kubeček]

K tomu by bylo potřeba si nejdřív ujasnit, o jakém zamykání je vlastně řeč. V tomto kontextu se mluví o atomických operacích a s tím souvisejícím LOCK (instrukčním) prefixem, což je hardwarová záležitost.

[Petr Ježek]

Následně je třeba si ujasnit, jaký kód má mít "vlastní židli" (být operačně atomický). Odhaduji, že takového kódu mnoho není a že jde o nezamýšlenou atomizaci. Ostatně nenárůst režie na dávku paketů oproti "single" dost jasně říká, kde hledat problém.

[Jendа]

Řešené je, ale řekl bych, že trvá, než to projde k ostatním jádrům a než si upraví cache(?).

[Snehuliak]

Preco konecne nezvysit MTU?

[Michal Kubeček]

MTU zvýšit můžete, koneckonců už většina gigabitových karet podporuje MTU přinejmenším 9000. Ale to řeší jen část problému. Jednak jsou tu featury typu TSO/GSO/LRO/GRO, díky kterým nemusí být zase až tak důležité, jak velké pakety běhají "po drátě", jednak ne zdaleka ne všechna komunikace je TCP přenos velkých datových bloků, je řada protokolů a aplikací, kde větší pakety stejně posílat nejde nebo to nemá smysl.

[Petr Ježek]

Protože to neřeší problém tam, kde vznikl.

[pc2005]

Páni 100Gb, kde jsou ty časy, když jsem rozběhával 115200kbps UART se SLIPem . BTW to se už skoro dá implementovat raw video-out over ethernet ne?

[Petr Tomášek]

záleží na rozlišení