Le site web, le blog et les projets de Stéphane Klein

Vous êtes ici : Blog › Archives › 2010 › Mars › Page 1

Mesures de bande passante de mon réseau local

Posté par Stéphane Klein le lundi 29 mars 2010 dans les catégories Informatique, Admin’Sys, Outils | View Comments

Depuis un certain temps, je trouvais mon réseau Wifi très lent. La dernière fois que j'ai dû transférer 20 Mo entre deux portables, cela a pris 20 minutes !

Cette après midi, j'ai décidé d'étudier un peu plus précisément ce problème.

1. Utilisation de "netperf"

netperf est un outil de mesure de performances réseaux.

D'après la documentation, il permet de mesurer de nombreuses choses… pour ma part, je n'ai utilisé que les mesures TCP_STREAM et TCP_MAERTS.

netperf est disponible sous Debian (dans la section non-free) et sous Ubuntu.

Une fois le paquet installé, netserver est lancé automatiquement et écoute sur le port 12865.

Voici un exemple de ce que j'ai fait :

j'ai installé le paquet netserver sur la machine A et B
j'ai exécuté sur l'une des deux machines la commande suivante :

$ netperf -H 192.168.1.10 -t TCP_STREAM
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.10 (192.168.1.10) port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    11.36       1.69

2. Mes mesures

J'ai donc utilisé netperf pour mesurer la bande passante mon réseau local dans un peu près toutes les configurations :

Source		Destination		Débit
Wifi / Ethernet	Lieu	Wifi / Ethernet	Lieu	Mbit/s	Mo/s
Wifi (eeepc)	Bureau	Wifi (macbook)	Bureau	0,01	0,00125
Wifi (eeepc)	Proche de la freebox	Wifi (macbook)	Proche de la freebox	1,16	0,15
Wifi (macbook)	Proche de la freebox	Ethernet (PC fixe)	-	6,36	0,795
Wifi (eeepc)	Proche de la freebox	Ethernet (PC fixe)	-	1.52	0,19
Ethernet (eeepc)	-	Ethernet (PC fixe)	-	94,03	11,75
Ethernet (macbook)	-	Ethernet (PC fixe)	-	93.96	11,75

Pour avoir un ordre de grandeur, voici les valeurs maximales théorique de mon réseau :

Ethernet : 100 Mbit/s soit 12,5 Mo/s
Wifi IEEE 802.11g : 54 Mbit/s théoriques, 25 Mbit/s réels soit 3,125 Mo/s

On peut constater que le débit Wifi de mon réseau est catastrophique ! D'une incroyable lenteur entre wifi à wifi : 1,25 Ko/s !

Par contre, pas de problème au niveau du réseau Ethernet, je suis très proche des valeurs maximales de transfert.

Pour améliorer le wifi, j'ai essayé de changer de canal, étant donné qu'il y a de nombreux réseaux wifi dans ma zone.

Sur ma Freebox, la sélection du canal était activée en mode automatique :

« Si vous activez le choix automatique du canal, la Freebox choisira elle même, à chaque démarrage, le canal Wifi le moins perturbé. Cela vous permet d'obtenir une connexion plus fiable. »

J'ai choisi de le passer en manuel et de choisir le canal 2 après avoir vérifié avec wifi-radar que personne ne l'utilise dans ma zone. Après observation, je constate que tous les utilisateurs de Neuf sont sur le canal 11… et il y a du monde ! Je pense que leurs débits doivent être catastrophique.

Voici mes mesures après être passé sur le canal 2 :

Source		Destination		Débit
Wifi / Ethernet	Lieu	Wifi / Ethernet	Lieu	Mbit/s	Mo/s
Wifi (eeepc)	Bureau	Wifi (macbook)	Bureau	7,36	0,92
Wifi (eeepc)	Proche de la freebox	Wifi (macbook)	Proche de la freebox	7,78	0.97
Wifi (macbook)	Proche de la freebox	Ethernet (PC fixe)	-	20,66	2.58
Wifi (eeepc)	Proche de la freebox	Ethernet (PC fixe)	-	22,41	2,8

Les résultats sont vraiment meilleurs, je suis presque aux valeurs maximales du Wifi.

Voici maintenant des mesures vers l'extérieur : un serveur situé chez un hébergeur.

