Jump to content

Appel à contribution: Monitoring du réseau ADSL en Algerie


Recommended Posts

as: je crée un nouveau thread pour ne pas interferer avec celui de Lemrid (thread=14816) qui parle d'un sujet similaire, mais pas tout à fait; je modifie une partie de mon contenu pour adapter à la nouvelle situation

 

Vous pouvez lire/telecharger ce document au format pdf à l'adresse suivante :

 

http://www.scribd.com/doc/17262364/appelacontributionmonitoringdistribue

 

Vous avez la possibilité de l'imprimer pour le lire à votre rythme, vous êtes invités à l'envoyer à vos collegues, contacts, amis; vous êtes priés de poser vos remarques et suggestions, pour le bénéfice de tous.

 

Introduction

------------

 

La qualité constatée par les clients ADSL en algérie, nottament les utilisateurs sur ce forum est sujette à polémique. Afin de pouvoir évaluer de façon objective les performances, et de constituer une base de conaissances, je propose qu'un projet open source soit lancé dans ce sens, et votre aide sera indispensable pour sa réussite. Je vous invite à lire la présente proposition, ou de sauter vers la section qui vous interesse dans le text si vous n'avez pas le temps de tout lire; vous pourrez reprendre plus tard, à votre aise.

 

 

La problematique

-----------------

 

Dans l'objectif de mettre en place un projet open source pour le suivi des performances du réseau ADSL, je propose d'evaluer la proposition suivante, et je vous prie d'apporter vos commentaires, qui seront plus que bienvenus :

 

Résumé :

--------

 

*Quoi* : une méthode pour collecter, analyser et publier les performances des reseaux ADSL en algérie

 

*Pourquoi* : afin de constituer une base de donnée vivante, sensibiliser les gens, isoler les problemes, avoir une influence eventuellement, faire améliorer les choses

 

*Comment* : en invitant les gens a donner leurs idées, critiques et suggestions, savoir faire, expriences

 

Si dix personnes, par exemple, participent avec une ligne de code chacune chaque jour, le code client et serveur seraient terminés en quatre semaines; ça vaut le coup de tenter l'experience ^^

 

Qui peut contribuer

-------------------

 

- utilisateur ADSL : en effectuant des tests (en utilisant le futur logiciel), vous aiderez la communauté a detecter les defaillances des fournisseurs, les goulots, isoler votre probleme. Vous pouvez aussi contribuer en donnant votre avis sur la question, en signalant un bug, parler du projet autour de vous. L'outil vous permettra aussi d'identifier la nature de votre probleme, et à terme (pour certains) de les résoudre.

 

- developpeur/chercheur : en ecrivant des bouts de codes, des idées techniques, des analyses eventuellement. Aucun besoin de s'investir lourdement, une fonction ou deux suffiront pour faire avancer l'ensemble

 

- technicien/commercial chez un provider : en parlant de ce projet aux administrateurs de votre entreprise, en lisant la documentation qui l'accompagne, en étant convaincu que cet outil permettra à votre employeur d'améliorer son service, sans débourser un centime en R&D

 

Comment contribuer :

--------------------

 

En proposant des idées, en parler autour de vous, proposer des fonctionnalités (wishlist), en débattre sur le forum, donner son avis, ...

 

Le projet

----------

 

- L'outil proposé permettra d'afficher les tests en ligne sur un site web, par région, fournisseur d'accès, qualité

- La récolte des tests est anonyme et ne concerne que les details techniques

- le rapport est envoyé, et une copie est gardée sur le disque dur de l'utilisateur (qu'il pourra utiliser pour réclamer auprés de son fournisseur, ou poster sur un forum afin qu'il soit assisté)

- L'outil proposé permettra aux nouveaux clients de choisir, selon la région et le provider, la meilleur configuration selon leurs souhaits

- L'outil proposé permet d'avoir une evaluation indépendante des performances globales des fournisseurs d'accès à internet en algérie, constitue une base d'aide à la décision, enrichie les recherches/rapports/articles dans le domaine

 

Les metriques

-------------

 

Les parametres que je vois interessants à evaluer, sont à mon avis :

 

- le debit en download + le temps de lattence : le debit uniquement ne suffit pas, car lui meme est affecté par d'autres parametres (par exemple, la congestion sur le reseau; au moment du test si l'upload du client en question est elevé par rapport aux max alloué, le download en prend un coup pour certains cas, son ping aussi)

 

- le systeme d exploitation : etant donné que les performances dependent beaucoup du stack tcp/ip qui est embarqué sur le systeme; il serait interessant de connaitre la version de l'os (les implementations sur windows par exemple ne sont pas respectueuses des recommandations)

 

- le download en bulk et en raffale : le systeme ayant ses caracteristiques intrinseques (depassement (overshoot), temps de montée (rise time), réponse permanente, d'ailleurs si vous voulez les 'voir' il suffit de voir evoluer le graph de emule ou utorrent : ça commence par monter suivant presque une sigmoide, puis redescend, et oscille autour d'une valeur; c'est le comportement typique, c est pour cette raison que le telechargement d'un fichier de 1Mo est plus rapide en gros que 10 fichiers de 1024 Ko)

 

- l'horaire du test : puisque le systeme dans son ensemble depend de ceci (heure:minutes)

 

