Pb débit réseau local sous Linux mais pas sous W$ avec NAS (Dual boot)

[krzyzstof]

Bonjour,

Après mon 1er post de présentation, je passe directement à mon 1er post technique 😇. J'ai hésité entre la thématique "réseau" et "linux", désolé si je me suis égaré.

Voilà mon problème :
Je viens de finir le câblage rj 45 de ma maison (câble cat.7 et prise cat.6a) et je rencontre un problème de débit entre mon PC HP (cf. config en signature) et mon NAS (Synology DS414, DSM 6.2) lorsque je suis en boot KDE 18.04. A titre d'exemple un fichier de 1,5 Go passe à 34 Mb/s (du pc vers NAS ou NAS vers PC) alors que lorsque sur le même PC mais en boot W$10 le même fichier transite à 120 Mb/s. Le fichier transite par le partage et le montage d'un dossier du NAS.
Avant toute chose j'ai vérifié que mes câbles et mes cartes réseaux de pc étaient ok. J'ai donc installé sur les différents PC linux et W$ de mon habitat le programme iperf3 et lancé un test entre ces PC. Les résultats étaient de l'ordre de près de 1Gb/s sauf sur mon PC HP en boot KDE qui plafonnait à 100 Mb/s (et bien 1G sous le boot W$). Je suis allé donc dans les paramètres de la carte réseau et je me suis aperçu que dans l'onglet "cablé", le champ "vitesse" était plafonné à 100 Mb/s. J'ai donc changé la valeur à 1000 Mb/s et j'ai relancé un test avec iperf3. Là, super, les résultats de débit approchait le Go.
Cependant, cela n'a pas changé mon problème de débit entre mon HP sous KDE et mon NAS. Les débits restent toujours aussi faiblards.
Je précise que sur la config de la carte réseau, le MTU est sur "automatique". J'ai essayé avec la valeur "1500" mais cela n'a rien changé. Je suis donc revenu sur "automatique".
Donc si vous avez des idées...
Merci

Pour info les lignes de commande linux suivantes donnent :
sudo lshw -C network

*-network DÉSACTIVÉ       
       description: Ethernet interface
       produit: Dual Band Wireless-AC 3168NGW [Stone Peak]
       fabriquant: Intel Corporation
       identifiant matériel: 0
       information bus: pci@0000:02:00.0
       nom logique: wlp2s0
       version: 10
       numéro de série: 30:e3:7a:cf:d1:fe
       bits: 64 bits
       horloge: 33MHz
       fonctionnalités: pm msi pciexpress bus_master cap_list ethernet physical
       configuration: broadcast=yes driver=iwlwifi driverversion=4.15.0-91-generic firmware=29.3e3b4de5.0 latency=0 link=no multicast=yes
       ressources: irq:133 mémoire:dea00000-dea01fff
  *-network
       description: Ethernet interface
       produit: Ethernet Connection (4) I219-LM
       fabriquant: Intel Corporation
       identifiant matériel: 1f.6
       information bus: pci@0000:00:1f.6
       nom logique: enp0s31f6
       version: 21
       numéro de série: 40:b0:34:12:76:af
       taille: 1Gbit/s
       capacité: 1Gbit/s
       bits: 32 bits
       horloge: 33MHz
       fonctionnalités: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=off broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=0.1-4 ip=192.168.1.113 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s

sudo ifconfig

enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.113  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fdd0:ff98:d6ef:3300:b375:9ba:42af:bdb  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::42e3:ae40:d299:777d  prefixlen 64  scopeid 0x20<link>
        inet6 fdd0:ff98:d6ef:3300:695a:676:bf22:f12c  prefixlen 64  scopeid 0x0<global>
        ether 40:b0:34:12:76:af  txqueuelen 1000  (Ethernet)
        RX packets 17317  bytes 20289818 (20.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10516  bytes 1367173 (1.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xdec00000-dec20000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Boucle locale)
        RX packets 463  bytes 41847 (41.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 463  bytes 41847 (41.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

cat  /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

 

[DaffY]

Bonjour,

Protocole smb mini à combien sur le nas ?

Sinon avec Linux sauf erreur un partage en nfs est mieux non ?

[krzyzstof]

Merci Daffy pour ta réponse :)

Pour le protocole smb en maxi j'ai SMB 3 et en mini SMB 2

Concernant le partage en nfs sous linux, je t'avoue que je ne sais pas, ayant toujours eu l'habitude de partager en smb. Je vais regarder ce que je trouve dans cette direction 😉

[krzyzstof]

Hello, j'ai donc longuement investigué sur ce protocole NFS qui ne m'est pas familier. Et effectivement en passant par NFS, les taux de transferts augmentent significativement. Cependant, je rencontre 2 problèmes.

1) Si le transfert du NAS vers le PC me donne des taux de transfert de 100 Mo/s (au lieu des 34 Mo/s sous SMB linux mais 120 Mo/s sous W$10), le transfert de PC vers NAS semble nettement moins rapide. Alors je dis "semble" car enfin de compte dans ce sens mon pc semble "freezer" : l'icône de notification de transfert en bas à droite du bureau n'apparaît pas et Dolphin ne répond plus jusqu'à la fin du transfert. Montant mes partitions avec autofs, j'ai bien noté une remarque stipulant :

Citation

 

doc ubuntu a écrit :

"N'utilisez pas les signets nautilus vers des dossiers issus du partage nfs, le timeout d'autofs ne fonctionnera pas et cela provoquera des freezes si le serveur est hors ligne. Par contre, les volumes NFS présent par défaut dans les raccourcis de nautilus ne poseront pas de problème. Pour ce faire allez voir le fichier /home/Utilisateur/.gtk-bookmarks, il se peut qu'il y ai une ligne qui pointe vers un partage nfs et qui n'apparaisse pas dans la partie signet de nautilus, supprimez là, sinon freezes…

 

N'utilisant pas Nautilus mais Dolphin, je n'ai pas trouvé ce fichier .gtk-bookmarks. J'ai juste trouvé un fichier bookmarks dans le répertoire .config/gtk-3.0/  Dans ce fichier pas de trace de partage nfs.

J'ai aussi arrêté le service autofs avec :

sudo service autofs stop

puis j'ai monté manuellement mon répertoire du type :

mount 192.168.1.253:/volume1/video  /media

je relance le transfert de NAS vers PC (tout est ok et rapide), puis de PC vers NAS, et là rebelotte, freeze et temps de transfert plus long 

Remarque personnelle : sous le boot W$10 le taux de transfert monte plus haut (120 Mo/s) et reste surtout plus stable sans réelle fluctuation de débit. Avec NFS le débit est un peu moindre (en tout cas de NAS vers PC) mais surtout très fluctuant avec des baisses jusqu'à 50 Mo/s ou moins. Alors soit ce protocole est moins performant, soit (ou les deux à la fois) Synology n'est pas vraiment bien conçu pour ce protocole, non ?

2) Avec tous les dossiers par défaut sous le NAS (video, music...) que je partage, je ne rencontre pas de problème de montage. Par contre, si je crée dans le NAS un nouveau dossier, admettons "Test" et que je lui octroi les mêmes permissions que les dossiers par défaut, je vois bien sur mon pc le montage mais je ne peux y accéder. J'ai bien vérifié j'ai exactement les mêmes paramètres et permissions que les dossiers par défaut. Après plusieurs heures je sèche...

