Le prestazioni di lettura di Synology peggiorano con i frame Jumbo oltre 6000


12

Versione breve

La mia rete domestica è pura gigabit con dispositivi che supportano tutti i frame jumbo fino ad almeno ~ 9000 byte. Aumentare l'impostazione del frame jumbo MTU su Synology a 6000 (byte) aumenta le prestazioni (810 Mbps in scrittura e 945 Mbps in lettura). L'impostazione del valore su 7000 distrugge solo le prestazioni di lettura (che diminuiscono fino a 4 Mbps); le prestazioni di scrittura rimangono veloci.

Ciò è inaspettato perché la maggior parte dei problemi dei frame jumbo non ha una direzionalità associata a questi e in genere sono tutti o niente (i pacchetti vengono rilasciati in uno switch indipendentemente da dove provengano). Non sembra esserci alcuna frammentazione IP in corso, ma il livello TCP è davvero infelice. Cosa potrebbe causare questo comportamento asimmetrico / instabile e come posso risolverlo per supportare l'intera MTU da 9000 byte che dovrebbe supportare tutta la mia attrezzatura?


Versione lunga

Queste sono le mie note modificate prese mentre provavo a capirlo.

Cliente

Controller
Jumbo RTL8167 della famiglia GBE Realtek PCIe : MTU 9KB

$ netsh interface ipv4 show subinterfaces
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  9198                1   32501506   11275394  Local Area Connection

(appare 9198 non include l'intestazione ethernet a 14 byte)

$ ping -l 1500 -f 192.168.1.84

(osservato con Wireshark in esecuzione sul client; tutte le dimensioni sono dimensioni di byte del filo)
[9213, ∞] non inviato dall'host (richiederebbe la frammentazione)
[9019, 9212] inviato ma nessuna risposta
[9015, 9018] risposta IP frammentata
[42, 9014 ] IP non frammentato
[0, 41]? (impossibile generare poiché intestazioni eth + IP + ICMP = 14 + 20 + 8 = 42 byte)

Router (porzione dell'interruttore)

Asus RT-AC68U - Firmware 3.0.0.4.378_4585
Abilita frame jumbo: "Abilita"
Non riesco a capire quale dimensione jumbo frame effettivamente supporta, sembra essere almeno 9000

Frammenta le richieste di ping dal client proprio a 1514 byte (ma il ping del router potrebbe innescare il suo comportamento del router WAN invece del suo comportamento di switch LAN?)

Switch non gestito

TP-LINK TL-SG1008D
Telai jumbo (schede tecniche): 9KB (il loro sito web dice 15KB ma sembra un dispositivo diverso)

server

Synology DS1815 + - DSM 5.2-5565 Aggiornamento 1
Jumbo Frame: 9000

Pacchetti di lettura file da Synology a
Dimensione client : la maggior parte sono 9014 byte (in entrambe le direzioni)
Flag IP: non frammentare
Wireshark scoperto: ritrasmissione spuria TCP, segmento precedente TCP non catturato, TCP fuori servizio, ritrasmissione veloce TCP, e pacchetti normali (9014 byte) Pacchetti
SMB2 su protocollo NetBIOS lettura lettura lunghezza lettura: 65.536 (~ 8 segmenti TCP)

$ ifconfig
bond0     Link encap:Ethernet  HWaddr --:FF
          inet addr:192.168.1.84  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:85 dropped:0 overruns:0 frame:85
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:237 GiB  TX bytes:117 GiB

eth2      Link encap:Ethernet  HWaddr --:00
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:19 dropped:0 overruns:0 frame:19
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:236 GiB  TX bytes:83 GiB

eth3      Link encap:Ethernet  HWaddr --FF
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:66 dropped:0 overruns:0 frame:66
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1 GiB  TX bytes:33 GiB

eth2 ed eth3 sono collegati utilizzando il bilanciamento del carico adattivo (nessun supporto switch)

$ ping -c 5 -s 1500 192.168.1.82

(osservato con Wireshark in esecuzione sul client; tutte le dimensioni sono dimensioni di byte del filo)
[9019, ∞] richiesta inviata, risposta inviata, risposta non ricevuta
[9015, 9018] richiesta IP frammentata (probabilmente frammentata da Synology, il ping busybox non ha un opzione no-framment quindi è difficile dirlo)
[60, 9014] IP non frammentato
[0, 59]? (impossibile generare perché il ping busybox mette almeno 18 byte più le intestazioni di 42 byte)

Dati vari

  • La modifica dell'MTU client a 8 KB non è stata di aiuto
  • La velocità di lettura del server scende da una scogliera quando si cambia l'MTU del server da 6000 (eccezionale, 945 Mbps) a 7000 (terribile, 4 Mbps)
  • La velocità di scrittura del server non è sostanzialmente influenzata da tutte le impostazioni MTU del server (sempre tra 700 e 825 Mbps)
  • Synology ha una rete legata (2 delle 4 porte)
  • I cavi sono tutti Cat6 o Cat5e

È necessario presentare un ticket di supporto con synology. Non ho alcuna esperienza con Synology, quindi non so se ci sono impostazioni avanzate in cui è possibile aumentare le dimensioni del buffer di memoria, ma è probabilmente ciò che è necessario. Personalmente, di solito ottengo 920mbits e non uso affatto i jumbo frame. Basta avere un interruttore netgear generico non gestito.
cybernard,

Risposte:


2

Aggiorna il firmware

Nella mia esperienza, Synology risolve molti problemi in ogni versione del firmware e quella in esecuzione ha quasi quattro anni. Non ho letto le note di rilascio, ma sembrano esserci molte possibilità per un bug frame Jumbo da allora essere stato risolto.

Prova con una connessione diretta

Collegare la macchina di prova direttamente a Synology (assegnare gli IP statici sulla stessa sottorete) con nuovi cavi patch ed eseguire nuovamente i test. Ciò eliminerà il cablaggio e gli interruttori, nonché eventuali altri problemi relativi alle apparecchiature e alla configurazione. Se il problema persiste, eseguire i test con un altro computer. Se rimane ancora è sicuramente il NAS.

Se il problema scompare durante il test di connessione diretta, provare prima a sostituire l'interruttore, quindi il cablaggio. Non hai mostrato le connessioni, quindi presumo solo il TPLINK tra la macchina di prova e il NAS.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.