Puncte:0

Cum să îmbunătățești toleranța TCP la livrarea în afara ordinului în obligațiunile Linux balance-rr și/sau în decalajele roundrobin FreeBSD?

drapel cn

Am 3 servere în funcție de rețea configurate după cum urmează

  • A este un DELL R710 care rulează Linux 5.13.19-1-pve Proxmox VE 7.1 si are 4 NIC-uri au făcut echipă într-un echilibru-rr legătură de mod.
  • B este un DELL R610 care rulează Linux 5.13.19-1-pve Proxmox VE 7.1 si are 4 NIC-uri au făcut echipă într-un echilibru-rr legătură de mod.
  • C este un DELL R710 care rulează FreeBSD 12.2-RELEASE-p1 cu un decalaj peste 8 NIC-uri în round-robin (aceasta este o distribuție TrueNAS).

Toate NIC-urile sunt de 1 GBps.

Când alerg iperf3 între bladele Linux, am max la aproximativ 3 GBps, iar fereastra urcă la o medie de ~300 KiB. Cu toate acestea, între blade TrueNAS (FreeBSD) și blade Linux, fluxul TCP atinge maxim 1,20 Gbps și limitează fereastra la o medie de ~60 KiB. Dacă rulez fluxuri paralele (adică, iperf3...-P 8) Pot satura legătura. Pe de altă parte, așa cum era de așteptat, numărul de retransmisii este destul de mare în ambele cazuri. Deci, întrebările mele sunt,

  1. De ce FreeBSD nu atinge același debit dacă se presupune că ambii abordează problema în același mod? (poate că acolo mă înșel).
  2. Există o opțiune de reglare sau o combinație de opțiuni pentru a face stiva TCP mai tolerantă la necomanda, fără a declanșa retransmiteri imediate? (Sunt vag familiarizat cu 3-ACK reTX, elementele de bază ale controlului congestiei TCP și așa mai departe).

Voi include aici câteva reglabile și opțiuni pe care le-am folosit în timpul testării mele.

  • Toate iface-urile sunt setate să utilizeze cadre jumbo (MTU 9000).
  • Cutiile Linux sunt reglate după cum urmează
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.ipv4.tcp_mem = 1638400 1638400 1638400
net.ipv4.tcp_rmem = 10240 87380 16777216
net.ipv4.tcp_rmem = 10240 87380 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_reordering = 127
net.ipv4.tcp_max_reordering = 1000
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_congestion_control = reno
  • Caseta FreeBSD (TrueNAS Core ~= FreeNAS) este reglată după cum urmează
kern.ipc.maxsockbuf=614400000
kern.ipc.somaxconn=1024
net.route.netisr_maxqlen=8192
net.inet.ip.intr_queue_maxlen=8192
net.inet.tcp.mssdflt=8948
net.inet.tcp.reass.maxqueuelen=1000
net.inet.tcp.recvbuf_inc=65536
net.inet.tcp.sendbuf_inc=65536
net.inet.tcp.sendbuf_max=307200000
net.inet.tcp.recvbuf_max=307200000
net.inet.tcp.recvspace=65228
net.inet.tcp.sendspace=65228
net.inet.tcp.minmss=536
net.inet.tcp.abc_l_var=52
net.inet.tcp.initcwnd_segments=52 # începe rapid
net.inet.udp.recvspace=1048576
net.inet.udp.sendspace=1048576
Effie avatar
drapel ne
în ceea ce privește retransmiterile: există un [rfc4015](https://datatracker.ietf.org/doc/html/rfc4015) care practic ridică 3-ACK la ceva mai mare la reordonare.Ultima dată când am lucrat cu nucleul linux (în jurul v4.0.2) a fost implementat. De asemenea, `net.ipv4.tcp_reordering = 127` înseamnă că 3-ACK este de fapt 127-ACK.
Effie avatar
drapel ne
strategia mea obișnuită de testare ar fi: descărcarea segmentării tcp (nu știu cum funcționează cu cadrele jumbo), apoi verificarea faptului că controlul fluxului nu este factorul limitator (bufferele sunt suficient de mari). Pe Linux o fac cu tcp_probe și verific că fereastra de congestie arată ca reno și nu ca pătrate, nu știu dacă există un instrument similar pentru freebsd, apoi controlul congestiei (linux-ul tău este setat la reno, deci cel puțin ar trebui să nu merite decât freebsd ). probabil că nu ajută, dar pentru orice eventualitate.
Puncte:1
drapel us

Puteți încerca să utilizați cadre jumbo dacă rețeaua dvs. acceptă acest lucru. Nu înlătură principala problemă de declanșare a retransmisiilor TCP în afara ordinului.Cu toate acestea, deoarece cadrele Ethernet sunt de șase ori mai mari, numărul de pachete scade, ceea ce scade numărul de evenimente necomenzi.

În caz contrar, ar trebui să vă verificați cazul de utilizare, chiar aveți nevoie de o singură conexiune TCP pentru a obține întregul debit? Dacă există mai multe conexiuni TCP active între dispozitive, atunci ar trebui să utilizați echilibrarea încărcăturii TCP.

dacabdi avatar
drapel cn
Cadrele Jumbo ajută foarte mult, de departe este cel mai pozitiv reglabil și văd de ce. Pe de altă parte, încerc să maximizez debitul pentru o parte, așa că, într-un fel, da, am nevoie de fluxul TCP pentru a maximiza. Voi muta câteva fișiere uriașe cu foarte puțină muncă simultană.
drapel us
Există, de asemenea, Multipath TCP, care ar fi potrivit pentru cazul dvs. de utilizare. Cu toate acestea, este încă devreme pentru aceasta, așa că este posibil să nu găsiți o implementare stabilă pentru mediul dvs.https://en.wikipedia.org/wiki/Multipath_TCP are mai multe informații.
dacabdi avatar
drapel cn
Este destul de grozav, nu știam de MPTCP. Voi citi ceva, chiar dacă nu există încă o adoptare pe scară largă, este ceva cu care pot experimenta într-o bancă de laborator.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.