[DaffY]

Bonjour,

date un peu mais peut peut être aider : https://libreaquimperle.blogspot.com/p/serveur-nas-synology.html
ça aussi mais j'imagine que c'est connu déjà : https://doc.ubuntu-fr.org/tutoriel/acceder_a_votre_nas_depuis_toutes_les_applications
Sinon en SMB ça donne quoi cette commande ? smbutil statshares -a

 

 

[.Shad.]

Via SCP/SFTP tu peux essayer de faire un transfert de fichier lourd (quelques Go) d'une machine linux vers ton NAS en SSH ?
Normalement le taux de transfert doit être proche du gigabit.

[krzyzstof]

Merci Daffy et Shad pour vos réponses 👍 Je regarde dès que possible et je fais un retour ! 😉

Modifié le 8 avril 2020 par krzyzstof

[krzyzstof]

Le 08/04/2020 à 14:33, DaffY a dit :

Bonjour,

date un peu mais peut peut être aider : https://libreaquimperle.blogspot.com/p/serveur-nas-synology.html
ça aussi mais j'imagine que c'est connu déjà : https://doc.ubuntu-fr.org/tutoriel/acceder_a_votre_nas_depuis_toutes_les_applications

Bon Daffy, j'ai bien regardé et testé (après avoir perdu beaucoup beaucoup de temps sur la signification et la compréhension des différentes options de montage et aussi suite une erreur malencontreuse dans mon chemin de partage lorsque j'ai recommencé à zéro mes montages), mais j'ai toujours les mêmes problèmes concernant 1) le freeze lors de l'upload (PC --> NAS) et un débit mieux que sous SMB mais pas à la hauteur de W$ (en moyenne : smb=34Mo/s ; NFS=75 Mo/s ; W$10=125Mo/s) 2) L'impossibilité d'accéder à un dossier que j'ai moi-même créer et partager. Aucun souci par contre pour les dossiers par défaut (music, vidéo, etc.). Franchement je sèche.

Le 08/04/2020 à 14:33, DaffY a dit :

Sinon en SMB ça donne quoi cette commande ? smbutil statshares -a

 

 

Cela ne serait pas une commande pour Mac ??? 🙃 Après une recherche, j'ai cru comprendre que cela correspondait à : "Vérifier l’état de la signature des paquets SMB" (cela ne m'évoque strictement rien 😁) et je n'ai pas trouvé d'équivalence sous ubuntu (mais ne comprenant pas ce que je cherche... 😉)

Le 08/04/2020 à 15:03, .Shad. a dit :

Via SCP/SFTP tu peux essayer de faire un transfert de fichier lourd (quelques Go) d'une machine linux vers ton NAS en SSH ?
Normalement le taux de transfert doit être proche du gigabit.

Je n'ai pas encore eu le temps de regarder de ce côté pour l'instant...

[DaffY]

il y a 45 minutes, krzyzstof a dit :

Cela ne serait pas une commande pour Mac ??? 🙃 Après une recherche, j'ai cru comprendre que cela correspondait à : "Vérifier l’état de la signature des paquets SMB" (cela ne m'évoque strictement rien 😁) et je n'ai pas trouvé d'équivalence sous ubuntu (mais ne comprenant pas ce que je cherche... 😉)

Oups.. grillée .. comme une ... Toutes mes excuses.... 😔

Donc oui c'est en effet une commande macOS mais l'idée est d'obtenir le plus d'informaitons sur le statut de la connexion smb acitvée. Normalement un équivalent cmme ça :

smbstatus --shares

détails sur la fonction ici : https://www.samba.org/samba/docs/current/man-html/smbstatus.1.html

 

[krzyzstof]

Pas de souci 😊 Alors la commande "sudo smbstatus --share"  me retourne juste :

Service      pid     Machine       Connected at                     Encryption   Signing     
---------------------------------------------------------------------------------------------

Je précise qu'avant d'avoir effectué cette commande j'ai fais un test de transfert en mode samba entre le PC --> NAS et inversement

Modifié le 10 avril 2020 par krzyzstof