- pour la region, je pense qu'il est plus interessant de granulariser en donnant si possible le rattachement par rapport au dslam (car parfois les goulots, sont à ce niveau la, et le decoupage par dslam est plus logique sur un reseau adsl que le decoupage geo. cette information peut etre "sniffée" lors des echanges ppp entre l'hote et le dslam, eventuellement )

 

Pour les quatre premiers parametres, leur récolte ne constitue pas de problemes majeurs, et une programmation classique est adequate.

 

Orientations du projet

---------------------

 

voici les aspects que j'estime necessaires :

 

1 - le test devrait etre automatisé (c'est pas tres mechant, sur linux/gnu à la rigueur c est un script shell qui lance un wget et qui grep le temps de download) :

 

+ pour que l'utilisateur n'ait à intervenir que peu (human factor)

 

+ pour collecter un plus grand nombre de metrics

 

+ pour homogeneiser les resultats

 

+ pour la collecte automatique (ça va de paire)

 

2 - si le test est automatisé, il doit etre :

 

+ open source (en python, perl, java ou autre)

 

+ multiplateforme (tout le monde n'utilise pas linux ^^)

 

3 - il doit etre open source :

+ pour garantir l *evolution* : chacun pourra rajouter ses fonctions dans la base de données de code

+ pour assurer la *confiance* : pas de distribution de logiciels malicieux

+ pour que ce soit une base de connaissances : quelque chose qui marche en industrie, c est toujours interessant pour les etudiants/demandeurs de savoir

+ si reussite il y'a, c est un projet qui émule, et qui pousse a voir davantage

 

4 - le test doit etre propagé chez un grand nombre : voila une bonne occasion pour faire les fameux Fwd sur nos contacts ^^ (le grand nombre garanti la fiabilité/répétabilité des resultats)

 

5 - les *resultats* doivent etre *publiques* : aucun interet pour l'utilisateur final de participer a un "sondage" automatique s'il n'ya pas de retour d'experience

 

je vois en ça une bonne occasion pour commencer des choses assez sympa autour de problematiques bien reelles, et des objectifs bien palpables

 

 

Et les tests de debits en ligne ?

----------------------------------

 

Pourquoi les résultats de tests manuels/semi automatiques ne sont pas pertinents (comme mireadsl, zdnet speedtest, et les autres) :

 

- le resultat produit n'est pas sous forme traitable (dans un tableur, ou sur une base de donnée)

- a cause de ça leur richesse est limitée, vous ne pouvez pas faire de statistiques (moyenne, max, min, deviation)

- pour qu'il soient utilisables, par exemple classer la qualité par région, par dslam, par debit max, par congestion, ... il faudrait reprendre ces tests et les transcrire en une ecriture traitable. trop contraignant pour un projet qui est basé sur le collectif/collaboratif

 

Méthodologie

-------------

 

En discutant autour de la meilleur façon de deployer un tel systeme, j'ai pensé à la méthodologie suivante :

 

1 - le choix des metriques : quels sont les elements que le programme devrait collecter chez le client. Bien entendu certains sont evidents, comme le debit en download et le debit en upload, on devrait aussi en determiner d'autres; dans ma vision premiere, je pensais à :

 

+ le ping : pour quantifier la congestion du réseau

+ la qualité du dns (temps de reponse, satisfaction des requetes)

+ le systeme d'exploitation

+ la date et heure du systeme (je pensais plutot à un synchro avec un serveur externe, histoire d avoir une pin point accuracy, et surtout etre synchro et eviter les eventuels decalages de l'horloge locale, les données dans leurs ensembles seraient alors homogenes d un point de vue timestamp)

+ l'adresse ip de la _passerelle_ adsl: pour pouvoir localiser le dslam qui est responsable du raccoredement (un mecanisme plus elaboré pourrait etre ensuite appliqué pour mieux localiser par region)

 

Je pense que ces metriques pourrait etre deja un bon debut

 

2 - le choix de la façon de distribuer ce software : pour que l'utilisateur soit le plus à l'aise dans son utilisation, et pour qu'il soit utilisable sur un tres grand nombre de plateformes. est-ce que le programme doit etre installable, telechargeable ? doit-on le distribuer sous forme de binaire, ou source ? doit-il demarrer sur un page web ? (mes choix perso : source, telechargeable, terminal)

 

3 - le choix du langage de developpement : si on utilise un langage populaire, les rajouts se feront plus naturellement. on m'a conseillé java webstart, pour lancer des applications à partir de pages web, parait-il. je pensais pour ma part a un programme en python qui demanderait quand meme de telecharger l'interpreteur pour les plateformes qui n'en sont pas munies, mais l'avantage reste d'avoir du source en main (et donc de la richesse, et un confort), et une idée derriere la tete celle d'utiliser plus tard l'excellent scapy[1] pour performer des tests beaucoup plus en profondeur.

 

4 - la façon de rapporter les données collectées : renvoyer un rapport automatiquement, ou proposer au client de poster le fichier de rapport lui meme ? (moins automatisé), sous quel format (xml, csv,...) ? (mes choix: automatique (avec confirmation); xml)

 

Pourquoi contribuer

-------------------

 

Aussi, pour les gens qui ne voient pas encore l'utilité d'un tel outil, je vais tenter d'exposer ce qui me parait etre pertinent :

 

- vous etes manager/vous travaillez dans le domaine des tic : impliquez vos ingenieurs pour participer à ce projet ne serait-ce que par une ligne de code par jour; votre retour sur investissement serait de collecter des données réelles sur les comportements d'un réseau de grande taille; une telle base de données :

 

+ coute tres cher (si vous arrivez à trouver les gens qui proposent ça)

+ n'est pas accessible legalement (sauf si ce projet aboutit)

+ les isp ne peuvent vous fournir de telles données : trop strategiques

+ l'analyse de ces données constitue une richesse

+ constitue une pub pour vous

 

- vous etes etudiant/chercheur/developpeur : idem, les données réelles ne sont presque jamais publiées, vous pourrez faire valider vos modeles, voir si vos solutions collent à la réalité, developper des méthodes

 

- vous etes utilisateurs final/futur client : l'analyse de ces données vous permettent de savoir si le probleme est isolé ou global, vous permettent d'avoir un avis informé (pour choisir votre prochain fournisseur selon votre region, vos exigences), vous permet d'avoir de l'aide rapidement puisque l'ensemble des données _utiles_ est recolté

 

Pas encore convaincus ?

-----------------------

 

Le fournisseur d'accès à internet, et d'une façon générale, le prestataire de service sera d'une oreille attentive dès que les clients s'expriment collectivement et d'une façon organisée. Il suffit d'influencer l'évolution du chiffre d'affaire pour que le management ajuste sa politique. Ce n'est pas la raison la plus parlante, mais elle me semble un argument de plus pour convaincre du bien fondé de cette démarche. (Merci à SecDz de m'avoir rappelé d'argumenter sur l'interet des ISP concernant cet outil dans le benefice du client)

 

Les graphs suivants représentent le chiffre d'affaire ainsi que le nombre total des abonnés particuliers ADSL du fournisseur Eepad pour le mois de mai 2009. Remarquez que pendant la durée du mois, ainsi que sur certaines portions, le mouvement massif de clients influe sensiblement sur les performances (baisse de 23.-- % en CA).

(Pour les graphs, merci de consulter le pdf, le lien est au debut du post)

 

 

Quelle est la suite ?

---------------------

 

Pour le moment, les choix à déterminer sont :

 

- Que mesurer

- Comment déployer

- Avec quel language

- Sous quelle forme rapporter les données

 

Vous en pensez quoi les gars ?

 

Portez-vous bien.

 

[1] scapy : logiciel en python pour la manipulation de packets tcp/ip, excellent pour le debug, l'academique ou l'assessment (de firewall, par exemple)

 

http://www.secdev.org/projects/scapy/

Link to post
Share on other sites

j'y participe

voila une bonne base pour commencer a traiter le sujet.

j'y contribue en étant un testeur (niveau informatique : bas).

vous devriez créer un blog dés maintenant (twitter,facebook .....etc)

merci pour ton temps.

Link to post
Share on other sites

bonjour tout le monde,

 

amarsoft: merci ^^ je publierais incha'-allah un second document pour commencer à mettre en place ceci, eventuellement placer le projet sur sourceforge

 

el3anif : merci à vous aussi pour votre participation, pour le blog/site honettement je ne suis pas "chaud" pour ces plateformes, mais je pense que si ce projet est plébicité par un nombre de personnes, j'y placerais la documentation ainsi que le suivi

 

wefix, Travmania : ravis que vous proposiez votre participation, je compte commencer par un programme open source, proof of concept afin de valider certains points (certaines approches, aussi).

 

onizo : merci pour votre remarque, pertinente en effet. Je publierais dans un prochain document les points que je vois interessants, nottament concernant les destintations de ping. J'ai pensé à une petite architecture bien sympathique dans l'esprit de ne pas avoir un systeme possedant des single point of failure. Mais pour résumer l'architecture (qui ne sera pas abordée en premier à cause de certains concepts qui viennent avant), je vois les tests comme des modules, importables dans le programme principal. Chaque test appartient à une classe de tests, partage un environnement, et à acces a des fonctions publiques. Plus de détails sur ça plus tard.

 

Les remarques et les suggestions sont plus que bienvenues.

N'hésitez pas à apporter vos commentaires, aucun besoin que ce soit technique, la moindre idée et direction est appréciable.

 

Si vous souhaitez aider ce projet, envoyez un email à vos contacts susceptibles d'etre interessés, en mentionnant le titre, le lien vers le pdf ou forum et éventuellement l'introduction.

 

Merci pour votre participation.

 

Portez-vous bien.

Link to post
Share on other sites
  • Moderators

on avait déja parlé de ce projet il y a pas mal d'années !

 

mais impossible de trouver des personnes mobilisées et motivées dans la durée et dans la réalité.

 

on peut s'inspirer pour faire simple de GRENOUILLE : http://www.grenouille.com/cest_quoi.php

 

 

logo.png

 

 

voici la partie tech : http://wiki.grenouille.com/index.php/Projet_Technique

 

.

Link to post
Share on other sites

...

+ pour collecter un plus grand nombre de metrics

...

 

Je trouve que c'est là où réside le problème.Pour collecter un grand nombre de données, il faut que l'outil soit extrêmement facile à utiliser.J'ai créé un tuto sur un logiciel qui fait à peu près ce que vous cherchez mais il est loin d'être facile à utiliser.

Link to post
Share on other sites

bonsoir tout le monde,

 

je prépare un ptit doc concernant la premiere partie que j'estime interessante avant de commencer le noyau dure. Le doc s'appel 'Metrics' et concerne donc les parametres à mesurer et une discussion sur les différents choix. j'effleurerais les problemes de filtrages des mesures des systemes dynamiques ainsi que de la backward compatibility du futur programme. Manque de temps, mais j'essaie de tenir le rythme.

Encore une fois, je vous invite à faire un peu de pub pendant votre temps libre, ce projet à un bon potentiel.

 

J'hésite encore, pour le moment : java ou python ? (histoire de parler du prochain choix à faire)

 

java : portable, sympa, c'est presque du C, démarrable sur page web, populaire

python : mignon, flexible, possibilité de l'héberger (une idée derriere la tete concernant la distribution coté serveur)

 

qu'en pensez vous ?

 

amarsoft : en effet oui, le monitoring est tres à la mode, si les gens se mettent un peu à étudier les dynamiques des systeme et leur feedback, une évolution importante pourrait voir le jour (et en plus sa recrute pas mal chez les operateurs telecom pour ce profil ^^)

 

djoss : bonne indication en effet, merci pour le lien. j'y ai jeté un coup d'oeil rapide

pourquoi pas, une grenouille dz ! bonne idée ! (un fenec, dans ce cas ? ^^)

pour la mobilisation; je pense qu'avant de lancer un projet, il faut poser des bases un chuia theoriques et de methode sur comment faire participer les gens dans un context ouvert. j'ai lancé l'idée mais je ne pense pas avoir convaincu, une prochaine doc ptet dans ce sens.(apres tout, c'est l 'eternelle' question chez nous : pquoi on avance pas ?)

 

racnet : j'ai consulté votre tutorial, je vous en remercie. PRTG est en effet un bon logiciel dans sa categorie. Justement, concernant la récolte des metriques, elle est destinée à etre tres fortement à faible interaction coté utilisateur. En gros, ce sera du "lancer le programme", "patienter", "confirmer l'envoi du rapport". Des options "expert" pourraient voir le jour, mais certainement pas en release-candidate ou en v.1

 

Les gars, vous me donnez une idée concernant le snmp, il serait fort judicieux d'exploiter le daemon snmp embarqué sur les (certains) modems adsl qui circulent en algérie afin d'exploiter les données brutes.

Probablement un appel à contribution pour enumerer les marques et les models, afin de faire les profils des tests.

 

Ca s'annonce plutot chaud ^^ courage, encore 8 semaines avant la premiere release candidate ^^

 

Sur-ce,

Portez-vous bien.

Link to post
Share on other sites

oui inchallah 8 semaines, rana fi intidar el mawssou3a el 3ilmiya

 

et plus un pour python, il y a un projet gestion stock qui serra lacer tres prochainement sur ce forum et je pense que python serra le langage choisi, donc on aura une équipe qui travail sur les deux projets et je pense que c'est du bien car on va savoir c'est quoi collaborer avec les autres.

 

http://www.forumdz.com/showthread.php?t=15203

Link to post
Share on other sites

bonsoir tout le monde,

 

onizo: ok ^^ je resterais alors theorique pour les deux prochains doc à produire.

 

amarsoft: j'aime bien python mais onizo a raison, d'abord l'abstrait ensuite le concret.

 

fs_djmellisse: merci pour votre soutien ainsi que votre participation

l'association est idéalement l'outil légal, comme vous dites. cependant (et j'ai exposé en detail mon point de vue sur le topic traitant de ce sujet) je pense que l'association dans un contexte algérien n'est pas efficace. De toute façon, ce ptit projet la n'est pas en contradiction, car si creation d'association il y'a, il faudra lui associer une partie technique, et alors il faudra faire appel aux compétences. A un moment donné, la phrase "la connection chez les clients adsl n'est pas satisfaisante" doit etre backed-up par un solide argumentaire, palpable vérifiable et cohérent. Je pense que ce projet répond humblement à une partie de cette problématique.

 

En résumé, on ne doit plus avancer d'appréciations sur la qualité sans indicateurs fiables. Si on parle indicateurs, on déplace le débat vers un terrain ou le discours de médiocrité aurait bien des difficultés à respirer.

 

En parlant de "voix du peuple", je pense qu'il nous faut une solide theorie derriere. Il nous faut aussi formuler ce que nous voulons communiquer. Nous gagnerons à demystifier certains problemes qui nous paraissent extra-terrestres. (dissequer, analyser, propager. froidement, methodiquement)

 

En vous remerciant pour l'interet que vous portez tous à cette initiative.

Portez-vous bien.

Link to post
Share on other sites

Bonjour,

 

Je m'interesse de pret depuis quelque temps a cette question : "Est ce qu'on pourra faire bouger les choses?"

 

Ma Réponse est : Oui.

 

Mais pas en croisons les droits, c'est pour cela que j'invite toute personne pourrons contribuer dans ce domaine a consacrer juste le peu du temps qu'il faudra car tous le monde sera gagnant ( même algerie telecom car qui dit client satisfait, chiffre d'affaire en +++ )

Link to post
Share on other sites
  • 2 weeks later...

 

Des Pages web pour le projet afin de mieux structurer la proposition

Tres bonne initiative, bien que longue a lire tewfik! Ce n'est pas forcement long mais en un seul document ca décourage plus d'un. Des pages web pour le projet auraient pu donner un peu plus de structuration ergonomique avec un menu et des liens pour chaque titre... avec un wiki (pour amener les gens a contribuer dans l'amélioration de la description même du projet) ca serait "plus" mieux ;_)

 

Un noyau... ensuite des cellules

Lancer un projet sans matière initiale (code source) n'est, a mon avis, pas évident. Il fraudera peut être créer un noyau de développeurs (ou même demmarer seul), comme il est souvent le cas dans les projets libres, proposera un premier noyau fonctionnel avec le minimum de fonctionnalités. C'est ce noyaux de développeurs qui imposera le mode de développement (quel langage, quelle norme de développement...), et balisera aussi les objectifs en matières de capacite fonctionnelle, fiabilite, rendement, portabilite et maintenabilite (voir ISO9126 et autres normes). Ce même noyaux validera, par la suite, les contributions des développeurs potentiels.

 

Mètre...HIC...le traceroute sera le bienvenu (casse tete)

Le contexte DZ est tellement "complexe" que les metriques seront l'un des plus grands HICs!

Dans la mesure deux paramètres tres importants rentrent en jeu : l'étalon (ou référence) et le "point de mesure". Pourquoi je cite ces deux paramètres? car la mesure se fera toujours d'un point différent (clients) par rapport a un autre point fixe qui sera le serveur (referent, etalon.. appellez le comme vous le voulez), ce dernier sera rendera la mesure alterable (relativement). Des exemples pour faire ressortir les problemes qui risquent d'etre poses :

  • Les tables de routage chez fawri font passer l'utilisateur par telefonica
  • Les tables de routage chez EEPAD font passer l'utilisateur par seabone
  • Un autre utilisateur chewz EEPAD passe par telefonica
  • Un autre utilisateur utilise un VPN
  • A ce moment le lien avec telefonica est saturée

et vice versa. Comment peut-on faire une comparaison entre ces deux cas puisque la route vers le referent est differente? et elle est changeante même a partir du meme client! ... des traceroutes pourront etre rajoutées aux métriques... mais pour analyser tout ca d'une maniere neutre "bonjour les degats" ...

 

ou sera hébergé le serveur ?

Un autre problème! Comment on saura si c'est la qualité de la ligne du client qui est mauvaise (il y a plusieurs abonnées dont les modems synchronisent en dessous de leur BP allouée) ou que c'est la qualité de connexion du FAI qui déconne?

 

Je prend simplement mon cas (debit/ping):

  • 5 Mb/s - 40ms a partir du site de l'EEPAD
  • 1Mb/s - 80 ms a partir du debian.seabone.net
  • 75Kb/s - 105 ms a partir de free.fr
  • 45Kb/s - 100 ms a partir de telefonica.es
  • 65Kb/s - 115 ms a partir de Djaweb ou AT

Comment je vais interpréter ces résultats ? Comment sera calculé le débit ? a partir du telechargement d'un fichier sur le serveur ? a partir du telechargement de fichiers sur internet ou sur les sites des FAIs? Comment assurer la fiabilité et la justesse de la mesure ? ou sera hébergé le serveur? pleine de questions qui me passent par la tete

mode: brainstorming>

 

PS: je viens de relire mon intervention et je la trouve pessimiste! Ce n'était pas le but mais il faut bien se poser tous les questionnements

Edited by assilabox
Link to post
Share on other sites

Salam,

 

Merci assilabox pour votre intervention, fort utile. Merci aussi pour votre habituelle mise en page qui rend la lecture aisée.

 

J'ai presque terminé mon deuxieme brouillon, au sujet des metrics, il ne me reste qu'a parler un peu de la façon de mesurer et quelques idées sur le bruit, avant de le publier.

 

Vous posez des problematiques interessantes, j'anticipe pour vous répondre, vous trouverez aussi peut être plus d'eclaircissement sur ce que je pense dans le prochain upload.

 

Au sujet des pages web :

 

J'ai très souvent tendance à mettre mes interventions au format "rapport" qui est probablement une déformation. Vous me donnez l'idée en effet de mettre la documentation sous forme plus lisible. Le wiki, vous avez raison, est le format qui semble être le plus adéquat. Je me concentre d'abord sur le contenu, ensuite le contenant. Une page sur wikipedia pour le suivi du projet peut etre ?

 

La matière :

 

Lorsqu'on sait ce qu'on veut obtenir, il est plus simple de faire le cheminement. Vous avez raison, il faut un noyau de code, celui-ci viendrait à la fin de la documentation, au debut de la mise en oeuvre. J'espere pouvoir produire une sorte de "framework" proof of concept, fonctionnel qui pourrait servir afin d'étendre par la suite les fonctionnalités.

 

Les metrics :

 

^^

En effet oui, complexes questions.

Vous citez un cas interessant, et globalement vous avez raison de vous soucier de la 'position' de la mesure par rapport à une référence. Vous dites que la mesure sera entachée d'une erreur qui est due aux aléas du service du provider. Vous avez raison.

 

J'ai encore mieux : la mesure dans ce cas la est alterée lors de la mesure elle même ^^

Lorsque vous uploadez a plein régime, le stack tcp/ip avec ses méthodes de controle va adapter le queueing, et hop! votre ping grimpe (et je parle pas des shaping coté routeurs), et du coup vous avez une fausse mesure car entachée (en gros, car en vérité meme le bruit est quantifiable dans certains cas). C'est comme si on essayait de voir des electrons avec un microscope electronique.

 

Vous estimez que le 'bruit' qui est produit par l'aléas de service est problématique, mais bien au contraire ! c'est exactement ce que l'on souhaite mesurer ^^ ! On aura le temps incha'-allah d'en discuter plus en détail.

 

Point important : lors des tests, on doit limiter les effets coté utilisateur, ce qui signifie qu'il serait pas tellement interessant de mesurer le download lorsque l'utilisateur télécharge deja quelquechose (la mesure reviendrait à évaluer une fraction de la bande passante réellement disponible, ce qui n'est pas juste). Mais en meme temps, on ne doit pas gener l'utilisation pendant une longue durée. A discuter.

 

Pour comparer, a mon avis, il faut sectoriser. Etant donné que je suis entrain de penser cet outil d'une part comme un outil de récolte, mais un peu plus tard comme un outil de diagnostique, il me semble interessant d'effectuer des tests sur plusieurs niveaux: entre vous et votre dslam, puis vers des machines chez l'isp, puis sur les routeurs de la backbones, ... Ceci permettrait par la suite d'isoler l'origine du problème (du monitoring distribué ^^). Ceci n'est pas prévu pour la première version.

 

Les traceroute seront d'une aide en effet, leurs analyse n'est pas si difficile que ça, mais pour une premiere version, je ne compte pas les integrer (pattern recogntion sera de retour ^^)

 

Hébergement du serveur :

 

ou dirais-je; les serveurs ^^

je comptais héberger le code chez google, au sein de leurs infrastructure appspot.

c'est gratuit, redondant, géographiquement distribué (ce qui pour certains pourrait poser matiere à réticences). Ils acceptent, à ma connaissance, le python et le java, ce qui est deja ça (avec parait-il un hack pour faire tourner le php sur du java)

 

 

Pour la qualité de ligne, il y'a sur ce forum des posts forts interessants (vous meme?) concernant l'analyse des paramètres (snr, et crc checks) du modem adsl. Integrer ceci comme module au programme principal serait en effet excellent. (soit un parser html pour chaque brand de modem, pour extraire les parametres en question, si ce n'est pas acccessible en snmp)

 

Comme vous dites, comment savoir si le serveur est saturé, ou si notre connexion n'est pas bonne, la réponse réside en partie dans la multiplication de tests, et leur distribution. Pratiquement, le fait de telecharger un fichier (en bulk donc), n'est pas représentatif de la qualité du surf. Le module de mesure du download doit pouvoir simuler une connection de type navigation, simplement en agissant comme agirait un navigateur : charger une page web, puis charger ses objets, mesurer les temps de chargement. Répeter l'opération quelques fois. Pour le bulk, je n'ai pas encore pris de décision definitive.

 

Je compte utiliser et les machines des isp, et les machines disponibles sur internet, mais une discussion est prévue à ce sujet, nottament pour les question de déni de service probables, le filtrage, la légalité d'une telle utilisation, ...

 

Pour assurer la fiablité et la justesse, il faut d abord : - multiplier les mesures, - filtrer les résultats, - évaluer le bruit (plus sur ça tres prochainement)

 

 

bidossessi : Merci pour votre soutient ^^ n'hésitez pas à apporter vos commentaires.

 

Au prochain doc,

Portez-vous bien.

Link to post
Share on other sites

Salam,

 

Classification du BRUIT...

Effectivement, l'objectif est de mesurer le bruit et de pouvoir le classifier en :

 

  1. Bruit FAI (Temps de réponses, Paquets perdus, BP reel donc taux de contention...)
  2. Bruit AT (Paire téléphonique)
  3. Bruit Client (Trafic UP et DOWN au moent du test , MTU, Modem, Branchement, OS, Firewall ativirus et autres applications de controle qui risquent ralentir la connexiuon...)

Contributions evntuelles ...

des modules dans lesquels je souhaiterais apporter ma contribution au projet:

 

1. module pour la récupération des valeurs suivantes (a partit du SAGEM 3302):

  • ADSL Up Speed
  • ADSL Down Speed
  • ADSL Attenuation UP
  • ADSL Attenuation Down
  • ADSL SNR Up
  • ADSL SNR Down
  • ADSL CRC
  • ADSL HEC

Ceci peut se faire, comme tu l'as dis, par un simple parsing html ou text (telnet? a vérifier). Bien sure, il faut penser a avoir l'accord au préalable de l'utilisateur notamment s'il a changer le mot de passe par défaut du routeur.

 

Je pourrais aussi essayer de récupérer de ces valeurs depuis le modem sagem A800 (qui est également en ma possession). Ceux qui ont d'autres modem/routeur peuvent se proposer pour faire la même chose.

 

2. liste des processus en cours, toujours avec l'accord de l'utilisateur ? Pour lui demander d'arrenter les processus qui consomme de la BP lors du test (clients P2P, download managers)? Les récupérer sur la BD pour analyse ?

 

3. Un module like MTR ou MTR (traceroute + ping) qui sera, a mon avis, l'un des outils les plus pertinents pour localiser les failles chez les FAI ;_) (un mtr a partir des serveurs serait peut être plus intéressant, afin d'éviter les pb d'interopérabilité?)

 

4. Etat de service du réseau du FAI : Il est facile de retourouver les adresse IP de tous les DSLAM, Serveur DNS etc.. chez un FAI et de mettre en place un service smokeping pour surveiller l'etat du reseau en permanence. Cette fois, la recolte de donnees se fera en permanence et independement des utilisateurs. Puisque je suis client chez eepad, et pour un debut, je pourrais heberger un service smokeping pour donner l'etat du reseau ainsi que des informations sur le temps de reponses, biensure, cela reste tributaire de la qualite de ma propre connexion :_) : Oups. the human factor nous suit partout :_P

 

Human factor ....

Pour ce qui est du développement, je maîtrise le PHP/MySQL, le C++ un peu moins, mais python et java je n'ai jamais toucher a ca (refus et crainte de l'innovation). Même si je cite souvent la normalisation, je suis pas le premier a la respecter :_( je suis plutôt anarchique et solo en développement :0) , j'essayerai de faire des efforts cette fois :_)

Pour le timing, je ne pourrais pas commencer avant le 22 Aout, je pars en vacances dans quelques jours.

PS: Tu peux me tutoyer tewfik, c'est plus simple :_)

Edited by assilabox
Link to post
Share on other sites

 

snmp

Ah oui, j'ai oublie... il est possible aussi de récolter les informations snmp a partir des routeurs de eepad (voir). Il faut vérifier s'il est possible de paramétrer une communauté automatiquement avec un script telnet ? Sinon demander aux utilisateur de le faire manuellement ?

 

Mesurer tous le trafic réseau au lieu d'un seul telechargement ou upload

Autre chose ... encore une idée qui me passe par la tete... ne serait-il pas plus adequat de recuperer tout le trafic reseau avec un application like la commande iftop ? Récupérer le débit de tous le trafic réseau permettra d'éviter les problèmes "human factor" liés a ce que l'utilisateur telecharge ... dans ce cas le seul pb qui risque de se poser c'est le cas de la saturation de l'upload. Pour le reste, on n'occasione aucune gene a l'utilisateur! Ca demanderait un peu plus de coding pour windows je suppose mais pour le libre iftop est deja la!

 

mode:"remue-meninges">

Edited by assilabox
Link to post
Share on other sites

bonsoir,

 

merci pour toutes ces suggestions, tres interessantes

je vais essayer de les integrer dans le brouillon

 

je tenterais une réponse détaillée dans mon prochain post incha'-allah

 

portez vous bien.

Link to post
Share on other sites

bonsoir tout le monde,

 

je viens d'uploader un deuxieme article qui concerne la meme proposition de projet open source. je vous invite à y jeter un oeil et apporter vos critiques.

 

Comme d'habitude, votre participation est indispensable pour la réussite de ce projet. Partagez ces documents dans votre entourage, apportez vos suggestions, corrections et avis.

 

Vous pouvez retrouver le document à l'adresse suivante :

 

 

0. Appel à contribution

http://www.scribd.com/doc/17262364/Appel-a-contribution-monitoring-distribue

 

1. Monitoring Distribué, Les Metriques

http://www.scribd.com/doc/18397714/Monitoring-distribue-1-Les-Metriques

 

Voici un extrait, pour aller vite :

 

Résumé

---------

 

Quoi : Choix des métriques, ou paramètres à mesurer afin d'avoir des échantillons quantitatifs sur lesquels un jugement sera fait quand à la qualité de la connexion.

 

Pourquoi : Les mesures sont indispensables afin d'avoir une appréciation et pouvoir archiver les résultats et les analyser par la suite.

 

Comment : Le choix des métriques doit être fait soigneusement. Aussi, une bonne architecture du projet permettra d'évoluer facilement lorsque de nouveaux paramètres sont amenés à être ajoutés. De plus, la façon de mesurer est très importante.

 

 

 

Assilabox :

 

- concernant le language de programmation : le language n'est pas tres tres critique. je souhaite que ce soit un language script plutot que qlq chose de compilé pour bien des raisons. je suis entrain de penser a une architecture du moteur qui incha'-allah rendera l ecriture des tests indépendante du langage choisi, plus sur ça plus tard.

 

- pour l'idée de voir le traffic au lieu de mesurer tout court : c est bien et c est pas bien. c est bien car non obstrusive, on touche pas on est passifs on regarde et on note. c est pas bien car lorsque l activité n est que navigation, on ne verrait que des successions de montagnes sur nos graphs. la plus part des objets html sont de faibles tailles en comparaison avec la bande passante disponible, tres souvent il ne font pas arriver le systeme à sa reponse permanente (et donc on ne peut pas voir les vrai valeurs max que l'on peut atteindre). par contre il est bien de voir ce genre de traffic pour déduire d autres parametres comme le rtt (en calculant par exemple le temps entre l aller d un packet (identifié par son port source destination numero de sequence) et le packet en retour (qui sera donc un ack plus data eventuelles avec meme signaure)).

 

- le snmp est une excellente idée, je retiens ^^

 

pour introduire un peu ce qui va suivre, mon idée est de construire un framework, comme dit précédement. Je pense donc mettre la spécification d'une sorte de mini language, qui sera on-top d'un language script, et qui permettra de scripter les tests

 

dans ma vision, nous avons : les metrics, leurs options, et leurs transformations

au niveau du coeur du programme, on aura des primitives, et un mini language

les tests seront sous forme de fichier macros, qui combinent les primitives entre elles, en associants des options, et en les modelant grace aux transformations

 

ce matin je m'amusais a construire une grammaire pour un tel mini language, quelque chose dans le style (rien de définitif, je ne fais que spéculer) :

 

# ceci est un commentaire ^^

begin test

# exemple de script pour engine test

set target = 82.101.136.29

# target; étant une option d une primitive

ping target repeat 10 put in stack

# ping étant une primitive

mean stack

# mean: moyenne; une transformation sur le résultat d une primitive (ici, ping)

testcredibility

savereport

sendreport

end test

 

le point le plus interessant d avoir un mini language, serait d une part d ecrire les tests sans avoir connaissance du coeur du programme, de ne pas forcément maitriser le langage du programme, de facilement ecrire de nouveau tests a effectuer, d avoir des procédures lisibles, de permettre a un plus grand nombre de participer

 

sans mini language : contributeurs possibles : developpeurs dans le langage choisi, utilisateurs testeurs

 

avec mini language : contributeurs possibles : developpeurs du coeur, developpeurs des primitives, redacteurs de tests, testeurs de programmes, contributeurs de nouvelles façon de tester

 

l interet me semble evident, j attend vos avis sur la question

 

plus sur ça plus tard, avec un article un peu plus propre + spécifications

 

sur ce

portez-vous bien.

Link to post
Share on other sites

Salam,

 

J'ai quelques remarques suite a la lecture de ton document :

 

Tout d'abor c'est un excellent document ... sa lecture était agréable.

 

Concernant le signal sunosoidal en électronique:

Ca paraîtra anodin mais il serait peu être utile de savoir que pour effectuer les mesure sur ce type de signaux on realise d'abord un redressement par un pont de diodes afin de mesurer la valeur absolue du signal ce qui rendra l'information de la composante négative utile

 

Dans smokeping, en plus de la "Déviation standard" les mesures suivantes sont effectuées:

 

  • Nombre de paquets perdus
  • Temps de réponse max
  • Temps de réponse médian

Concernant le ping :

Le ping dépend aussi de la taille du paquet envoyé par le ping lui même:

ping -s 10 google.com

et

ping -s 500 google.com

ne donnent pas les mêmes résultats (respectivement):

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8996ms
rtt min/avg/max/mdev = 188.534/192.612/196.576/2.244 ms

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8996ms
rtt min/avg/max/mdev = 260.703/265.241/272.069/3.201 ms

Donc c'est un paramètre a prendre en compte dans la mesure (surtout que la taille par défaut du paquet envoyés par la commande ping risque de dépendre du système d'exploitation?)

 