Source		Destination		Débit
Wifi / Ethernet	Lieu	Wifi / Ethernet	Lieu	Mbit/s	Mo/s
Ethernet (PC fixe)	À mon domicile	via ADSL	Hébergeur	0.87	0,108
Ethernet (PC fixe)	À mon lieu de travail	via ADSL	Hébergeur	0.84	0,105
via ADSL	Hébergeur	Ethernet (PC fixe)	À mon domicile	5.49	0,686
Ethernet (Serveur A)	Hébergeur A	Ethernet (Serveur B)	Hébergeur A	94.13	11,76

Voici les caratéristiques de ma ligne ADSL :

Votre ligne est raccordée à un DSLAM compatible ADSL2+
Longueur : 2159 mètres
Affaiblissement : 32 dB

Voici les caratéristiques de la ligne ADSL à mon lieu de travail :

Votre ligne est raccordée à un DSLAM compatible ADSL2+
Longueur : 1490 mètres
Affaiblissement : 22 dB

La bande passante maximale pour une connexion ADSL2+ :

en réception : 28 Mbit/s théoriques soit 16 Mbit/s en pratique
en émission : 1,2 Mbit/s théoriques

Informations supplémentaires

Pour utiliser netperf à travers un Firewall : How configure my firewall to execute netperf ? I use shorewall (iptable firewall) on Debian
Pour effectuer une mesure inverse de la bande passante, par exemple le débit montant/descendant d'une connexion ADSL : netperf ... -t TCP_MAERTS

Read and Post Comments

php var_dump VS python repr !

Posté par Stéphane Klein le vendredi 12 mars 2010 dans les catégories Informatique, Python, Php, Comparaison, Développement | View Comments

Un exemple en Php :

<?php

$a = 'bar "test" bar';
var_dump($a);
// Sortie : string(14) "bar "test" bar"

$b = 'bar \'test\' bar';
var_dump($b);
// Sortie : string(14) "bar 'test' bar"

$c = 'bar \'test\' "test" bar';
var_dump($c);
// Sortie : string(21) "bar 'test' "test" bar"

$d = array(
    'foo' => 'bar \'test\' "test" bar'
);
var_dump($d);
/* Sortie :
    array(1) {
      ["foo"]=>
      string(21) "bar 'test' "test" bar"
    }
*/

?>

la sortie de ce script :

string(14) "bar "test" bar"
string(14) "bar 'test' bar"
string(21) "bar 'test' "test" bar"
array(1) {
  ["foo"]=>
  string(21) "bar 'test' "test" bar"
}

Même chose en Python :

>>> a = 'bar "test" bar'
>>> print(repr(a))
'bar "test" bar'

>>> b = 'bar \'test\' bar'
>>> print(repr(b))
"bar 'test' bar"

>>> c = 'bar \'test\' "test" bar'
>>> print(repr(c))
'bar \'test\' "test" bar'

>>> d = { 'foo': 'bar \'test\' "test" bar' }
>>> print(d)
{'foo': 'bar \'test\' "test" bar'}

Observatons :

PHP oublie d'afficher les caractères d'échappements
Python affiche correctement les caractères d'échappements
Python prend soin d'afficher au mieux les guillemets : soit utilise des simples "quotes" ou des "double quotes"

Read and Post Comments

Début mars 2010, Python, WSGI, WebDAV état des lieux

Posté par Stéphane Klein le mercredi 10 mars 2010 dans les catégories Informatique, WSGI, WebDAV, Python, Web-dev, Projets, Développement | View Comments

Plus de six mois après avoir publié mon dernier billet au sujet des serveurs WebDAV basés sur protocole WSGI (sous Python), il est tant pour moi de faire un nouveau point sur la situation.

1. J'ai choisi WsgiDAV

Au mois d'août dernier, je n'avais pas encore choisi entre le projet pywebdav et wsgidav. Depuis, j'ai fait mon choix, j'ai choisi wsgidav. Qu'est ce qui a motivé ce choix ?

l'architecture de wsgidav est modulaire, je trouve que l'utilisation de plusieurs middleware wsgi pour ajouter des fonctionnalités est une chose intéressante
comme son nom l'indique WsgiDAV est orienté WSGI ce qui est avantageux pour moi car c'est mon objectif premier et donc cela me donne moins de travail par rapport à pywebdav

