On Sun, Mar 31, 2002 at 12:21:47PM -0800, MuTECH wrote: > Ouaa �a � papoter dur pendant le temps ou je faisait connaissance avec > Felix.
> >ATM est enooorme, complexe, difficile a depanner. > >c'est un empilement de couche interdependante, une lasagne > >complete a lui tout seul. > >pense au jour ou il y a une interruption sur ton reseau, comment > >trouver la panne. > > J'aime assez bien ce genre de d�fis et puis si l'on veut que cela avance il > bien faut de temps en temps sortir des solutions toutes faites. euh voui mais la non! :) chtexpliquerai > >> Comme je l'ai signal� pr�c�demment je ne suis pas persuad� que l'on > >puisse > >> sur une machine normale router et avoir le firewall sans qu'elle soit � > >> genou ! Car il me semble qu'avec de l'ATM ou de l'Ethernet ainsi qu'une > > > >oh en terme de performance, je pense pas que ce soit un probleme. > >par contre pour des questions de gestions, ca peut etre une bonne > >chose de mettre ces deux fonctions sur deux machines separees. > > C'est � se niveau que cela cloche car si l'on passe par une gestion du > routage classique sur un syst�me multitache, celui-ci ne peut pas assurer > que le traitement se ferra pendant un temps d�terminer, il va rien a peter, le noyau gere une tache 'noyau' en prenant tout le temps qu'il faut, les interruption reseaux 'prenne le dessus' sur les applications qui tournent en user-space. a moins d'appliquer le patch 'preeamptable kernel', qui doit donc etre a eviter sur un routeur linux. et les ordres de grandeurs: forwarder un paquets, c'est quelques microsecondes de CPU. > obligatoirement d�pendre de la charge du syst�me. Cette fonction et > l'apanage des syst�me temps r�el (QNX, etc). On peut �ventuellement bah c'est ce qu'il ecrive sur leur papier glasser pour les vendres. souvent on pense a utiliser un cannon pour tuer une mouche par rapport a l'informatique 'embarquee' (pas qu'elle d'ailleur), on croit que derriere le capot se cache un truc DINGUE et quand tu fouilles un peu, c'est la douche froide tellement t'aurai pas oser mettre ca sur le marche toi-meme. mais non, le routage, c'est vraiment pas l'apanage des OS temps reels. il suffit de soigner le traitement d'interruption venant d'une serie d'interface reseau. c'est a ca que sert un noyau monolithique (entre autre). Linux, en terme de latence de forwardnig, s'en sort tres bien (faut pas utiliser le driver IDE avec les parametres par defaut - toujours desactiver le masquage des interruption sur le driver IDE ou mieux ne pas utiliser IDE). > appliquer certain patche sur le noyau afin de favoriser le temps > d'activation de certaine taches mais cela ne fait pas grande diff�rence. Le justement pas, en tout ca le patch preeamptable kernel, je pense que ca doit avoir l'effet inverse pour les temps de forwarding (a charge vachement elevee neanmoins). > seul moyen d'assurer une certain temps de transfert des paquets et de faire > l'int�graliter du processus par l'activation d'un code de fa�on contr�l�e > et que celui-ci ne puisse pas �tre interomput de fa�on incontrol�e comme > par example dans la gestion des interuptions hard. Ceci entraine > naturelement un risque assez important au niveau du d�veloppement car on > est vraiment � un bas niveau alors les plantages risques d'avoir un impact > tr�s style �cran bleu de NT voir pire (je sais par exp�rience). > C'est pour �a que le FDDI me semblait interessant car celui-ci est vraiment > pr�vu pour travaill� en anneau et qu'il semblerai que quelque soit la > charge du syst�me le r�seau continue � fonctionner de fa�on presque > identique car c'est la carte qui s'occupe de faire passer le jeton d'une > paire de fibre � l'autre si le destinataire pas cette m�me machine. De plus oui tout a fait. ca representait un sacre avantage a l'age d'or du FDDI car les stations de travail avait au mieux un 68030 pour lequel, traiter des interruption d'une carte 10Mbit/s vers une seconde intf aurait bouffe 30% du CPU a lui tout seul. avec un OS pas trop mal ecrit et les CPU actuel, le taux d'interruptions devient un probleme autour de 500Mbit/s a 1Gbit/s (avec un MTU moyen de 500 bytes). c'est pour ca que certains fabricant de matos GigabitEthernet ont propose de passe a un MTU de 9000 bytes, ca diviserait le taux d'interruption par 6 (par rap. a 1500). > les cartes g�rent �galement la rupture de l'anneau. oui peut-etre le temps de failover est plus rapide qu'avec RIP ou OSPF. > Pour ce qui est de l'ATM et de l'ethernet il probable donc que la charge du > syst�me puisse avoir influence non n�gligable sur le comportement global du > r�seau en anneau, ce qui n'est pas g�nial si pour limit� les frais on place > un firewall et �ventuellement un proxy sur la m�me machine que celle qui > fait le routage. > Il est possible que certaine carte qui on deux int�rfaces ATM que j'ai > aper�ues impl�mentes des fonctionalit�s proche du FDDI mais je n'ai pas > l'exp�rience pour le confirmer. non, faut du do du ble du flouse de la thune pour se payer un bon gros switch des que tu veux le moindre dynamisme de la part d'un reseau ATM. ou alors bidouiller avec linux-atm. bonne chance. > >ah mon avis, ethernet est plus 'mainstream' donc tu auras > >moins de probleme a trouver des gens capable de comprendre > >son fonctionnement, ca sera moins cher a entretenir, plus > >rapide a depanner, moin couteux aussi, et ethernet > >est maintenant capable d'avoir different niveau de qualite > >de service (avec 802.1p, a utiliser en conjonction avec une couche > >QOS au niveau IP), une isolation des traffic (les vlan 802.1q). > > Je le pense aussi et puis on aura toujours la posibilit� dans 3 ou 4 ans de > planter de nouvelles cartes plus p�rformantes et o� mieux adapt�es sur un > ordianteur d'ocasion. Et puis il est fort probable que je me casse un peut > trop la t�te pour enfin ne devoir pass� que 1 Mbs car on aurra pas moyen de > lou� une bande passante plus grande chez SWITCH. ah oui pour 1 Mbit/s y a pas de probleme de performance avec des routeur linux et du fast ethernet pour utiliser un media fibre :) 1Mbit/s ca fait 83 interruption a la seconde (MTU de 1500 bytes). le timer du noyau en declanche 100. sur certains OS 1000 a la secondes. donc ca va pas etre un probleme. (concretement, tu peux pousser 400Mbit/s a travers un routeur linux de nos jour - a peu pres identique aux perf. d'un cisco 7200 / 7500.) > Pas de probl�me, tu me dis une date, un lieu et heure ? > A propos tu habite o� ? echandens, mais je monte volontier de ton cote, ca fait une paie que j'ai pas vu de sapins :) je te redis quand, plutot la semaine prochaine. > D'autres personnes sont int�ress�es ? Cela me permettrai peut �tre de > rencontrer d'autres fameux gourous (Salut Marc) et l'on pourai se faire une > bouffe. -- Philippe Strauss http://philou.ch/ L'indiff�rence est le plus grand risque de notre temps, la forme civilis�e de la cruaut�. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