Concernant la vérification DNS...

Vu que le nombre de serveurs DNS est limité et est bien connu, les requettes de vérifications DNS pourraient se faire depuis deux ou trois machines au lieu de les faire depuis les clients testeurs (Toujours dans un soucis d'interoperabilite , comme il est le cas dans le service smokeping proposé pour surveiller en permanence le réseau des DSLAM et serveurs des FAIs)

 

A++

Link to post
Share on other sites

Assilabox: merci d'avoir pris la peine de lire et commenter

 

ok pour le redressement du signal, bonne idée ^_^

 

>> (surtout que la taille par défaut du paquet envoyés par la commande ping risque de dépendre du système d'exploitation?)

 

ça dépend, si on utilise la commande du systeme (oui) ou si on "craft" nous meme les packets icmp (au choix)

si on utilise la commande du systeme, il faudra parser, et comme les systeme ne sortent pas de la meme façon (mais sur un format humainement similaire), ça demandera plus de tests/validations

 

pour les dns, c'est une bonne idée en effet; elle souffre cependant des défauts suivants (à mon sens) :

 

- si les quelques machines responsables du monitoring cessent de monitorer, les données ne sont plus dispo (les machines peuvent perdre la connection à internet; leur maintainer qui ne veux/peux plus les faire fonctionner pour ce but, pannes electriques, ...)

 

- la mesure faite ainsi ne représente que le "point de vue" de ces quelques machines (géographique, réseau, dslam), et c'est ce qu'utiliseront les isp pour assimiler ces mesures la à des aleas et à les annuler.

 

par contre, en utilisant un monitoring distribué, en testant les dns (et le reste) de plusieurs points reseau, de plusieurs endroits on evite ces lacunes, c'est l'equivalent d'un sondage (automatique)

 

bien entendu, rien n'empeche de commencer à faire du centralisé, pour ensuite évoluer, ton idée me semble fort interessante et on commencera deja à avoir une idée sur le uptime du service et des serveurs

 

aucune inquietude quand au déni de service, car les tests au niveau de cette application aura un mécanisme de scheduling, pour programmer les tests les plus intensifs moins souvent (chaque 5m, chaque 30m, ...)

 

aussi, en suivant ton conseil, j'ai ouvert une page google code pour ce projet

j'ai pris la liberté de choisir un nom : ispwatch, le nom changera peut être

 

vous pouvez consulter la page du code ainsi q'un mini wiki à l'adresse suivante :

 

http://code.google.com/p/ispwatch

 

dans le menu source, vous pourrez trouver deux trois scripts,

en m'amusant j'ai fais deux trois fonctions histoire de commencer à écrire quelquechose

 

en parlant de scripts, j'ai (par défaut) choisi de commencer à coder en python, ceci dit, ne vous censurez pas, codez dans n'importe quel language qui vous conviens (php, perl, ruby,...)

 

je pense à :

 

- ouvrir des branches pour les programmes clients pour chaque language proposé

- translater en python les fonctions des autres language si la progression est supérieur

 

voila voila

 

Encore une fois, j'invite tout le monde à poster les commentaires et propositions, aucune auto censure, postez ce qui vous passe par la tête, ça profitera certainement à l'ensemble

 

à bientot j'espere (priez pour moi, période coupe-tete)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...