2. Changements apportés à `WsgiDAV`

Lorsque je travaillais sur le projet pywebdav j'avais comme objectif d'apporter des modifications au code pour fournir une classe application ou middleware WSGI. Je n'ai plus à me préocuper de ce point car WsgiDAV est nativement orienté WSGI.

Par contre, depuis août j'ai tout de même apporté des améliorations à WsgiDAV. Ma plus importante contribution est la compatibilité avec le client WebDAV Finder de Apple.

2.1. Compatibilité avec Apple Finder WebDAV Client

C'est la tâche qui m'a pris le plus de temps et posé le plus de difficulté... bien que cela soit surtout dû à un manque de méthode et un surplus de procrastination.

Au niveau de la méthode, j'ai procédé à tâton pendant un certain moment. Je
plaçais des logs, activais PDB...
et j'essayais de de comprendre les causes d'incompatibilités avec Apple
Finder.
J'ai ensuite utilisé Wireshark
pour analyser les échanges TCP/IP... ce qui fut une très bonne idée car en
quelques heures j'ai trouvé et corrigé les erreurs que je n'arrivais pas à
déceler auparavant.
Parlons maintenant de ma procrastination... on va dire que j'ai tourné autour du
problème pendant trois ou quatre mois, de septembre à décembre 2009.
Étant donné que je ne procédais pas avec la bonne méthode, je n'étais pas très
motivé pour travailler sur cette tâche. J'avais toujours une bonne excuse pour
travailler sur d'autres choses. Comme très souvent, la cause première de la
procrastination est la peur de l'échec.

La bonne nouvelle est que maintenant les problèmes de compatibilités avec Apple Finder sont réglés. D'autre part, ces corrections ont aussi corrigé d'autres erreurs... avec Windows Vista si mes souvenirs sont bons.

3. Chantiers en cours

Depuis que les problèmes de compatibilités avec Apple Finder sont résolus, j'ai débuté d'autres chantiers...

3.1. Amélioration des tests

J'en ai marre de devoir utiliser Wireshark, un client WebDAV... pour tester mon code... j'ai donc décidé pour gagner du temps et de la qualité en regardant du coté des test fonctionnels... ce que j'aurais dû faire depuis le début !

En gros, WsgiDAV utilise trois types de tests :

un fichier de commande à lancer avec litmus (programme pour tester des serveurs Webdav)
utilisation de la librairie davclient
utilisation de paste.fixture.TestApp mais ce type de test est limité aux requêtes HTTP classiques GET, PUT, DELETE

Autre informations :

les tests utilisent le module standard unittest
il n'est pas toujours possible de lancer des tests individuellement, par exemple avec test_wsgidav_app.py il est obligatoire de lancer l'intégralité des fonctions de tests et dans le bon ordre

Mes objectifs et tâches en cours au niveau des tests :

utiliser l'outils Nose pour lancer les tests et supprimer petit à petit l'utilisation du module unittest
permettre de lancer les tests individuellement
fournir une classe davclient.TestApp dérivée de paste.fixture.TestApp qui permet de tester l'intégralité des fonctions Webdav.

Pour le moment ces tâches ne me posent pas trop de difficultés.

3.2. Support d'un provider "Mixin"

Dans un de mes projets d'utilisation de WsgiDAV, j'ai besoin de "monter" un dossier accessible via une url du type "http://exemple.com/dav/".

Petit détail, j'aimerais pouvoir voir le dossier "dav" (dossier virtuel nommé aussi "share_name") lorsque je me connecte à "http://exemple.com/". Cette fonctionnalité n'est pas existante actuellement.

Ce point est important pour deux choses :

