[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport



Le 04/08/2010 18:13, Pascal Hambourg a écrit :
> giggz a écrit :
>>>>
>>> les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
>>> Est ce normal ?
> 
> Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options
> n'existaient pas lors de la conception initiale de TCP, et si la machine
> en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont
> essentiellement pour but d'augmenter les performances dans certaines
> circonstances : produit débit*latence élevé, pertes de paquets,
> nombreuses connexions...
> 
>> Bon ça avance!!! si je force via sysctl.conf la valeur de
>> net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres
>> valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le
>> résultat.
> 
> Tu pouvais tester en modifiant directement la valeur du paramètre du
> noyau en ligne de commande avec
> sysctl -w net.ipv4.tcp_timestamps=1
> (le -w n'est apparemment plus obligatoire pour modifier un paramètre)
> (ou echo 1 > /proc/sys/net/ipv4/tcp_timestamps mais c'est laid)
> d'autant plus que le résultat final au démarrage dépend de l'ordre dans
> lequel firestarter et le script qui applique sysctl.conf sont exécutés.
> 
>> et c'est bien firestarter qui modifie cette valeur:
>> dans /etc/firestarter/sysctl-tuning on a la valeur de
>> net.ipv4.tcp.timestamps forcé à 0.
>>
>> Bon je suppose que si cette variable est forcée à 0 il doit y avoir une
>> bonne raison.
> 
> Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas
> correctement ces options, aussi il est parfois nécessaire de les
> désactiver. Sinon je ne vois pas trop.
> 
>> je suppose que le rapport de bug doit plutot aller au
>> maintenant du driver atl1c, non ?
> 
> Je vais encore te donner du travail, mais pourrais-tu vérifier si
> tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en
> fonction du MTU avec les autres distributions installées sur la machine
> (sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug.
> En gros vérifier sur chacune si (si j'ai bien compris) :
> - MTU=1492 et tcp_timestamps=0 -> bug
> - MTU=1500 ou tcp_timestamps=1 -> ok
> 

sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
MTU=1492 et tcp_timestamps=0 -> bug
MTU=1492 et tcp_timestamps=1 -> ok
MTU=1500 ou tcp_timestamps=0 -> ok
MTU=1500 ou tcp_timestamps=1 -> ok

Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le
bug apparait.

sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de
tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte
graphique et pas le même driver (b44).

Bonne soirée
Guillaume


Reply to: