Ciao fdineve, mi fa piacere trovare un interlocutore su questo argomento.
Utilizzi qualche programma od utility per monitorare la velocità dei trasferimenti oppure usi anche te semplicemente Gestione attività?
Ma hai verificato se dopo aver impostato un valore personalizzato nel pc esso cambia, per opera del s/o, magari dopo una connessione effettuata o dopo un riavvio? Nel pc con Win8 che ho quel che dici non si verifica ma neanche in quello con Win7 se non erro (poi verifico) e non ho applicato nessun cambiamento alle impostazioni di connessione nel Pannello di controllo o nella scheda di rete (al di fuori dell'MTU) quindi non saprei dirti cosa causa quel comportamento nel tuo caso, sempre che si verifichi, perché se non sbaglio non hai controllato che il valore fosse veramente cambiato da Win7 ma hai solo osservato che le performance sono le stesse anche avendo impostato due valori diversi e quindi hai supposto che il s/o cambiasse autonomamente il valore.
Tieni comunque presente che per ottenere il massimo i valori in tutti gli elementi della rete devono essere identici all'unità quindi non fanno fede i casi in cui c'è un valore diverso dagli altri.
Facendo le prime prove riavviavo i notebook dopo ogni variazione di MTU applicata tramite Gestione dispositivi poi però ho pensato che fosse superfluo perché appena davo l'okay alla modifica la NIC veniva riavviata senza che io facessi niente (solo dopo il suo riavvio riavviavo il pc), sicuramente per rendere effettiva la modifica, quindi ho smesso di riavviare i pc anche per risparmiare tempo e tutto è andato liscio: mai un errore di connessione né niente di simile.
Proprio cinque minuti fa ho fatto un altro trasferimento (un solo file MKV da 4.7 GB) ed ho visto che la velocità questa volta ballava molto ma il massimo è stato di 90 MB/s per qualche istante, che non avevo mai raggiunto, anche se la velocità media è stata di molto inferiore ai casi sopra riportati; segno forse che è più facile trasferire un archivio compresso che un file video, o magari vale solo per quei precisi formati e non in generale per indie tipi di contenuto o addirittura nessuna di queste, chissà.
Cmq con valori di MTU più alti dovresti osservare un miglioramento ben maggiore di quello che hai visto ora dato che al momento hai solo eguagliato i valori ma non li hai alzati. Ricordati però che se vuoi fare un collegamento Gigabit è necessario un cavo di categoria 5e, oltre a tutte le NIC coinvolte capaci del GigE e con risparmio energetico (Green Ethernet a volte è chiamato) disattivato. Va bene anche Unshielded soprattutto se non hai dei SSD o HDD molto veloci perché 800 Mbps sono già 100 MB/s e dei comuni dischi rigidi non ci arrivano se non per pochi istanti a quella velocità di lettura e scrittura. Se invece non hai quei colli di bottiglia potresti anche valutare l'acquisto di un cavo Foiled che costa di più ma rende altrettanto. Penso invece che un cavo Shielded sia del tutto superfluo. Come anche un cavo di categoria 6 perché per i collegamenti domestici mi sa proprio che i 5e sono più che sufficienti e poi quelli di categoria superiore non si trovano facilmente più corti di tre o cinque metri.
EDIT
Come non detto: nel pc con Win7 il valore di MTU è tornato quello di default, ecco perché l'ultimo trasferimento fatto era andato peggio in quanto a velocità media. Ma sono sicuro che quando ho fatto i trasferimenti di cui al primo post il valore fosse come lo avevo impostato io ed infatti sono andati meglio. Evidentemente dopo un riavvio od una nuova connessione via cavo (se non ricordo male l'ho collegato via cavo al router dopo quelle prove) il s/o si impone sulle tue preferenze. Probabilmente lo farà anche Win8 ma non posso saperlo perché ho allineato il valore nel NB con Seven a quello con 8 e non viceversa e non voglio fare la prova al contrario perché meno smanetto più sono sereno: non si sa mai che si possano combinare casini.
- - - Updated - - -
Mi sono informato su Microsoft Technet ed ho capito meglio la situazione.
Nella chiave del registro di sistema di Windows HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters vi è il valore EnablePMTUDiscovery che è normalmente impostato su 1 e fa sì che il TCP cerchi autonomamente il miglior MTU per l'adattatore di ogni interfaccia (Ethernet, Wi-Fi, Bluetooth) e glie lo imponga, invece se impostato su 0 imporrà un MTU di 576 bytes per le connessioni a tutti i computer che si trovano al di fuori della sottorete in cui è l'adattatore. Non è specificato per quelle ad host nella stessa sottorete, come un altro pc in casa propria, quindi se si avesse un vecchio pc che può essere utile solo per conservarci una copia di backup dei propri dati (e quindi non risentisse del problema di avere un MTU basso quando si va a collegare ad internet perché tanto su internet non lo si manda) magari si potrebbe anche dargli uno 0 ed impostare con netsh l'MTU automatico del pc dal quale gli si mandano i file ed i due coinciderebbero e tutto filerebbe lisco. Ma è un'altra strada anche poco praticabile.
C'è poi il valore MTU nella chiave di registro HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\
nome dell'interfaccia che ha precedenza sul suddetto valore e se quest'ultimo è impostato su 1 l'utilità di questo secondo valore è imporre all'adattatore un MTU più basso di quello che TCP gli ha assegnato, ma non uno più alto. Infatti se l'MTU automatico è maggiore di quello nella seconda chiave è quest'ultimo a venire assegnato all'adattatore, se invece è minore sarà lui ad imporsi. Cioè ogni volta che il valore personalizzato sarà più basso di quello automatico vincerà ed ogni volta che sarà più alto perderà quindi in nessun caso si può ottenere un MTU maggiore di quello automatico perché lo scopo del valore della seconda chiave è di abbassare l'MTU utilizzato e non alzarlo.
Dunque quel che dovrò fare io è ribaltare l'impostazione attuale: al momento ho adattato l'MTU più basso a quello più alto ma ogni volta che TCP prenderà il controllo annullerà ciò quindi per non diventare matto a ripetere tutte le votle la modifica adatto il valore più alto a quello più basso.
Fonti:
#1,
#2