simplifier la "découverte" des points de montages
Gnome Nautilus ne permet pas de visualiser une resource si la racine du domaine ne contient pas son dossier parent (c'est un bug que j'aimerais corriger à l'avenir). C'est à dire qu'il n'est pas possible d'accéder à "http://exemple.com/dav/" si la requête PROPFIND sur "http://exemple.com/" ne liste pas le dossier "dav"

Pour résoudre ce problème, j'ai décidé de créer un nouveau provider, que j'ai nommé "MixinProvider". Ce provider permet de "mixer" plusieurs "provider" en un seul.

Exemple d'utilisation :

provider = MixinProvider((
    (&quot;/&quot;, FilesystemProvider('/tmp/root1/')),
    (&quot;/&quot;, FilesystemProvider('/tmp/root2/')),
    (&quot;/dav&quot;, FilesystemProvider('/tmp/root3/')),
    (&quot;/foo/bar/&quot;, FilesystemProvider('/tmp/root3/'))
})

Note :

il est tout à fait possible de mélanger d'autres types de provider que FilesystemProvider
les providers sont traités dans l'ordre d'apparition de la liste (ici un tuple), c'est à dire que dans cet exemple, si les dossiers '/tmp/root1/' et '/tmp/root2/' contiennent tous les deux un fichier nommé "foobar.txt", si l'utilisateur exécute la requête GET '/foobar.txt', c'est le contenu du fichier '/tmp/root1/foobar.txt' qui sera retourné.

Actuellement, la classe MixinProvider est presque fonctionnelle.

3.3. Support d'un provider "Dummy"

Pour la réalisation de la classe MixinProvider j'ai eu besoin de créer un provider permettant de créer des ressources mais aussi surtout des dossiers fictifs… d'où le nom « Dummy ».

Voici un exemple d'utilisation de cette classe :

dummy_provider = DummyProvider(
    resources = ('/file1.txt', '/folder_a/file2.txt', '/file3.txt',),
    collections = ('/folder_b/', '/folder_c/folder_d/',)
)

Remarque : la classe MixinProvider crée automatiquement un provider "dummy" pour permettre la visualisation des points de montages lors de l'exécution de requêtes PROPFIND.

4. Chantiers futurs

Voici une liste d'autres chantiers futurs :

amélioration de la documentation : basé sur Sphinx, qui devra être hébergé sur http://packages.python.org/wsgidav/
amélioration des tests..., mise en place d'un buildbots...
rédiger une procédure de sortie de release : liste d'instructions à réaliser après chaque release stable. L'une de ces instructions serait de mettre à jour un tableau qui liste les clients webdav avec lesquels wsgidav est compatible.

5. En annexe du projet

À la marge du projet, j'ai réalisé un provider basé sur ZODB. Il fonctionne plutôt bien. Ce provider n'est pas libre pour le moment.

C'est dans le cadre de ce projet que j'ai eu besoin de créer le provider MixinProvider.

6. Temps passé sur le projet

Depuis août, on peut dire que j'ai travaillé en moyenne 3h par mois sur le projet... le problème est que j'y ai surtout passé de multiples petits moments... ce qui n'est pas ce qu'il y a de plus efficace... car la plupart du temps j'avais juste le temps de me replonger dans le code... avant d'arrêter.

Dans les semaines qui viennent, j'espère pouvoir travailler chaque dimanche quatre heures sur le projet afin de rapidement finir la partie provider Mixin (ce qui est presque réalisé).

Read and Post Comments

stephane-klein.info

Navigation principale

Mesures de bande passante de mon réseau local

1. Utilisation de "netperf"

2. Mes mesures

Informations supplémentaires

php var_dump VS python repr !

Début mars 2010, Python, WSGI, WebDAV état des lieux

1. J'ai choisi WsgiDAV

2. Changements apportés à `WsgiDAV`

2.1. Compatibilité avec Apple Finder WebDAV Client

3. Chantiers en cours

3.1. Amélioration des tests

3.2. Support d'un provider "Mixin"

3.3. Support d'un provider "Dummy"

4. Chantiers futurs

5. En annexe du projet

6. Temps passé sur le projet

Sujets (tags)

Mes services professionnels

Plan de site

Ressources

Mon blog

Contributions

Autres pages

Mes flux :

Navigation principale

1. Utilisation de "netperf"

2. Mes mesures

Informations supplémentaires

1. J'ai choisi WsgiDAV

2. Changements apportés à WsgiDAV

2.1. Compatibilité avec Apple Finder WebDAV Client

3. Chantiers en cours

3.1. Amélioration des tests

3.2. Support d'un provider "Mixin"

3.3. Support d'un provider "Dummy"

4. Chantiers futurs

5. En annexe du projet

6. Temps passé sur le projet

Sujets (tags)

Mes services professionnels

Plan de site

Mes flux :

2. Changements apportés à `WsgiDAV`