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.

Répondre à