FDDI ou ATM pour un backbone ?
Actuellement je fais une évaluation pour établir un petit backbone fibre d'une dizaine de Km avec 4 points d'entrées que je voudrai gérer avec des machines linux. Dans un premier temps je suis arriver à la conclusion que l'ATM avec une redondance dans les routes (un peut comme le token-ring) était un bon choix mais après réflexion, il se pourrait que le FDDI-II ne soit pas à négliger car il est plus adapter à la gestion avec redondance de route et devrai demander moins de CPU aux machines des points d'entrées). Je voudrai savoir si quelqu'un a une expérience ou une opinion sur ces différents protocoles et leurs impactes sur le temps CPU utilisé ainsi que les temps de latences et éventuellement leur pérennité et le support de média comme que la vidéo ou le son avec ces protocoles. J'ai rapidement abandonné la voie du Giga Ethernet car il semble que physiquement il ne peut pas établir une ligne de plus de 5 km sur des fibres mono mode, j'ai également oublié volontairement tous les protocoles qui n'étant pas ou mal supporter par FreeBSD et où Linux. Donc si quelqu'un veut discuter le bout de gras je suis tout ouvert à la conversation. Martial Guex MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users)
Re: FDDI ou ATM pour un backbone ?
bonjour, On Sat, Mar 30, 2002 at 04:45:55AM -0800, MuTECH wrote: > Actuellement je fais une évaluation pour établir un petit backbone fibre > d'une dizaine de Km avec 4 points d'entrées que je voudrai gérer avec des > machines linux. Dans un premier temps je suis arriver à la conclusion que > l'ATM avec une redondance dans les routes (un peut comme le token-ring) > était un bon choix mais après réflexion, il se pourrait que le FDDI-II ne > soit pas à négliger car il est plus adapter à la gestion avec redondance de > route et devrai demander moins de CPU aux machines des points d'entrées). > Je voudrai savoir si quelqu'un a une expérience ou une opinion sur ces > différents protocoles et leurs impactes sur le temps CPU utilisé ainsi que > les temps de latences et éventuellement leur pérennité et le support de > média comme que la vidéo ou le son avec ces protocoles. J'ai rapidement > abandonné la voie du Giga Ethernet car il semble que physiquement il ne > peut pas établir une ligne de plus de 5 km sur des fibres mono mode, j'ai > également oublié volontairement tous les protocoles qui n'étant pas ou mal > supporter par FreeBSD et où Linux. > Donc si quelqu'un veut discuter le bout de gras je suis tout ouvert à la > conversation. mouai tu veux du consulting a l'oeuil quoi :) oublie ATM et FDDI, ca va te couter un max et tu sais pas vers quoi tu vas en terme de gestion (pour ATM), par contre il y a une flopee de produits fast ethernet sur fibre optique qui tirent 100km sans broncher, nbase etait un des premiers a commercialise ca, depuis 3 ans il y a plethore d'offre dans ce domaine. (j'ai mis de tels transceiver en place sur un lien de 110km il y a 4 ans et ca marche tjr a merveille). et il y a aussi des transceiver qui permettent de transmettre du gigaE sur 20 a 100 km. tout vendeur de boites en metal genre azlan, anixter, saura t'en trouver a la pelle. (ca n'a pas grand chose a voir avec linux, viens sur [EMAIL PROTECTED] nous raconter ton projet avec une fibre nue ca nous interesse, c'est une liste de fada de reseau 'grassroot' :) aplus > Martial Guex > > -- > MuTECH > Martial Guex > Rue des Alpes > 1452 Les Rasses > Switzerland > > Phone : +41 24 454 46 35 > Fax. : +41 24 454 46 32 > Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- 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.
Re: FDDI ou ATM pour un backbone ?
At 09:33 30.03.02, you wrote: >bonjour, > >On Sat, Mar 30, 2002 at 04:45:55AM -0800, MuTECH wrote: > > Actuellement je fais une évaluation pour établir un petit backbone fibre > > d'une dizaine de Km avec 4 points d'entrées que je voudrai gérer avec des > > machines linux. Dans un premier temps je suis arriver à la conclusion que > > l'ATM avec une redondance dans les routes (un peut comme le token-ring) > > était un bon choix mais après réflexion, il se pourrait que le FDDI-II ne > > soit pas à négliger car il est plus adapter à la gestion avec > redondance de > > route et devrai demander moins de CPU aux machines des points d'entrées). > > Je voudrai savoir si quelqu'un a une expérience ou une opinion sur ces > > différents protocoles et leurs impactes sur le temps CPU utilisé ainsi que > > les temps de latences et éventuellement leur pérennité et le support de > > média comme que la vidéo ou le son avec ces protocoles. J'ai rapidement > > abandonné la voie du Giga Ethernet car il semble que physiquement il ne > > peut pas établir une ligne de plus de 5 km sur des fibres mono mode, j'ai > > également oublié volontairement tous les protocoles qui n'étant pas ou mal > > supporter par FreeBSD et où Linux. > > Donc si quelqu'un veut discuter le bout de gras je suis tout ouvert à la > > conversation. > >mouai tu veux du consulting a l'oeuil quoi :) Houai un peu car c'est ce que je fais actuellement afin de promouvoir le net chez-moi. Mon premier objectif était d'avoir une ligne rapide qui arrive chez-moi. J'avais plusieurs possibilités tel que rester en ADSL, avoir une ligne p-p HF jusqu'a l'EIVD ou j'ai des contacts puis de louer une bande passante chez Switch ou Cablecom ou enfin d'essayer de promouvoir un backbone entre Sainte-Croix et Bullet ou les lignes sont trop atténuées pour permettre l'ADSL. De plus il est peut probable qu'un fournisseur d'accès le fasse étant donné le formidable potentiel de client (vivez dans une petite localité qu'il disait, enfin on a au moins les sapins). Par ailleurs j'ai du boulot assurer jusqu'à la fin de l'année alors ce n'est vraiment pas sur ce projet que je compte pour gagné ma vie. D'ailleurs si une où plusieurs personnes veulent se proposer afin de se faire du fric, pas de problème et je me propose même de leurs donné un coup de main gratuitement. Tu es intéressé ? Bon pour prendre les devants j'ai sacrifié presque une semaine afin de trouver le compromis entre la bidouille et le professionnel pour que tout le monde soit satisfait (Commune et clients potentiels) aussi bien financièrement que fonctionnellement pour ce backbone. Du coup je me suis dît que faire les points d'entrées sur du Linux ou du FreeBSD permettrai de faire le pied de nez à ceux qui proposent systématiquement du matériel genre CISCO parce qu'ils ont toujours fait ça et que cela fonctionne très bien. De plus cela pourrai être moins chère. A titre d'information pour les candidats, il ne faut pas être trop bas au niveau prix autrement les administrations nous prennent pour des rigolos et oublie volontairement notre offre (elles sont trop habituées au dumping des boîtes avant leur crash). >oublie ATM et FDDI, ca va te couter un max et tu sais pas >vers quoi tu vas en terme de gestion (pour ATM), par contre Peut-tu préciser le problème au niveau de la gestion de l'ATM ? >il y a une flopee de produits fast ethernet sur fibre optique >qui tirent 100km sans broncher, nbase etait un des premiers a >commercialise ca, depuis 3 ans il y a plethore d'offre dans ce domaine. >(j'ai mis de tels transceiver en place sur un lien de 110km il y a 4 ans >et ca marche tjr a merveille). 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 boucle de routage redondante tous les paquets doivent passer d'une carte à l'autre de l'ordinateur à l'exception des paquets à destination de cette machine. Et je ne pense pas à la vue du prix de la fibre et de la pose qu'une topologie en étoile avec un switch au centre soit moins chère et de plus cette solution n'autoriserait l'ajout d'un point que par l'utilisation de deux fibres supplémentaires et de réouvrir des tranchées. Peut-tu confirmer que cela marche en Ethernet ou avec un transceiver ? Enfin pour le prix, rien ne m'empêche d'envisagé la possibilité de l'usage de l'ATM où le FDDI (je croix qu'il faut compter environ 2 x ~1500.00 CHF les 2 cartes ATM ou FDDI pour chaque point d'entrée, c'est ça ?) car pour le moment je fais l'évaluation gratuitement. Et de plus cela me permettra d'avoir une idée des prix pour d'autre choix que de l'ethernet. Il semble également qu'avec l'Ethernet il soit difficile d'assurer des temps de latences de façon correcte (peut-être avec de l'ipv6 mais là c'est très testing) ce qui n'est pas idéal si l'on veut passer des infos comme de l'audio
Re: FDDI ou ATM pour un backbone ?
On Sat, Mar 30, 2002 at 05:29:42PM -0800, MuTECH wrote: > At 09:33 30.03.02, you wrote: > > >mouai tu veux du consulting a l'oeuil quoi :) > > Houai un peu car c'est ce que je fais actuellement afin de promouvoir le > net chez-moi. > Mon premier objectif était d'avoir une ligne rapide qui arrive chez-moi. > J'avais plusieurs possibilités tel que rester en ADSL, avoir une ligne p-p > HF jusqu'a l'EIVD ou j'ai des contacts puis de louer une bande passante > chez Switch ou Cablecom ou enfin d'essayer de promouvoir un backbone entre > Sainte-Croix et Bullet ou les lignes sont trop atténuées pour permettre > l'ADSL. De plus il est peut probable qu'un fournisseur d'accès le fasse > étant donné le formidable potentiel de client (vivez dans une petite > localité qu'il disait, enfin on a au moins les sapins). :) c'est sympa comme projet! > Par ailleurs j'ai du boulot assurer jusqu'à la fin de l'année alors ce > n'est vraiment pas sur ce projet que je compte pour gagné ma vie. > D'ailleurs si une où plusieurs personnes veulent se proposer afin de se > faire du fric, pas de problème et je me propose même de leurs donné un coup > de main gratuitement. Tu es intéressé ? me proposer pour l'ensemble du projet, je pense pas, mais y apporte un coup de main, volontier! > Bon pour prendre les devants j'ai sacrifié presque une semaine afin de > trouver le compromis entre la bidouille et le professionnel pour que tout > le monde soit satisfait (Commune et clients potentiels) aussi bien > financièrement que fonctionnellement pour ce backbone. Du coup je me suis > dît que faire les points d'entrées sur du Linux ou du FreeBSD permettrai de > faire le pied de nez à ceux qui proposent systématiquement du matériel > genre CISCO parce qu'ils ont toujours fait ça et que cela fonctionne très > bien. De plus cela pourrai être moins chère. A titre d'information pour les oui tout a fait, linux est utilise pour remplace des cisco7500 avec un plein succes comme routeur IP pur, cf. John Fraizer sur la mailing-list de zebra, un demon de routage GPL pour les *nix. > candidats, il ne faut pas être trop bas au niveau prix autrement les > administrations nous prennent pour des rigolos et oublie volontairement > notre offre (elles sont trop habituées au dumping des boîtes avant leur > crash). > > >oublie ATM et FDDI, ca va te couter un max et tu sais pas > >vers quoi tu vas en terme de gestion (pour ATM), par contre > > Peut-tu préciser le problème au niveau de la gestion de l'ATM ? 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. > >il y a une flopee de produits fast ethernet sur fibre optique > >qui tirent 100km sans broncher, nbase etait un des premiers a > >commercialise ca, depuis 3 ans il y a plethore d'offre dans ce domaine. > >(j'ai mis de tels transceiver en place sur un lien de 110km il y a 4 ans > >et ca marche tjr a merveille). > > 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. > boucle de routage redondante tous les paquets doivent passer d'une carte à > l'autre de l'ordinateur à l'exception des paquets à destination de cette > machine. Et je ne pense pas à la vue du prix de la fibre et de la pose > qu'une topologie en étoile avec un switch au centre soit moins chère et de ah je pensais utilise du fast ethernet entre les 4 points en anneau, comme interface point-a-point entre deux routeurs linux, 4 fois. ca suppose que ton reseau transporte uniquement de l'IP. ce qui n'etait pas forcement ton but. autrement, la meme chose peut-etre fait entre 4 switch ethernet en bridging, si tu veux transporter autre chose que IP. a voir en fonction des besoins. > plus cette solution n'autoriserait l'ajout d'un point que par l'utilisation > de deux fibres supplémentaires et de réouvrir des tranchées. Peut-tu > confirmer que cela marche en Ethernet ou avec un transceiver ? tout a fait, la solution en etoile n'est pas appropriee, heureusement c'est aussi tout a fait faisable en anneau. > Enfin pour le prix, rien ne m'empêche d'envisagé la possibilité de l'usage > de l'ATM où le FDDI (je croix qu'il faut compter environ 2 x ~1500.00 CHF > les 2 cartes ATM ou FDDI pour chaque point d'entrée, c'est ça ?) car pour je sais pas, mais ca doit pas eviter d'acheter des transceiver multi-mode courte distance - mono-mode longue distance qui vont couter a peu pres autant que les transceiver ethernet - mono-mode longue distance, la plupart des cartes sont faites pour ce brancher
Re: FDDI ou ATM pour un backbone ?
On Sun, 31 Mar 2002, Philippe Strauss wrote: > ATM est enooorme, complexe, difficile a depanner. > c'est un empilement de couche interdependante, une lasagne > complete a lui tout seul. Oui. Maintenant, les avantages d'ATM (absence de collision: on n'insère une trame que lorsqu'il y a un `slot' sur le réseau) ne compensent-ils pas en partie, dans un réseau partagé, ses inconvénients ? Ou alors on n'utilise qu'ATM que pour communiquer entre deux routeurs, et les problèmes de collisions locale restent ? Quelles sont les autres solutions pour éviter les collisions sur le dernier tronçon de la liaison vers l'abonnée ? merci -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Re-bonjour, Pour demain au Jura, cela est compromis, le Jura n'ouvre pas avant le 3 avril. La Poste, à la rue Centrale sera fermé demain lundi, dès lors, il ne reste que cet après-midi... A+! -- Félix Hauri -Informaticien consultant- <[EMAIL PROTECTED]> Tél: (+41/0) 24 454 54 04 - 079 703 15 36 - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Sun, 31 Mar 2002, Félix Hauri wrote: > Re-bonjour, Oups! Ce message ne vous étais pas destiné! Vous aviez compris;-) Milles excuses! Bonnes Fêtes!!! -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Sun, Mar 31, 2002 at 01:32:52PM +0200, Marc SCHAEFER wrote: > On Sun, 31 Mar 2002, Philippe Strauss wrote: > > > ATM est enooorme, complexe, difficile a depanner. > > c'est un empilement de couche interdependante, une lasagne > > complete a lui tout seul. > > Oui. Maintenant, les avantages d'ATM (absence de collision: on n'insère > une trame que lorsqu'il y a un `slot' sur le réseau) ne compensent-ils pas > en partie, dans un réseau partagé, ses inconvénients ? chaque fois que je parle d'ethernet, c'est en considerant ethernet en mode full duplex, qui n'utilise pas csma-cd, donc qui ne connait pas de collision: il y a une paire de fil pour l'emission, une paire separee pour la reception. les collisions peuvent survenir a l'interieur d'un switch ethernet, tout comme dans un switch ATM des cellules peuvent etre dropee. tout bon switch et dimensionne pour rendre ces cas la impossible ou tellement marginal qu'imperceptible. ca n'empeche pas d'autre cas de perte de paquet 'normaux' par congestion du genre: deux machines chacune derriere un port 100Mbit/s envoie un flux de 100Mbit/s a une troisieme en 'reception'. la troisieme machine ne verra que la moitie de la somme des traffic. mais c'est normal. c'est une question de dimensionnement des branches du reseau. ATM sur le LAN, ca n'a pas ete un succes, il s'est fait une petite place.. quand le fast-ethernet n'existait pas et qu'ATM avait deja un debit de 155Mbit/s pas trop cher. ATM a ete concu par les telcos pour etre la partie large bande de RNIS, internet a soufle l'aspect 'services integres', et ATM est une bonne technologie pour le transport de la voix (telephone) chez les operateurs. Dans le domaine data, il ne lui reste plus grand chose. le fait d'avoir une taille de cellule fixe permet de faire des calculs d'allocations de bande passante a l'interieur d'un switch qui permettent de respecter des contraintes de QOS plus facilement qu'avec des trames a taille variable, mais un grand nombre de switch ethernet segmentent les trames en cellules de taille fixe afin d'avoir les memes avantages. bref, il y a eu convergence entre un bon switch ethernet et un switch ATM, et il n'y a plus beaucoup de raison desormais de partir sur ATM pour du transport de donnees. surtout en milieu rural, ca me parait legerement ''overkill'' mais on sait jamais, des fois on tombe sur des besoins qu'on imaginait pas. > Ou alors on n'utilise qu'ATM que pour communiquer entre deux routeurs, et oui c'est tres courant, entre des equipements 'backbone' et 'aggregation', ATM est un bon media pour l'aggregation, tu peux y retrouver un canal virtuel par client, courant sur les equipement Cables et ADSL cote station de tete ou central respectivement. > les problèmes de collisions locale restent ? Quelles sont les autres > solutions pour éviter les collisions sur le dernier tronçon de la liaison > vers l'abonnée ? les collisions vers l'abbones n'existes plus, ca a seulement existe avec les modems cable zenith, et les points a point xDSL entre deux LAN sans routeur entre deux. les autre technologies cables arbitrent ''qui peut emettre quand'' de maniere explicite, et dans le cas plus simple qui nous concerne, le switch ethernet ne connait pas de collision sur un lien full-duplex. > merci > > > -- > http://www-internal.alphanet.ch/linux-leman/ avant de poser > une question. Ouais, pour se désabonner aussi. -- 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.
Re: FDDI ou ATM pour un backbone ?
On Sun, 31 Mar 2002, Philippe Strauss wrote: > chaque fois que je parle d'ethernet, c'est en considerant > ethernet en mode full duplex, qui n'utilise pas csma-cd, donc > qui ne connait pas de collision: il y a une paire de fil pour > l'emission, une paire separee pour la reception. et deux machines connectées directement (ou une machine <--> un switch). > les autre technologies cables arbitrent ''qui peut emettre quand'' > de maniere explicite, et dans le cas plus simple qui nous concerne, > le switch ethernet ne connait pas de collision sur un lien > full-duplex. Y-a-t-il aussi des technologies où le canal d'émission (vers l'usager) est partagé (mais contrôlé par un seul émetteur), et le canal de réception est en multiplexe fréquentiel (plages de fréquences allouées à chaque abonné), ou est-ce géré plutôt en multiplexe temporel ou via un autre protocole, genre canal de contrôle à accès partagé et CSMA/CR p.ex. sur adresse MAC ? As-tu une idée d'une documentation qui décrirait cela ? PS: les Zenith marchent toujours pas mal ainsi que tes configs fibre :) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Sun, Mar 31, 2002 at 04:22:48PM +0200, Marc SCHAEFER wrote: > On Sun, 31 Mar 2002, Philippe Strauss wrote: > > > chaque fois que je parle d'ethernet, c'est en considerant > > ethernet en mode full duplex, qui n'utilise pas csma-cd, donc > > qui ne connait pas de collision: il y a une paire de fil pour > > l'emission, une paire separee pour la reception. > > et deux machines connectées directement (ou une machine <--> un switch). dans les deux cas. faut configurer chaque interface pour etre sur qu'elles sont bien en full duplex. > > les autre technologies cables arbitrent ''qui peut emettre quand'' > > de maniere explicite, et dans le cas plus simple qui nous concerne, > > le switch ethernet ne connait pas de collision sur un lien > > full-duplex. > > Y-a-t-il aussi des technologies où le canal d'émission (vers l'usager) est > partagé (mais contrôlé par un seul émetteur), et le canal de réception > est en multiplexe fréquentiel (plages de fréquences allouées à chaque > abonné), ou est-ce géré plutôt en multiplexe temporel ou via un autre > protocole, genre canal de contrôle à accès partagé et CSMA/CR p.ex. sur > adresse MAC ? plutot du multiplexage temporel, le GSM utilise du TDMA sur plusieurs bandes de frequences. mais pas une par utilisateur. le systeme de telephone mobile analogique americain etait du pure analogique mux en frequences. > As-tu une idée d'une documentation qui décrirait cela ? non, mais essaie peut-etre "GSM TDMA" sur google? pour le cable (multiplexage temporel et acces multiple gere de maniere centralisee par le recepteur de station de tete): une intro rapide a docsis1.1 (TDMA) http://wirelessman.org/tg1/mac/contrib/80216mc-99_02.pdf un projet qui a peut-etre inspire docsis1.1 (802.14) http://www.comsoc.org/livepubs/surveys/public/4q98issue/lin.html le (S)CDMA, permettant a plusieurs modem d'emettre *simultanement* (en utilisant des codes d'encryption different chacun, et distingable a la reception), c'est utilise sur les modems terayons et le docsis2. docsis2 utilisera deux technologies differentes dans le canal montant et descendant, mais toujours plutot TDM que mux frequentiel. en fait c'est TDM et SCDMA. > PS: les Zenith marchent toujours pas mal ainsi que tes configs fibre :) :) joli! (pour les zenith, ils se font ages pourtant :) > -- > http://www-internal.alphanet.ch/linux-leman/ avant de poser > une question. Ouais, pour se désabonner aussi. -- 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.
Re: FDDI ou ATM pour un backbone ?
At 09:52 31.03.02, you wrote: >On Sun, Mar 31, 2002 at 04:22:48PM +0200, Marc SCHAEFER wrote: > > On Sun, 31 Mar 2002, Philippe Strauss wrote: > > > > > chaque fois que je parle d'ethernet, c'est en considerant > > > ethernet en mode full duplex, qui n'utilise pas csma-cd, donc > > > qui ne connait pas de collision: il y a une paire de fil pour > > > l'emission, une paire separee pour la reception. > > > > et deux machines connectées directement (ou une machine <--> un switch). > >dans les deux cas. faut configurer chaque interface pour etre >sur qu'elles sont bien en full duplex. > > > > les autre technologies cables arbitrent ''qui peut emettre quand'' > > > de maniere explicite, et dans le cas plus simple qui nous concerne, > > > le switch ethernet ne connait pas de collision sur un lien > > > full-duplex. > > > > Y-a-t-il aussi des technologies où le canal d'émission (vers l'usager) est > > partagé (mais contrôlé par un seul émetteur), et le canal de réception > > est en multiplexe fréquentiel (plages de fréquences allouées à chaque > > abonné), ou est-ce géré plutôt en multiplexe temporel ou via un autre > > protocole, genre canal de contrôle à accès partagé et CSMA/CR p.ex. sur > > adresse MAC ? > >plutot du multiplexage temporel, le GSM utilise du TDMA sur plusieurs >bandes de frequences. mais pas une par utilisateur. >le systeme de telephone mobile analogique americain etait >du pure analogique mux en frequences. Il semble les premier réseaux "Natel C" était en fréquences. Par ailleur le mélange fréquence et TDMA est également utilisé sur les fibres à trés grandes bandes passante (10Tera) avec des lasers semi-conduteurs de différentes couleures. C'est également utilisé par Cablecom pour multiplexer les données et la télévision, un peut comme comme sur un cable coax d'antenne satelite. > > As-tu une idée d'une documentation qui décrirait cela ? > >non, mais essaie peut-etre "GSM TDMA" sur google? Le problème de la transmision de données par ondes radio et un peut comme sur l'ethernet car plusieurs intervenant peuvent tenter d'accédés au même moment. Seulement il faut rajouter une données suplémentaire (sorte de canal) qui est la fréquence sur laquelles tu travailles. Si tu veus quelques données sur les différents modes de transmitions de données par radio tu peut consulter quelques intro sur le sujet http://www.newwaveinstruments.com/resources/index.htm tel que le spread spectrum les méthodes de modulation etc. Si tu veut plus d'info on peut se voire (j'ai un peu bidouillé dans ce domaine). Fait attention c'est un monde ou tu as tendance à plongé très profond (un peu comme dans le grand bleu dans la scéne finale, je t'assure j'ai testé). >pour le cable (multiplexage temporel et acces multiple gere >de maniere centralisee par le recepteur de station de tete): > >une intro rapide a docsis1.1 (TDMA) >http://wirelessman.org/tg1/mac/contrib/80216mc-99_02.pdf > >un projet qui a peut-etre inspire docsis1.1 (802.14) >http://www.comsoc.org/livepubs/surveys/public/4q98issue/lin.html > >le (S)CDMA, permettant a plusieurs modem d'emettre *simultanement* >(en utilisant des codes d'encryption different chacun, et >distingable a la reception), c'est utilise sur les modems >terayons et le docsis2. > >docsis2 utilisera deux technologies differentes dans le canal >montant et descendant, mais toujours plutot TDM que mux frequentiel. >en fait c'est TDM et SCDMA. > > > PS: les Zenith marchent toujours pas mal ainsi que tes configs fibre :) > >:) joli! (pour les zenith, ils se font ages pourtant :) -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Ouaa ça à papoter dur pendant le temps ou je faisait connaissance avec Felix. Il va faloir un petit bout de temps pour que j'intégre mais je profite pour mettre mon grain de sel sur quelques points. At 02:47 31.03.02, you wrote: >On Sat, Mar 30, 2002 at 05:29:42PM -0800, MuTECH wrote: > > At 09:33 30.03.02, you wrote: > > > > >mouai tu veux du consulting a l'oeuil quoi :) > > > > Houai un peu car c'est ce que je fais actuellement afin de promouvoir le > > net chez-moi. > > Mon premier objectif était d'avoir une ligne rapide qui arrive chez-moi. > > J'avais plusieurs possibilités tel que rester en ADSL, avoir une ligne p-p > > HF jusqu'a l'EIVD ou j'ai des contacts puis de louer une bande passante > > chez Switch ou Cablecom ou enfin d'essayer de promouvoir un backbone entre > > Sainte-Croix et Bullet ou les lignes sont trop atténuées pour permettre > > l'ADSL. De plus il est peut probable qu'un fournisseur d'accès le fasse > > étant donné le formidable potentiel de client (vivez dans une petite > > localité qu'il disait, enfin on a au moins les sapins). > >:) > >c'est sympa comme projet! Je pense aussi > > Par ailleurs j'ai du boulot assurer jusqu'à la fin de l'année alors ce > > n'est vraiment pas sur ce projet que je compte pour gagné ma vie. > > D'ailleurs si une où plusieurs personnes veulent se proposer afin de se > > faire du fric, pas de problème et je me propose même de leurs donné un > coup > > de main gratuitement. Tu es intéressé ? > >me proposer pour l'ensemble du projet, je pense pas, mais y apporte >un coup de main, volontier! Merci, j'ai pris note. > > Bon pour prendre les devants j'ai sacrifié presque une semaine afin de > > trouver le compromis entre la bidouille et le professionnel pour que tout > > le monde soit satisfait (Commune et clients potentiels) aussi bien > > financièrement que fonctionnellement pour ce backbone. Du coup je me suis > > dît que faire les points d'entrées sur du Linux ou du FreeBSD > permettrai de > > faire le pied de nez à ceux qui proposent systématiquement du matériel > > genre CISCO parce qu'ils ont toujours fait ça et que cela fonctionne très > > bien. De plus cela pourrai être moins chère. A titre d'information pour > les > >oui tout a fait, linux est utilise pour remplace des cisco7500 >avec un plein succes comme routeur IP pur, cf. John Fraizer >sur la mailing-list de zebra, un demon de routage GPL pour les *nix. > > > candidats, il ne faut pas être trop bas au niveau prix autrement les > > administrations nous prennent pour des rigolos et oublie volontairement > > notre offre (elles sont trop habituées au dumping des boîtes avant leur > > crash). > > > > >oublie ATM et FDDI, ca va te couter un max et tu sais pas > > >vers quoi tu vas en terme de gestion (pour ATM), par contre > > > > Peut-tu préciser le problème au niveau de la gestion de l'ATM ? > >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. > > >il y a une flopee de produits fast ethernet sur fibre optique > > >qui tirent 100km sans broncher, nbase etait un des premiers a > > >commercialise ca, depuis 3 ans il y a plethore d'offre dans ce domaine. > > >(j'ai mis de tels transceiver en place sur un lien de 110km il y a 4 ans > > >et ca marche tjr a merveille). > > > > 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 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 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 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 ç
Re: FDDI ou ATM pour un backbone ?
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 d
Re: FDDI ou ATM pour un backbone ?
At 08:27 03.04.02, you wrote: >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. Moi j'était dans l'ordre de 10 milisec, Je m'était basé sur des user-space. Il n'y pas, il faut de l'expérience. > > 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. C'est bon à savoir ! >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). Il faut vraiment que je te voie histoire que je te fasse cracher plus de truc de ce genre. J'espère pouvoir te rendre la pareil dans d'autre domaine. > > 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 > > sys
Re: FDDI ou ATM pour un backbone ?
> >(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.) > > Mais pourquoi on achete du CISCO ? Juste pour payé un prix fou pour la mise > à jour ou l'ajout de la fonctionalité suplèmentaire que l'on avait pas > prévu ! oh le fait que linux ou un *BSD soit a la hauteur de ce point de vue la, en totalement libre, c'est recent. y a meme pas de date precise, c'est un mouvement actuel, on est dedans. le logiciel de routage 'zebra' est la seule suite supportant BGP et OSPF en license GPL, les deux protocoles de routage important pour l'ensemble du net. Je l'avais teste il y a deux ans, ca marchait deja, bien qu'il y avait encore pas mal de bug. Maintenant il est pas mal stable. Le hardware cisco reste mieux concu pour transmettre des paquets d'une interface a une autre. le software cisco.. disons que la vague du libre a rehausse quelque peu le niveau de fiabilite de ce qu'attendent les clients payant une license logiciel. IOS, le firmware cisco, en terme de fiabilite, c'est entre novell netware et window95. La comparaison n'est pas choisie par hasard, IOS a aussi un model de gestion memoire simple, sans pagination, sans protections. J'imagine pour des questions de perf. Ca a ete concu pour tourner sur des ordinateurs avec un processeur central et des interfaces bien interconnectees au bus memoire (un routeur, ce n'est que ca), le CPU allant du 68360 au MIPS R7000, donc la gestion memoire, c'est reste leger pour rester portable aussi. Mais un MIPS R7000, en force brut, ca c'est fait rattraper par les Pentium II et AMD Athlon, meme avec le bus memoire d'un pc qui n'est pas la panacee. Pour le software cisco, tout ecrit en C, tant que les developpeurs sont content de touiller leur code ca va, des que les tensions entre marketing et developpement (demande d'ajout de trop de nouveaute dans un laps de temps trop court) atteigne un certains points, ca se casse la gueule. la qualite du soft livre au client devient de la merde. Il y a 3 - 4 ans la stabilite etait nickel (comme un netware oublie dans un coins depuis 5 ans), c'etait les version 11.1CC. Petit-a-petit, ca c'est degrade. Bon quand tu regardes le nombre de boites qu'ils ont rachetes et vaguement ''integres'' a la ligne de produit, y a rien d'etonnant. Ca restera peut-etre comme un fabricant de telephone. ''tse gamin quant j'etait jeune, j'avais configurer des tas de routeurs cisco'' ''quoi, cisco, comme les telephones? ptain ce que t'etait deja beauf quand t'etait jeune grand papa'' Et depuis 5 ans, les besoins chez les gros ISP font qu'une architecture avec un CPU central ne convient plus. Il faut deleguer la partie forwarding a du hardware concu specialement pour. Gros design 'en partant de zero'. Cisco pas trop habitue a autre chose que du developpement logiciel. Mais ils etaient tout de meme les premiers sur le marche, trop tot. en tout cas par rapport a la qualite de ce qu'ils ont livres. debuts difficiles et lent pour le GSR (le nom de ce gros routeur). Depuis, la seconde generation de ce genre d'equipements c'est fait, mais pas chez cisco, chez juniper. ca marche bien parait-il. La complexite de developpe ces circuits specialises est tel que ce n'est pas trop a la portee d'une societe ce specialisant dans des equipement destine aus ISP, mais plutot a des fabricant de chip ultra integre. Cette generation de hardware concu par les fabricants de routeur eux meme est deja sur la voie de garage. Le truc plus raisonnable en terme de temps de developpement, c'est de faire des processeurs specialement etudie pour traiter des paquets. des 'network processor'. Bon, ca c'est pour transferer des Gbit/s. on est pas encore la entre vallorbe et bullet. Recemment y a eu un bug marrant: un paquet IP traversant un routeur cisco, et contenant une taille de payload IP plus petite que la taille de trame, peut contenir des donnees d'autre paquets IP ayant traverse le meme routeur. Un tel paquet n'est pas chose courante, pas vraiment normal, mais tout a fait valide. C'est donc un superbe diffuseur de password et autres donnees sensible pour qui sait l'exploiter. Ce que ciso dit: desactiver CEF (une fonction bien pratique car exploitant le fait que la memoire soit moins chere qu'au debut de l'ere cisco, sacrifiant de l'espace memoire pour de la vitesse de traitement, donc de la performance). Le hic: CEF est active un peu chez tout les ISP, et le desactive implique une sacree perte de performance, donc ajouter des nouveaux routeurs dans un reseau. Marrant non? aplus -- 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.
Re: FDDI ou ATM pour un backbone ?
At 12:08 03.04.02, you wrote: > > >(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.) > > > > Mais pourquoi on achete du CISCO ? Juste pour payé un prix fou pour la > mise > > à jour ou l'ajout de la fonctionalité suplèmentaire que l'on avait pas > > prévu ! > >oh le fait que linux ou un *BSD soit a la hauteur de ce point >de vue la, en totalement libre, c'est recent. y a meme pas de date >precise, c'est un mouvement actuel, on est dedans. >le logiciel de routage 'zebra' est la seule suite supportant >BGP et OSPF en license GPL, les deux protocoles de routage >important pour l'ensemble du net. >Je l'avais teste il y a deux ans, ca marchait deja, bien qu'il y >avait encore pas mal de bug. Maintenant il est pas mal stable. > >Le hardware cisco reste mieux concu pour transmettre des paquets >d'une interface a une autre. >le software cisco.. disons que la vague du libre a rehausse quelque peu >le niveau de fiabilite de ce qu'attendent les clients payant une >license logiciel. >IOS, le firmware cisco, en terme de fiabilite, c'est entre novell >netware et window95. La comparaison n'est pas choisie par hasard, >IOS a aussi un model de gestion memoire simple, sans pagination, sans >protections. J'imagine pour des questions de perf. >Ca a ete concu pour tourner sur des ordinateurs avec un processeur >central et des interfaces bien interconnectees au bus memoire >(un routeur, ce n'est que ca), le CPU allant du 68360 au MIPS R7000, >donc la gestion memoire, c'est reste leger pour rester portable aussi. >Mais un MIPS R7000, en force brut, ca c'est fait rattraper par >les Pentium II et AMD Athlon, meme avec le bus memoire d'un pc qui >n'est pas la panacee. > > >Pour le software cisco, tout ecrit en C, tant que les developpeurs >sont content de touiller leur code ca va, des que les tensions entre >marketing et developpement (demande d'ajout de trop de nouveaute >dans un laps de temps trop court) atteigne un certains points, >ca se casse la gueule. >la qualite du soft livre au client devient de la merde. >Il y a 3 - 4 ans la stabilite etait nickel (comme un netware oublie >dans un coins depuis 5 ans), c'etait les version 11.1CC. >Petit-a-petit, ca c'est degrade. >Bon quand tu regardes le nombre de boites qu'ils ont rachetes >et vaguement ''integres'' a la ligne de produit, y a rien d'etonnant. >Ca restera peut-etre comme un fabricant de telephone. > >''tse gamin quant j'etait jeune, j'avais configurer des tas de routeurs >cisco'' >''quoi, cisco, comme les telephones? ptain ce que t'etait deja beauf quand > t'etait jeune grand papa'' > >Et depuis 5 ans, les besoins chez les gros ISP font qu'une architecture >avec un CPU central ne convient plus. >Il faut deleguer la partie forwarding a du hardware concu specialement >pour. >Gros design 'en partant de zero'. Cisco pas trop habitue a autre >chose que du developpement logiciel. Mais ils etaient tout >de meme les premiers sur le marche, trop tot. en tout cas par rapport >a la qualite de ce qu'ils ont livres. debuts difficiles et lent pour le GSR >(le nom de ce gros routeur). >Depuis, la seconde generation de ce genre d'equipements c'est fait, mais pas >chez cisco, chez juniper. ca marche bien parait-il. > >La complexite de developpe ces circuits specialises est >tel que ce n'est pas trop a la portee d'une societe ce >specialisant dans des equipement destine aus ISP, mais >plutot a des fabricant de chip ultra integre. >Cette generation de hardware concu par les fabricants >de routeur eux meme est deja sur la voie de garage. >Le truc plus raisonnable en terme de temps de developpement, >c'est de faire des processeurs specialement etudie pour >traiter des paquets. des 'network processor'. >Bon, ca c'est pour transferer des Gbit/s. >on est pas encore la entre vallorbe et bullet. Entre Sainte-Croix et Bullet, éventuellement Yverdon-Bullet. Ouai, cela me rapelle ma réaction quand j'ai à l'époque remarqué que Apple utilisait plusieurs processeur dédicasé à différentes tâches comme sur les Amiga (salut Felix). Je me suis dît que cette optique était bien plus performante mais génère des contrainte limitant l'adaptabilité du système. Dans le cas des réseau, je pense qu'il serai intéresant pour les constructeurs de créer des cartes génerant moin de travail sur l'unité centrale (comme les cartes FDDI). A propos, est-ce qu'il existe des routeurs basé sur des bus style VME (cela doit être plus modulaire et plus ouvert)? >Recemment y a eu un bug marrant: un paquet IP traversant un routeur >cisco, et contenant une taille de payload IP plus petite >que la taille de trame, peut contenir des donnees d'autre paquets >IP ayant traverse le meme routeur. >Un tel paquet n'est pas chose courante, pas vraiment normal, mais tout >a fait valide. >C'est donc un superbe diffuseur de password et autres donnees sensible >pour qui sait l'exploiter. >Ce que ciso dit: desactiver CEF (une fonction bien pra
Re: FDDI ou ATM pour un backbone ?
On Thu, 2002-04-04 at 00:52, MuTECH wrote: Hello, Zebra est quand meme un must dans le domaine du routage sous Nux et Bsd. Il existe d'autre daemon que l'on peut trouver sur Freshmeat. A l'essai on voit vite que zebra est beaucoup plus stable meme si l'on trouve encore des core dump sur certaines parties. Comme ospf6 ou d'autres fonctionnalités ipv6 récentes. Mais très utiles en tout cas pour des sessions BGP en lab ou autres ... En tout cas CISCO reste quand meme une garantie face à Zebra. Pour ce que dit Philippe avec CEF je suis d'accord la dessus meme si CEF pause parfois des problèmes de mise à jour des routes. J'ai déjà eu le cas sur de nombreux routeurs ... Encore un bug IOS ? A+ Nicolas > At 12:08 03.04.02, you wrote: > > > >(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.) > > > > > > Mais pourquoi on achete du CISCO ? Juste pour payé un prix fou pour la > > mise > > > à jour ou l'ajout de la fonctionalité suplèmentaire que l'on avait pas > > > prévu ! > > > >oh le fait que linux ou un *BSD soit a la hauteur de ce point > >de vue la, en totalement libre, c'est recent. y a meme pas de date > >precise, c'est un mouvement actuel, on est dedans. > >le logiciel de routage 'zebra' est la seule suite supportant > >BGP et OSPF en license GPL, les deux protocoles de routage > >important pour l'ensemble du net. > >Je l'avais teste il y a deux ans, ca marchait deja, bien qu'il y > >avait encore pas mal de bug. Maintenant il est pas mal stable. > > > >Le hardware cisco reste mieux concu pour transmettre des paquets > >d'une interface a une autre. > >le software cisco.. disons que la vague du libre a rehausse quelque peu > >le niveau de fiabilite de ce qu'attendent les clients payant une > >license logiciel. > >IOS, le firmware cisco, en terme de fiabilite, c'est entre novell > >netware et window95. La comparaison n'est pas choisie par hasard, > >IOS a aussi un model de gestion memoire simple, sans pagination, sans > >protections. J'imagine pour des questions de perf. > >Ca a ete concu pour tourner sur des ordinateurs avec un processeur > >central et des interfaces bien interconnectees au bus memoire > >(un routeur, ce n'est que ca), le CPU allant du 68360 au MIPS R7000, > >donc la gestion memoire, c'est reste leger pour rester portable aussi. > >Mais un MIPS R7000, en force brut, ca c'est fait rattraper par > >les Pentium II et AMD Athlon, meme avec le bus memoire d'un pc qui > >n'est pas la panacee. > > > > > >Pour le software cisco, tout ecrit en C, tant que les developpeurs > >sont content de touiller leur code ca va, des que les tensions entre > >marketing et developpement (demande d'ajout de trop de nouveaute > >dans un laps de temps trop court) atteigne un certains points, > >ca se casse la gueule. > >la qualite du soft livre au client devient de la merde. > >Il y a 3 - 4 ans la stabilite etait nickel (comme un netware oublie > >dans un coins depuis 5 ans), c'etait les version 11.1CC. > >Petit-a-petit, ca c'est degrade. > >Bon quand tu regardes le nombre de boites qu'ils ont rachetes > >et vaguement ''integres'' a la ligne de produit, y a rien d'etonnant. > >Ca restera peut-etre comme un fabricant de telephone. > > > >''tse gamin quant j'etait jeune, j'avais configurer des tas de routeurs > >cisco'' > >''quoi, cisco, comme les telephones? ptain ce que t'etait deja beauf quand > > t'etait jeune grand papa'' > > > >Et depuis 5 ans, les besoins chez les gros ISP font qu'une architecture > >avec un CPU central ne convient plus. > >Il faut deleguer la partie forwarding a du hardware concu specialement > >pour. > >Gros design 'en partant de zero'. Cisco pas trop habitue a autre > >chose que du developpement logiciel. Mais ils etaient tout > >de meme les premiers sur le marche, trop tot. en tout cas par rapport > >a la qualite de ce qu'ils ont livres. debuts difficiles et lent pour le GSR > >(le nom de ce gros routeur). > >Depuis, la seconde generation de ce genre d'equipements c'est fait, mais pas > >chez cisco, chez juniper. ca marche bien parait-il. > > > >La complexite de developpe ces circuits specialises est > >tel que ce n'est pas trop a la portee d'une societe ce > >specialisant dans des equipement destine aus ISP, mais > >plutot a des fabricant de chip ultra integre. > >Cette generation de hardware concu par les fabricants > >de routeur eux meme est deja sur la voie de garage. > >Le truc plus raisonnable en terme de temps de developpement, > >c'est de faire des processeurs specialement etudie pour > >traiter des paquets. des 'network processor'. > >Bon, ca c'est pour transferer des Gbit/s. > >on est pas encore la entre vallorbe et bullet. > > Entre Sainte-Croix et Bullet, éventuellement Yverdon-Bullet. > Ouai, cela me rapelle ma réaction quand j'ai à l'époque remarqué que Apple > utilisait plusieurs processeur dédicasé à différentes tâches comme sur les > Amiga (salut Felix). Je me suis dît que
Re: FDDI ou ATM pour un backbone ?
On Wed, 3 Apr 2002, Philippe Strauss wrote: > le logiciel de routage 'zebra' est la seule suite supportant > BGP et OSPF en license GPL, les deux protocoles de routage > important pour l'ensemble du net. un ami a mis une machine Linux avec zebra dans le Internet Exchange de Zürich. Ca semble marcher. Je lui demanderai plus de détails ce week-end. > on est pas encore la entre vallorbe et bullet. :) très marrant. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Thu, Apr 04, 2002 at 09:20:27AM +0200, Marc SCHAEFER wrote: > On Wed, 3 Apr 2002, Philippe Strauss wrote: > > > le logiciel de routage 'zebra' est la seule suite supportant > > BGP et OSPF en license GPL, les deux protocoles de routage > > important pour l'ensemble du net. > > un ami a mis une machine Linux avec zebra dans le Internet Exchange de > Zürich. Ca semble marcher. Je lui demanderai plus de détails ce week-end. Andre Oppermann? -- 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.
Re: FDDI ou ATM pour un backbone ?
On Wednesday 03 April 2002 23:52, MuTECH wrote: > A propos, est-ce qu'il existe des routeurs basé sur des bus style VME (cela > doit être plus modulaire et plus ouvert)? VME n'existe plus et est remplacé par la norme VXI depuis (~10 ans). Les constructeurs ne sont pas intéressés à "ouvrir" leur architecture :-( Aujourd'hui, les bus backplanes sont, presque tous, des cross-bar, pour des raisons de performances de swicthing. Les routeurs sont aussi des switch et la bagarre se situe dans le haut de gamme. On ne parle plus que de milions de paquets swicthés par seconde... D'où du hard de plus en plus spécialisé. Il est certain qu'un système Linux peut très bien faire du routage, mais à partir d'un certain débit, le bus PCI est mal adapté à gérer ce genre de traffic et commence à prendre trop de ressources. Tout dépend donc des besoins et attentes. Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 01:44 04.04.02, you wrote: On Wednesday 03 April 2002 23:52, MuTECH wrote: > A propos, est-ce qu'il existe des routeurs basé sur des bus style VME (cela > doit être plus modulaire et plus ouvert)? VME n'existe plus et est remplacé par la norme VXI depuis (~10 ans). Les constructeurs ne sont pas intéressés à "ouvrir" leur architecture :-( Aujourd'hui, les bus backplanes sont, presque tous, des cross-bar, pour des raisons de performances de swicthing. Les routeurs sont aussi des switch et la bagarre se situe dans le haut de gamme. On ne parle plus que de milions de paquets swicthés par seconde... D'où du hard de plus en plus spécialisé. Il est certain qu'un système Linux peut très bien faire du routage, mais à partir d'un certain débit, le bus PCI est mal adapté à gérer ce genre de traffic et commence à prendre trop de ressources. Tout dépend donc des besoins et attentes. Daniel Merci pour ces précisions. Je ne pense pas que VME n'existe plus, il est encore assez actif au niveau de l'industrie (http://www.vmetro.com/ propose une carte 2 Gigabits/sec Fibre Channel). La dernière bouture de VME (VME320) permet de transferts de 320 à 500+ Mbytes/s se qui pourrai être exploitable pour des routeurs. On peut consulter http://www.vita.com/ pour avoir de plus amples informations. A+ Martial Guex -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi. MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users)
Re: FDDI ou ATM pour un backbone ?
On Thursday 04 April 2002 14:39, MuTECH wrote: > Merci pour ces précisions. Je ne pense pas que VME n'existe plus, il est > encore assez actif au niveau de l'industrie (http://www.vmetro.com/ propose > une carte 2 Gigabits/sec Fibre Channel). La dernière bouture de VME > (VME320) permet de transferts de 320 à 500+ Mbytes/s se qui pourrai être > exploitable pour des routeurs. > On peut consulter http://www.vita.com/ pour avoir de plus amples Le vieux pseudo-standard VME (198*) est devenu une norme qui se nomme VXI, mais il semble aussi qu'il y ait eu de neombreux dérivés... VME64, etc. VME320 est un back-plane propriétaire !!! Oui, il existe des systèmes complets sur bus VME/VXI avec des Unix/Linux temp-réel ! Toutefois, ce n'est pas parceque l'on peut avoir des vitesses de 500 Mbytes/s sur un back-plane que l'on peut en déduire qu'il s'agit d'une bonne architecture pour faire du routage. Il est certain qu'un bus VME/VXI peut assurer des taux de transferts point-à-point intéressant, mais de là à monter un système avec 6-8 cartes chargés de faire du routage il y a un pas à franchir qui n'est pas forcément approrié. Dans un réseau, on a tendance à oublier le "traffic" broadcast/multicast; et ça c'est un truc qui tue... Même un petit réseau a facilement 500-1000 paquets/s. Même si le kernel et le CPU peuvent traîter ces interruptions, l'overhead va croître de manière exponnetielle et c'est là qu'un vrai routeur va faire la différence. Les back-plane de petits switchs (quelques centaines de francs) en 100Base-T ont déjà un bande passante (agrégée) de +1.5 Gbytes/s. Donc attention, si tu as l'intention de faire un simple gateway entre deux points (ou trois), pas de problème. Si tu veux jouer au routeur entre du FDDI, 100 B-T et autre avec plusieurs réseaux, le problème de performances n'est pas si simple qu'il n'y paraît et il ne suffit pas d'aditionner les "burst transfer rate" des bus. N'oublions pas que VME/VXI sont à la base des bus destinés à recevoir des cartes CPU et des instruments (acquisition de données). Il est donc optimiser pour des transfert DMA de paquets relativement importants; non d'une quantité de petit paquets (les paquets ATM ont, sauf erreur, une taille fixe de 64 bytes !). Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 08:21 04.04.02, you wrote: >On Thursday 04 April 2002 14:39, MuTECH wrote: > > > Merci pour ces précisions. Je ne pense pas que VME n'existe plus, il est > > encore assez actif au niveau de l'industrie (http://www.vmetro.com/ propose > > une carte 2 Gigabits/sec Fibre Channel). La dernière bouture de VME > > (VME320) permet de transferts de 320 à 500+ Mbytes/s se qui pourrai être > > exploitable pour des routeurs. > > On peut consulter http://www.vita.com/ pour avoir de plus amples > >Le vieux pseudo-standard VME (198*) est devenu une norme qui se nomme VXI, >mais il semble aussi qu'il y ait eu de neombreux dérivés... VME64, etc. >VME320 est un back-plane propriétaire !!! > >Oui, il existe des systèmes complets sur bus VME/VXI avec des Unix/Linux >temp-réel ! Toutefois, ce n'est pas parceque l'on peut avoir des vitesses de >500 Mbytes/s sur un back-plane que l'on peut en déduire qu'il s'agit d'une >bonne architecture pour faire du routage. Il est certain qu'un bus VME/VXI >peut assurer des taux de transferts point-à-point intéressant, mais de là à >monter un système avec 6-8 cartes chargés de faire du routage il y a un pas à >franchir qui n'est pas forcément approrié. Dans un réseau, on a tendance à >oublier le "traffic" broadcast/multicast; et ça c'est un truc qui tue... Même >un petit réseau a facilement 500-1000 paquets/s. Même si le kernel et le CPU >peuvent traîter ces interruptions, l'overhead va croître de manière >exponnetielle et c'est là qu'un vrai routeur va faire la différence. Les >back-plane de petits switchs (quelques centaines de francs) en 100Base-T ont >déjà un bande passante (agrégée) de +1.5 Gbytes/s. > >Donc attention, si tu as l'intention de faire un simple gateway entre deux >points (ou trois), pas de problème. Si tu veux jouer au routeur entre du >FDDI, 100 B-T et autre avec plusieurs réseaux, le problème de performances >n'est pas si simple qu'il n'y paraît et il ne suffit pas d'aditionner les >"burst transfer rate" des bus. N'oublions pas que VME/VXI sont à la base des >bus destinés à recevoir des cartes CPU et des instruments (acquisition de >données). Il est donc optimiser pour des transfert DMA de paquets >relativement importants; non d'une quantité de petit paquets (les paquets ATM >ont, sauf erreur, une taille fixe de 64 bytes !). > >Daniel Je ne disais pas que c'était l'idéal, c'était plutôt pour te titiller suite à ta déclaration que VME était mort, ce qui m'a parut un peut catégorique comme déclaration, de plus j'ai un petit parti-pris car j'ai toujours eu un petit faible pour le bus VME qui était initialement dédicasé à des processeurs Motorola qui, je le pense toujours sont bien mieux conçus que ceux de la branche Intel (essaié de faire des compilateurs pour ces processeurs et vous comprendrez). Il est certain qu'arriver à ces vitesses entraine des sacrés problèmes car des couplages peuvant intervenir entre les différentes lignes présentes sur la platine ce qui entraine le controle précis des impédences des lignes et éventuellement l'utilisation de substrat de capacité éléctrique mieu adapté comme le silicone. Cela commence à devenir des vrais émeteurs radio et de plus cela commence à vraiment sortir du sujet. Bon d'accord j'abdique, pour le top-ten des routeurs il n'existe pas trop d'altérnative à des back-plane cross-bar et du hard vraiment dédicasé. Par contre je persiste à penser qu'une carte adaptée à un réseau en anneau fibre, que se soit en ethernet ou en ATM serai une bonne solution si elle existait (bonjour FDDI). On pourrai la considérer comme un minirouteur à trois voies pourvue de son back-plane personnel et l'on aurai plus qu'à se consacrer qu'à la gestion d'une seule voie et de la configuration de la carte. Cela reviendrai à l'utilisé il me semble comme un carte normale branchée sur un switch. Bon finit les prise de têtes, quesque tu me conseillerai comme paire de carte ethernet 100 Mbs pour les pop de mon backbone "encore" virtuelle munis de 2 paires de fibres monomode d'au maximum 10 km ? Tu pense qu'une carte mère du style MSI K7T266Pro2-RU avec un processeur AMD Athlon XP 1800+ et 256 Mbyte de ram conviendrai où il faut taper dans du plus perfo ? A+ Martial >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Thu, 4 Apr 2002, MuTECH wrote: > Bon finit les prise de têtes, quesque tu me conseillerai comme paire de > carte ethernet 100 Mbs pour les pop de mon backbone "encore" virtuelle > munis de 2 paires de fibres monomode d'au maximum 10 km ? > Tu pense qu'une carte mère du style MSI K7T266Pro2-RU avec un processeur > AMD Athlon XP 1800+ et 256 Mbyte de ram conviendrai où il faut taper dans > du plus perfo ? > > A+ > Martial Un avis concernant les chiffres: - 100Mbps x 2 ? (Ne voulais-tu pas dire 1000Mbps) - K7 266 Tu me sembles large. - 1800 + 256Mo , là aussi;) Je n'ai pas d'expérience sur de tels matériels, mais je m'y prendrai en commencant par /usr/src/linux/Documentation: --- /usr/src/kernel-source-2.2.17/Documentation/networking/bonding.txt 2. What type of cards can it work with it? Any Ethernet type cards (ie, you can even mix cards - a tulip and a 3com 3c905, for example). You can even bond together Gigabit Ethernet cards! --- /usr/src/kernel-source-2.2.17/Documentation/networking/bonding.txt et aussi, --- /usr/src/kernel-source-2.2.17/Documentation/networking/sk98lin.txt The sk98lin driver supports the SysKonnect SK-NET Gigabit Ethernet Adapter SK-98xx family on Linux 2.2.x and above. It has been tested with Linux on Intel/x86, ALPHA and UltraSPARC machines. >From v3.02 on, the driver is integrated in the linux kernel source. --- /usr/src/kernel-source-2.2.17/Documentation/networking/sk98lin.txt puis www.google.com/linux?q=gigabit -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 17:48 06.04.02, you wrote: >On Thu, 4 Apr 2002, MuTECH wrote: > > > Bon finit les prise de têtes, quesque tu me conseillerai comme paire de > > carte ethernet 100 Mbs pour les pop de mon backbone "encore" virtuelle > > munis de 2 paires de fibres monomode d'au maximum 10 km ? > > Tu pense qu'une carte mère du style MSI K7T266Pro2-RU avec un processeur > > AMD Athlon XP 1800+ et 256 Mbyte de ram conviendrai où il faut taper >dans > > du plus perfo ? > > > > A+ > > Martial >Un avis concernant les chiffres: >- 100Mbps x 2 ? (Ne voulais-tu pas dire 1000Mbps) Tout à fait. >- K7 266 Tu me sembles large. >- 1800 + 256Mo , là aussi;) Ne pas oublier que je dois avoir quelques autres tâche sur la même machine tel que le proxy et puis pour le gain de prix a passer sur une config moin performate serai négligeable par rapport au reste. >Je n'ai pas d'expérience sur de tels matériels, mais je m'y prendrai en >commencant par /usr/src/linux/Documentation: C'est déjà fait mais souvent la doc à un peut de la peine à suivre les nouveautés qui pourrai s'appliquer ici (à qui la faute, je culpabilise un peut). >--- /usr/src/kernel-source-2.2.17/Documentation/networking/bonding.txt >2. What type of cards can it work with it? > > Any Ethernet type cards (ie, you can even mix cards - a tulip >and a 3com 3c905, for example). You can even bond together Gigabit >Ethernet cards! >--- /usr/src/kernel-source-2.2.17/Documentation/networking/bonding.txt C'est en général ma première aproche mais dans le cas de l'ethernet beacoup de carte pour fibre optique ne sont pas explicitement données. Il est plus résonnable de trouver le constructeur et ensuite de voir si elle suportée par linux et où par *BSD. >et aussi, >--- /usr/src/kernel-source-2.2.17/Documentation/networking/sk98lin.txt >The sk98lin driver supports the SysKonnect SK-NET Gigabit Ethernet >Adapter SK-98xx family on Linux 2.2.x and above. >It has been tested with Linux on Intel/x86, ALPHA and UltraSPARC machines. > >From v3.02 on, the driver is integrated in the linux kernel source. >--- /usr/src/kernel-source-2.2.17/Documentation/networking/sk98lin.txt > >puis www.google.com/linux?q=gigabit Merci, mais attention le gigabit sur fibre optique monomode est il me semble limité à 2 ou 5 Km dans le standard et j'ai besoin comme je l'ai déjà dit d'environ 10 Km. Pour le moment j'ai touvé les produits suivants : En Giga === 3Com, Gigabit Fiber-LX Server NIC 710026 with Memory, List Price: $998.00 (http://www.3com.com/products/en_US/detail.jsp?tab=prodspec&sku=710026&pathtype=purchase) En Fast === DAMPEX, CFM3300CS20, Pas trouver de pris sur le net (http://www.danpex.com/products/converters/cfm3300cs.htm), C'est un convertisseur. DAMPEX, CFM3800C20, Pas trouver de pris sur le net (http://www.danpex.com/products/converters/cfm3800.htm), C'est un convertisseur. DAMPEX, CFWDM3505C20, Pas trouver de pris sur le net (http://www.danpex.com/products/converters/cfwdm350x.htm), C'est un convertisseur Simplex. Canoga Perkins, 9119 Media Converter, http://www.canoga.com/pdffiles/manual_pdfs/6911560D-MAN-9119.pdf Je cherche encore car je trouve un peu cher les cartes gigabit et je n'arrive pas à touver de solution satisfaisant en 100 Mb Après une petite évalutation il semble que le prix du hard d'un pop point reviendrait à environ 5'000 CHF (2 cartes 3500 plus l'ordi à 1500). De plus je voudrai avoir un pop point complet de réserve en cas de panne. Tout ceci entraine un prix 25'000 CHF pour les 4 pop's et la reserve. De plus il faut compter le travail et les petits détails tel que le connection des fibres. Enfin si je pouvait descendre le prix du hard au environ de 20'000 ce serai bien. >-- > Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch > > >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Sunday 07 April 2002 19:02, MuTECH wrote: >...Enfin si je pouvait descendre le prix du hard au environ de 20'000 > ce serai bien. La grande question est plutôt de savoir quel genre de traffic tu envisages. Soit tu veux servir quelques autres systêmes pour des gros transferts de fichiers, soit tu as l'intention de servir de hub/proxy pour plein d'utilisateurs. Ta config hard me paraît amplement suffisante quelque soit l'usage qu tu veux en faire. Par contre, tu as raison de te soucier de la qualité des cartes qui feraont certainement la différence dans le deuxième scénario. Il faut avouer que les informations détaillées de l'architecture des cartes sont faibles. Tout dépend de la taille des buffers des cartes, et de leur intelligence interne... à part poser des questions plus détaillées sur des listes spécialisées je ne vois pas comment te répondre. Se plonger dans le code source des drivers va simplement te donner mal à la tête et seul des testes en grandeur nature te donnerons les réponses. Toutefois, l'expérience m'a appris que beaucoup de cartes bon marché ont des lacunes lorsqu'on les pousse à bout. C'est souvent le fait d'un hard un peu plus minimum (buffer plus petits) qui reporte ses lacunes sur les soft et le CPU. Dans ce cas, le problème n'apparaîtra que lorsque le CPU est sollicités pour d'autres transactions I/O ou tâches CPU. Par exemple, lance des compilation pendant que tu fais des essais de transfert avec un bus 100Mb. Mais là encore, si une fois que tout fonctionne avec ton routeur, que les utilisateurs sont satisfaits des performances, que tu n'as pas l'intention d'en faire plus et que ton CPU est occupé à 99%... pourquoi pas ! Il n'est pas nécessaire de maintenir un grosse marge de manoeuvre si tu n'as pas l'intention de t'en servir Daniel PS : A propos de Motorola... nous sommes bien d'accord :-) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 04:12 08.04.02, you wrote: >On Sunday 07 April 2002 19:02, MuTECH wrote: > >...Enfin si je pouvait descendre le prix du hard au environ de 20'000 > > ce serai bien. > >La grande question est plutôt de savoir quel genre de traffic tu envisages. >Soit tu veux servir quelques autres systêmes pour des gros transferts de >fichiers, soit tu as l'intention de servir de hub/proxy pour plein >d'utilisateurs. Ta config hard me paraît amplement suffisante quelque soit >l'usage qu tu veux en faire. Par contre, tu as raison de te soucier de la >qualité des cartes qui feraont certainement la différence dans le deuxième >scénario. Il faut avouer que les informations détaillées de l'architecture >des cartes sont faibles. Tout dépend de la taille des buffers des cartes, et >de leur intelligence interne... à part poser des questions plus détaillées >sur des listes spécialisées je ne vois pas comment te répondre. Se plonger >dans le code source des drivers va simplement te donner mal à la tête et seul >des testes en grandeur nature te donnerons les réponses. Toutefois, >l'expérience m'a appris que beaucoup de cartes bon marché ont des lacunes >lorsqu'on les pousse à bout. C'est souvent le fait d'un hard un peu plus >minimum (buffer plus petits) qui reporte ses lacunes sur les soft et le CPU. >Dans ce cas, le problème n'apparaîtra que lorsque le CPU est sollicités pour >d'autres transactions I/O ou tâches CPU. Par exemple, lance des compilation >pendant que tu fais des essais de transfert avec un bus 100Mb. Mais là >encore, si une fois que tout fonctionne avec ton routeur, que les >utilisateurs sont satisfaits des performances, que tu n'as pas l'intention >d'en faire plus et que ton CPU est occupé à 99%... pourquoi pas ! Il n'est >pas nécessaire de maintenir un grosse marge de manoeuvre si tu n'as pas >l'intention de t'en servir Mon problème n'est pas tellement la vitesse, 10 Mb serait sufisant à la limite. C'est surtout de trouver des cartes fiables travaillant en monomode. Ce genre de produit semble toujour assez cher et on en général de grand débits. C'est expliquable par le fait que la plupart des gens qui on besoin de ce type de carte on aussi besoin également d'un débit substentiel. Ce qui n'est pas tellement le cas chez-nous car avec ~300 logements à couvrir et 3 ou 4 demande de bande passante plus généreuses, nous ne pouvons pas nous permettre de loué un bande chez cabelcom ou switch d'une trop grande passante et les tranfert locaux devrai être casiment négligeable. Justement je vien de recvoir les tarifs de cabelcom pour une connection à Sainte-Croix (je l'ai placée à l'adresse http://mutech.ch/Prix-Feed-Internet.pdf). Il s'avere qu'il est environ 3 x moin cher d'utilisé 4 connection ADSL à 512K montant et 128 descendant chez sunrise (sans limite de tansfert et l'installation compris) que d'avoir une ligne 1 MB et un tranfert d'un maximum 90GB/mois chez Cbelcom. Sans complexe j'ai téléphoné a cabelcom et je leur ai demander leur argumentation afin d'expliquer cette différence. Il explique par le fait qu'il assure la bande passante jusqu'a leur noeud centrale en suisse allemande (je crois que c'est Oeutingen). Après un petit momment de réflexion je me suis posé la question suivante suivante étant donnée que sur "mon" backbone je n'ai pas de problème à assurer cette bande passante jusqu'a Sainte-Croix où jusqu'a Yverdon (si j'utilise un liason p-p HF) et qu'entre Sainte-Croix et Yverdon il existe 48 fibres dont quelques une apartiennent à Swisscom, j'ai des doutes gros comme une montage que les lignes s'engorges jusqu'a Yverdon. Comme il existe un pop d'un enorme backbone à Yverdon et que celui-ci à encore une sacré marge avant de saturer mes petits paquets ethernet ne risque pas trop se sentir coincés. Par aquis de conscience je vais quand même demander des tarifs à Swisscom pour comparer mais je croix que je vai viré en ADSL. Par ailleur mon interlocuteur de Cabelcom dans sa plédoirie à prétendu qu'il était impossible de pouvoir faire passez des paquets d'une même requête par des cannaux ADSL différent. Comme j'ai toujours entendu et vu qu'un paquet ethernet et indépendant d'une session style FTP qui se trouve à niveau un poil plus haut que la couche de OSI, je ne vois pas bien pourquoi un routage avec un QoS bien configurer ne pourai pas résoudre le problème. Est-ce que quelqu'un voit un obstacle majeur à router en paralelle sur plusieurs connection ADSL ? Il me semble que plus problèmatique c'est la gestion du masqaring avec le load-balancing des lignes ADSL du au manque d'adresse fixe de l'ADSL mais Sunrise devrai prochainement proposé cette option pour l'ADSL ce qui pourai simplifier le problème. La je navigue un peut beacoup dans un truc que je ne métrise pas. Help me ! A+ Martial >Daniel > >PS : A propos de Motorola... nous sommes bien d'accord :-) >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. ---
Re: FDDI ou ATM pour un backbone ?
On Monday 08 April 2002 16:43, MuTECH wrote: > > Est-ce que quelqu'un voit un obstacle majeur à router en paralelle sur > plusieurs connection ADSL ? > En fait, on te dit ADSL, mais c'est une encapsulation au-dessus de la technologie pure ADSL. N lignes ADSL == N adresses IP !!! On peut "router" des paquets IP par des voies différentes mais l'on n'a pas de mechanisme standard pour agrèger plusieurs adresse IP avec une connection FTP (ou autre), amoins d'écrire du code spécifique. Techniquement, il faudrait uen version spéciale de ftp ouvrant plusieurs connections en //... Avec ADSL on te propose, en général, une adresse IP en DHCP. Une adresse fixe est plus chère. De plus, certains fournisseurs te déconnectent au moins une fois par 24h. Il est aussi vrai qu'il assurent un peu moins la bande passante... Naturellement le prix à payer pour avoir une connection à 1Mb/s montant/descendant est nettement plus coûteux, mais par contre c'est du 24/24 à ce débit ! Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
> Justement je vien de recvoir les tarifs de cabelcom pour une connection à > Sainte-Croix (je l'ai placée à l'adresse > http://mutech.ch/Prix-Feed-Internet.pdf). Il s'avere qu'il est environ 3 x > moin cher d'utilisé 4 connection ADSL à 512K montant et 128 descendant chez > sunrise (sans limite de tansfert et l'installation compris) que d'avoir une > ligne 1 MB et un tranfert d'un maximum 90GB/mois chez Cbelcom. Sans > complexe j'ai téléphoné a cabelcom et je leur ai demander leur > argumentation afin d'expliquer cette différence. Il explique par le fait > qu'il assure la bande passante jusqu'a leur noeud centrale en suisse > allemande (je crois que c'est Oeutingen). Après un petit momment de > réflexion je me suis posé la question suivante suivante étant donnée que > sur "mon" backbone je n'ai pas de problème à assurer cette bande passante > jusqu'a Sainte-Croix où jusqu'a Yverdon (si j'utilise un liason p-p HF) et > qu'entre Sainte-Croix et Yverdon il existe 48 fibres dont quelques une > apartiennent à Swisscom, j'ai des doutes gros comme une montage que les > lignes s'engorges jusqu'a Yverdon. Comme il existe un pop d'un enorme > backbone à Yverdon et que celui-ci à encore une sacré marge avant de > saturer mes petits paquets ethernet ne risque pas trop se sentir coincés. > Par aquis de conscience je vais quand même demander des tarifs à Swisscom > pour comparer mais je croix que je vai viré en ADSL. > Par ailleur mon interlocuteur de Cabelcom dans sa plédoirie à prétendu > qu'il était impossible de pouvoir faire passez des paquets d'une même > requête par des cannaux ADSL différent. Comme j'ai toujours entendu et vu > qu'un paquet ethernet et indépendant d'une session style FTP qui se trouve > à niveau un poil plus haut que la couche de OSI, je ne vois pas bien > pourquoi un routage avec un QoS bien configurer ne pourai pas résoudre le > problème. > > Est-ce que quelqu'un voit un obstacle majeur à router en paralelle sur > plusieurs connection ADSL ? Hello, Je préfère te répondre en privé vu que je ne sais pas si mes commentaires sont d'un grand interêt... et vu que je me suis fait tirer les oreilles y'a pas longtemps Je connais plusieurs personnes qui utilisent l'ADSL de Sunrise et, pour l'instant en tout cas, cette connexion ne marche chez personne ! Même chose chez Swisscom... perso, j'utilise l'ADSL de VTX et cela marche à merveille :) et en plus ils sont très très rapide (niveau délais)... Hope that "helps", Pascal -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 08:54 08.04.02, you wrote: >On Monday 08 April 2002 16:43, MuTECH wrote: > > > > Est-ce que quelqu'un voit un obstacle majeur à router en paralelle sur > > plusieurs connection ADSL ? > > > >En fait, on te dit ADSL, mais c'est une encapsulation au-dessus de la >technologie pure ADSL. N lignes ADSL == N adresses IP !!! > >On peut "router" des paquets IP par des voies différentes mais l'on n'a pas >de mechanisme standard pour agrèger plusieurs adresse IP avec une connection >FTP (ou autre), amoins d'écrire du code spécifique. Techniquement, il >faudrait uen version spéciale de ftp ouvrant plusieurs connections en //... Je me pose la question, si l'on prend 4 modems ADSL sur ligne analogique avec sortie en Ethernet style Speed Touch Home d'Alcatel à 220 Euro chez france-telecom (il sont prévut pour travailler sur une plateforme Alcatel comme Swisscom), 4 carte ethernet 10MB qui se voient chacunes attribuées leur adresses IP par le DHCP du modem ADSL lui étant connecter ou même d'utiliser un hub et une seule carte auquel on attriburai 4 adresses IP en allant le piocher sur le serveur DHCP des 4 modems ADSL. Puis on considére le tout comme 4 ligne ethernet que l'on gére avec une config QoS adéquoite. Il te semble que c'est possible ? Marial >Avec ADSL on te propose, en général, une adresse IP en DHCP. Une adresse fixe >est plus chère. De plus, certains fournisseurs te déconnectent au moins une >fois par 24h. Il est aussi vrai qu'il assurent un peu moins la bande >passante... Naturellement le prix à payer pour avoir une connection à 1Mb/s >montant/descendant est nettement plus coûteux, mais par contre c'est du 24/24 >à ce débit ! > >Daniel >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Mon, Apr 08, 2002 at 07:43:58AM -0700, MuTECH wrote: > Est-ce que quelqu'un voit un obstacle majeur à router en paralelle sur > plusieurs connection ADSL ? Je vois plusieurs problèmes. Il faut trouver un moyen de distribuer le traffic sortant sur les différentes lignes ADSL, c'est faisable avec equal-cost multipath ou un truc de ce genre mais il faut encore que ton provider ne filtre pas le traffic. Sinon il est possible d'utiliser du NAT (ip-masquerade par ex.) mais le load-balancing ne fonctionnera que par connection. Pour ce qui est du traffic entrant c'est déjà plus difficile si ton provider ne coopère pas (ce qui sera certainement le cas pour une connection ADSL pas chère...). A moins d'utiliser encore une magouille a base de NAT. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Monday 08 April 2002 17:36, MuTECH wrote: >... > Puis on considére le tout comme 4 ligne ethernet que l'on gére avec une > config QoS adéquoite. > Il te semble que c'est possible ? |-/ C'est un sujet très délicat dans lequel les provider ne semblent pas vouloir s'investir. Il semble que ça leur pose pas mal de problèmes au niveau de leurs routeurs et de la gestion DNS... Eux aussi doivent assurer de la redondance et l'échange d'infos de ce genre entre les routeurs ne paraît pas évidente. A part ça, je ne me lancerais pas dans ce genre de truc. Assurer de l'aggrégation, du load balancing et une redondance avec cette méthode me semble hasardeux. De plus, tu auras besoins d'une montagne de volonté et de collaboration de la part du provider, et là... j'ai des doutes. Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Mon, 8 Apr 2002, Pascal Perez - LHA wrote: > Je préfère te répondre en privé vu que je ne sais pas si mes commentaires > sont d'un grand interêt... et vu que je me suis fait tirer les oreilles y'a > pas longtemps On peut tout à fait créer une mailing-list sur le sujet, m'envoyer un mail (attention au Reply-To:) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Hello, J'ai une petite question. Combien de "clients" potentiels tu as sur place (à St-Croix)? A+ Blaise Drayer -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Avant de traiter le sujet du mail j'aimerai vous informez que je viens de me voir attribué une somme énorme de 1000 franc par la commune de Bullet afin d'évaluer les possibilité de la création de ce backbone. Ceci leur permettant d'officialiser mes requêtes au niveau des prestataires avec lesquels je prend contact. Je propose donc de faire un grand geulton indirectement au frais de la commune de Bullet avec les différentes personnes qui voudrai s'impliquer ainsi que ceux pour qui c'est déjà fait tel que : Daniel Cordey, Francois Deppierraz, Blaise Drayer, Félix Hauri, Marc SCHAEFER, Philippe Strauss et Nicolas STRINA afin que l'on voient quesque je vais bien pouvoir faire de cette argent à par payer le repas naturelement. Cela permettrai éventuellement de discuter du projet "linux-edu", j'en profite d'ailleur pour invité Gilbert Robert si il le désire. Je soumai la date du samedi 20 avril pour ce grand évenement. Pour le lieu on verra quand la date sera fixée et que les participants seront connus. Donc pour tout ceux qui voudrai participer, faite le moi savoir et n'oublié pas de m'indiquer si la date vous convient. A+ Martial At 01:46 09.04.02, you wrote: >Hello, > >J'ai une petite question. Combien de "clients" potentiels tu as sur >place (à St-Croix)? Je pense que c'est environ 10 à 15% des 3500 habitants mais Sainte-Croix n'est pas concerné par mon projet, d'ailleur Sainte-Croix et déjà pris en main par Cabelcom qui il me semble à planifié le remplacement leur réseau de cables coax pour la télévision par de la fibre. C'est probablement la raison pour laquel il ont monté la fibre depuis Yverdon, ceci en colaboration avec avec Swisscom qui devai elle en avoir besoin pour l'ADSL. >A+ > >Blaise Drayer > >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Tue, 9 Apr 2002, MuTECH wrote: > Je soumai la date du samedi 20 avril pour ce grand évenement. Install-Fest EPFL; et personnellement mai me conviendrait mieux pour diverses raisons. Mais on peut combiner l'Install-Fest EPFL avec ça peut-être. PS: ton idée m'intéresse à fond. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Hello, > Je propose donc de faire un grand geulton indirectement au frais de la > commune de Bullet avec les différentes personnes qui voudrai s'impliquer > ainsi que ceux pour qui c'est déjà fait tel que : Daniel Cordey, Francois > Deppierraz, Blaise Drayer, Félix Hauri, Marc SCHAEFER, Philippe Strauss et > Nicolas STRINA afin que l'on voient quesque je vais bien pouvoir faire de > cette argent à par payer le repas naturelement. :-) > Cela permettrai éventuellement de discuter du projet "linux-edu", j'en > profite d'ailleur pour invité Gilbert Robert si il le désire. Bonne idée. > Je soumai la date du samedi 20 avril pour ce grand évenement. Pour moi ça joue, mais je pense que ce serait mieux si Marc pouvait venir aussi donc je pense qu'il faut définir une autre date avant ou alors après computer 2002 (quoiqu'on peux aussi se voir un soir pendant computer) > Pour le lieu on verra quand la date sera fixée et que les participants > seront connus. Je viens volontier :-) mais ça dépends quand même un peu de la date (mais je suis normalement libre le soir) A+ Blaise Drayer -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Tue, Apr 09, 2002 at 07:08:29AM -0700, MuTECH wrote: > Avant de traiter le sujet du mail j'aimerai vous informez que je viens de > me voir attribué une somme énorme de 1000 franc par la commune de Bullet > afin d'évaluer les possibilité de la création de ce backbone. Ceci leur > permettant d'officialiser mes requêtes au niveau des prestataires avec > lesquels je prend contact. > Je propose donc de faire un grand geulton indirectement au frais de la > commune de Bullet avec les différentes personnes qui voudrai s'impliquer > ainsi que ceux pour qui c'est déjà fait tel que : Daniel Cordey, Francois > Deppierraz, Blaise Drayer, Félix Hauri, Marc SCHAEFER, Philippe Strauss et > Nicolas STRINA afin que l'on voient quesque je vais bien pouvoir faire de > cette argent à par payer le repas naturelement. > Cela permettrai éventuellement de discuter du projet "linux-edu", j'en > profite d'ailleur pour invité Gilbert Robert si il le désire. > Je soumai la date du samedi 20 avril pour ce grand évenement. nickel :)) j'accepte bien volontier l'invite, quand vous voulez (puisque le 20 semble pas trop jouer). aplus -- 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.
Re: FDDI ou ATM pour un backbone ?
On Tuesday 09 April 2002 18:55, Philippe Strauss wrote: > > j'accepte bien volontier l'invite, quand vous voulez (puisque > le 20 semble pas trop jouer). L'idée de computer 2002 évoquée précédemment est sans doute la seule possibilité pour moi. Mais je pense que ma présence est plus complémentaire qu'essentielle. Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Bon pour ceux qui sont canditats au souper je vous propose le samedi 4 mai à midi, cela permettra de d'étendre la discution en soirée si on le sens bien et également de se bronzer au soleil (cela me changera) et éventuelement de laiser batifoler la famille. Je m'excuse si je n'ai pas répondu promptement mais je me suis pris la tête avec l'histoire du e-vote. A+ Martial MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Hello, > Bon pour ceux qui sont canditats au souper je vous propose le samedi 4 mai > à midi, cela permettra de d'étendre la discution en soirée si on le sens > bien et également de se bronzer au soleil (cela me changera) et > éventuelement de laiser batifoler la famille. Pour moi c'est OK pour le 4 à midi A+ Blaise Drayer -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Tuesday 09 April 2002 19:37, MuTECH wrote: > Bon pour ceux qui sont canditats au souper je vous propose le samedi 4 mai > à midi, cela permettra de d'étendre la discution en soirée si on le sens > bien et également de se bronzer au soleil (cela me changera) et > éventuelement de laiser batifoler la famille. Désolé mais je ne pourai pas me joindre à vous. Bonne bouffe à tous :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Tue, 9 Apr 2002, Daniel Cordey wrote: > On Tuesday 09 April 2002 18:55, Philippe Strauss wrote: > > > > j'accepte bien volontier l'invite, quand vous voulez (puisque > > le 20 semble pas trop jouer). > > L'idée de computer 2002 évoquée précédemment est sans doute la seule > possibilité pour moi. Mais je pense que ma présence est plus complémentaire > qu'essentielle. Si tu viens et que tu dis un seul truc qui fait avancer les choses, alors ta présence aurra été essentielle. Si tu ne viens pas, on ne le saura jamais! ;-) -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On 9 Apr 2002, Blaise Drayer wrote: > Hello, > > J'ai une petite question. Combien de "clients" potentiels tu as sur > place (à St-Croix)? Pourquoi poses-tu cette question? >:-( -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Hello, > > J'ai une petite question. Combien de "clients" potentiels tu as sur > > place (à St-Croix)? > Pourquoi poses-tu cette question? >:-( Bêtement pour savoir ce qui est envisagable et nécessaire comme connection, ... Si tu a 3 personnes interessées effectivment tu prends de l'ADSL de l'autre côté. Si tu as 500 personnes de l'autre côté tu prends une vrais connection et si c'est le cas le plus simple est d'avoir une ligne louée Swissnet jusqu'au CERN ou tu peux faire des peering et acheter du transit pas cher (toujours trop cher mais bon, ...) A+ Blaise Drayer -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 00:14 10.04.02, you wrote: >On Tuesday 09 April 2002 19:37, MuTECH wrote: > > Bon pour ceux qui sont canditats au souper je vous propose le samedi 4 mai > > à midi, cela permettra de d'étendre la discution en soirée si on le sens > > bien et également de se bronzer au soleil (cela me changera) et > > éventuelement de laiser batifoler la famille. > >Désolé mais je ne pourai pas me joindre à vous. Bonne bouffe à tous :-) Domage enfin on va probablement avoir une autre ocasion de se voir, de toute façon je te garde ton souper en reserve. Tu peu si tu le veut réserver le 31 juillet comme les autres paticipants du "Re: FDDI ou ATM pour un backbone ?" et de "linux-edu" d'ailleur car se jour là on fait un souper canadien (ou tout le monde aporte sa nouriture) avec un groupe d'amis qui aime bien les nouvelles têtes puis on fait un petit feu d'artifice (entre 2000 et 3000 CHF d'engin pyrotechniques en tous genres). A+ Martial >Daniel >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 01:50 10.04.02, you wrote: >Hello, > > > > J'ai une petite question. Combien de "clients" potentiels tu as sur > > > place (à St-Croix)? > > Pourquoi poses-tu cette question? >:-( > >Bêtement pour savoir ce qui est envisagable et nécessaire comme >connection, ... > >Si tu a 3 personnes interessées effectivment tu prends de l'ADSL de >l'autre côté. Si tu as 500 personnes de l'autre côté tu prends une vrais >connection et si c'est le cas le plus simple est d'avoir une ligne louée >Swissnet jusqu'au CERN ou tu peux faire des peering et acheter du >transit pas cher (toujours trop cher mais bon, ...) Acutellement on à deux posibilités pour se connecter sur le net. La première est d'utilisé un pop de Cabelcom à Sainte-Croix ou de faire une liaison p-p HF jusqu'à Yverdon et venir se planter sur pop de Switch (il semblerai qu'un des anciens directeurs de Switch soit établit à Bullet et qu'il avait proposé à ces anciens collégue une solution de ce genre afin de connecter sont châlet de vacance au net) ou sur un pop de VTX. J'ai actuelement une offre de VTX et de Cabelcom, les deux sonts un peut chère mais il semble que VTX offre un peut plus souple, ce qui m'embete c'est de rompre la chaine de la fibre par la liaison HF mais je pense que c'est la seul solution valable car elle permet de démarer plus gentiment avec une bande de 512K à 5'000 CHF/année avec 3G/mois de limite volume contrairement au 1M de Cabelcom à 1200 CHF/mois avec 90G/mois de volume. J'ai églement contactez Swisscom et Sunrise mais à première il cible des clients plus fortuné car leur offres se balade entre 4000 et 5000 CHF/mois pour une bande de 1M avec un volume illimitée que VTX offre à 21000 CHF/année. J'ai cassé les offres de VTX et Cabelcom aux adresses suivantes pour ceux que cela intéresse : * http://mutech.ch/Prix-Feed-Internet.pdf (Cabelcom) * http://mutech.ch/Premium.pdf (VTX Premium) * http://mutech.ch/Gold.pdf (VTX Gold) Pour ce qui est de l'ADSL, je pense suite au discution de cette liste que dans notre cas elle n'est pas admissible car elle risque de créer tellement de problèmes qu'elle rendrait l'utilisation backbone peut fiable, ce qui n'est pas l'objectif. Par contre il est interessant de se posé la question si il n'est pas plus résonable de remplacé les pop du backbone par 4 où 4 routeur ADSL et d'oublié le backbone. C'est vraiment enuyeux pour moi d'envisager cette solution car mon objectif premier et quand même d'avoir un serveur chez-moi branché sur une ligne rapide et fiable. Enfin on va voir. Pour le moment je vais aller à la pêche au prix d'une liaison p-p HF entre Bullet et Yverdon pour pouvoir faire une analyse des coûts complète. Je me permet de placer un petit liste qui peut-être complaitée facilement, ceci afin de confirmé si il participeront au diné du 4 mai: * Daniel Cordey, Il est bookés jusqu'au 20 mais se n'est que partie remise je l'espère. * Francois Deppierraz, Pas de réaction ? * Blaise Drayer, A confimer car il semble qu'il prefere le soir. * Félix Hauri, Alor tu viens ? Autrement, pour te siter "on ne le saura jamais"! * Marc SCHAEFER, C'est en mai alor pas d'excuse, tu viens ? * Philippe Strauss, C'est sur ? Noublie pas que tu as dît que c'est quand on veus! * Nicolas STRINA, Pas de réaction ? * Gilbert Robert, Pas de récation ?, Hé tu oublie les écoles et le serveur du gull! * Pour les autres completer vous même la liste: A+ Martial -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
> Pour ce qui est de l'ADSL, je pense suite au discution de cette liste que > dans notre cas elle n'est pas admissible car elle risque de créer tellement > de problèmes qu'elle rendrait l'utilisation backbone peut fiable, ce qui sur le troncon ou swisscom ne veut pas demarrer l'ADSL dans ta region c'est claire, mais je me rends pas compte des distance entre tes 4 pop. si il y a du cuivre sout-terrain plutot qu'aerien, de distance raisonnable (max 3km), la fiabilite du DSL sera excellente. mais si les lignes telephonique circulent beaucoup en aerien, la ca peut etre mauvais par temps humide. > n'est pas l'objectif. Par contre il est interessant de se posé la question > si il n'est pas plus résonable de remplacé les pop du backbone par 4 où 4 > routeur ADSL et d'oublié le backbone. C'est vraiment enuyeux pour moi beuh finalement swisscom delivre de l'ADSL? y e comprend piu. > d'envisager cette solution car mon objectif premier et quand même d'avoir > un serveur chez-moi branché sur une ligne rapide et fiable. Enfin on va > voir. > Pour le moment je vais aller à la pêche au prix d'une liaison p-p HF entre > Bullet et Yverdon pour pouvoir faire une analyse des coûts complète. > > Je me permet de placer un petit liste qui peut-être complaitée facilement, > ceci afin de confirmé si il participeront au diné du 4 mai: >* Daniel Cordey, Il est bookés jusqu'au 20 mais se n'est que partie > remise je l'espère. >* Francois Deppierraz, Pas de réaction ? >* Blaise Drayer, A confimer car il semble qu'il prefere le soir. >* Félix Hauri, Alor tu viens ? Autrement, pour te siter "on ne le saura > jamais"! >* Marc SCHAEFER, C'est en mai alor pas d'excuse, tu viens ? >* Philippe Strauss, C'est sur ? Noublie pas que tu as dît que c'est > quand on veus! oui c'est bien note! :) >* Nicolas STRINA, Pas de réaction ? >* Gilbert Robert, Pas de récation ?, Hé tu oublie les écoles et le > serveur du gull! >* Pour les autres completer vous même la liste: et Nico D. de lausanne, ici la terre repondez:) -- 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.
Re: FDDI ou ATM pour un backbone ?
Hello, > * Blaise Drayer, A confimer car il semble qu'il prefere le soir. Non, non c'est OK pour moi :-) ça va aussi à midi A+ Blaise Drayer -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 00:08 11.04.02, you wrote: > > Pour ce qui est de l'ADSL, je pense suite au discution de cette liste que > > dans notre cas elle n'est pas admissible car elle risque de créer > tellement > > de problèmes qu'elle rendrait l'utilisation backbone peut fiable, ce qui > >sur le troncon ou swisscom ne veut pas demarrer l'ADSL dans >ta region c'est claire, mais je me rends pas compte >des distance entre tes 4 pop. Il y a actuellement 3 solution qui se démarque. La première est de tiré la fibre depuis Sainte-Croix jusqu'à Bullet en passant par les Rasses (~6 Km) et de se racorder à un pop de Cabelcom à Sainte-Croix donc les tarifs sont disponibles sur les liens que j'ai donné dans un de mes message précedent. Cette solution risque d'être trop cher pour le potentielle actuelle de la région mais offre l'avantage d'être complètement en fibre. La seconde et d'éventuellement de ne pas tiré le segment Sainte-Croix - Les Rasses et de se connecter par une liaison p-p HF sur un pop de VTX à Yverdon qui est moin cher et de plus permet une vitesse minumum de 512K à 5'000 CHF/Année contrairement au 1M à 14400 CHF/année pour Cabelcom. De plus il se pourai que l'on établise des lien privilegié avec switch par l'intermédiare d'un de ces anciens directeur qui à une résidence secondaire à Bullet. Ce qui permettrai éventuellement d'avoir des tarifs préferenciel pour un connection directe sur un pop de Switch. La dernière et d'utilisé une ligne ADSL pour connecter le backbone de Sainte-Croix à Sainte-Croix avec une connection à 2Mbits montant et 396 en descente qui reviendrai à environ 280 CHF/mois mais n'authoriserai pas d'extension de la bande passante et n'offrant aucune aucunes adresse IP fixe puisque la mise en paralléle de ligne ADSL ne semble vraiment difficile à mettre en oeuvre. >si il y a du cuivre sout-terrain plutot qu'aerien, de distance >raisonnable (max 3km), la fiabilite du DSL sera excellente. >mais si les lignes telephonique circulent beaucoup en aerien, >la ca peut etre mauvais par temps humide. > > > n'est pas l'objectif. Par contre il est interessant de se posé la question > > si il n'est pas plus résonable de remplacé les pop du backbone par 4 où 4 > > routeur ADSL et d'oublié le backbone. C'est vraiment enuyeux pour moi > >beuh finalement swisscom delivre de l'ADSL? y e comprend piu. Je clarifie, chez-moi (au Rasses, distans d'environ 4 Km de sainte-Croix ou se trouve la centrale) l'ADSL et disponible jusqu'à 512K pour ceux qui n'on pas de bout en aérien, par contre la localité de Bullet qui est environ à 2 Km des Rasses n'on pas la posibilité de ce connecter à l'ADSL (je n'ai pas tester tous le numéros, il y a peut être quelque exceptions). Voulant avoir une ligne plus fiable chez-moi afin de placer un serveur sur net qui est actuellement au states. Je me suis dît que l'on pourai utilisé l'expérience toutes fraiche des gens qui on récement posé la fibre entre Yverdon et Sainte-Croix pour la prolongé jusqu'à Bullet afin d'offrir une préstation plus corecte sur Bullet et les Rasses et du coup d'avoir la fibre chez-moi. Il c'est averé qu'il existait une vieilles cannalisation d'eau vide sur une grande partie du chemin que devrai emprunter la fibre et qu'il était donc relativement pas trop cher de la faire passer la fibre à l'intérieur à l'aide de sorte de petit parachutes et d'air comprimé. C'est à ce moment que j'ai commencé à pensé à ce petit backbone et que j'ai commencé à m'activé sur cette liste. > > d'envisager cette solution car mon objectif premier et quand même d'avoir > > un serveur chez-moi branché sur une ligne rapide et fiable. Enfin on va > > voir. > > Pour le moment je vais aller à la pêche au prix d'une liaison p-p HF entre > > Bullet et Yverdon pour pouvoir faire une analyse des coûts complète. > > > > Je me permet de placer un petit liste qui peut-être complaitée facilement, > > ceci afin de confirmé si il participeront au diné du 4 mai: > >* Daniel Cordey, Il est bookés jusqu'au 20 mais se n'est que partie > > remise je l'espère. > >* Francois Deppierraz, Pas de réaction ? > >* Blaise Drayer, A confimer car il semble qu'il prefere le soir. > >* Félix Hauri, Alor tu viens ? Autrement, pour te siter "on ne le saura > > jamais"! > >* Marc SCHAEFER, C'est en mai alor pas d'excuse, tu viens ? > >* Philippe Strauss, C'est sur ? Noublie pas que tu as dît que c'est > > quand on veus! > >oui c'est bien note! :) Super! > >* Nicolas STRINA, Pas de réaction ? > >* Gilbert Robert, Pas de récation ?, Hé tu oublie les écoles et le > > serveur du gull! > >* Pour les autres completer vous même la liste: >et Nico D. de lausanne, ici la terre repondez:) > >-- >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. --
Re: FDDI ou ATM pour un backbone ?
On Thursday 11 April 2002 10:34, MuTECH wrote: > > La dernière et d'utilisé une ligne ADSL pour connecter le backbone de > Sainte-Croix à Sainte-Croix avec une connection à 2Mbits montant et 396 en > descente qui reviendrai à environ 280 CHF/mois mais n'authoriserai pas > d'extension de la bande passante et n'offrant aucune aucunes adresse IP > fixe puisque la mise en paralléle de ligne ADSL ne semble vraiment > difficile à mettre en oeuvre. Mais ne peux-tu obtenir au moins une adresse IP fixe en payant un poil plus ? En installant un proxy tu contournes ce problème. De plus, cette solution n'est pas trop lourde à mettre en oeuvre et tu ne payes pas pour de la technologie qui peut s'avérer obsolète rapidement. Imagine que dans deux ans la compagnie d'électricité propose une connection 512 Kb/s à tous les foyers... Tes utilisateusr ne vont-ils pas te laisser tomber en te laissant règler le reste de la facture ? > Il c'est averé qu'il existait une vieilles cannalisation d'eau vide sur une > grande partie du chemin que devrai emprunter la fibre et qu'il était donc > relativement pas trop cher de la faire passer la fibre à l'intérieur à > l'aide de sorte de petit parachutes et d'air comprimé. C'est à ce moment > que j'ai commencé à pensé à ce petit backbone et que j'ai commencé à > m'activé sur cette liste. Oui, la fibre c'est l'idéal, mais n'est-ce pas un peu "canon à mouche" dans ce cas ? Quel est le coût de la pose de la fibre ? Il existe des kits de connection aérienne ofrants des connexion 11 Mb/s sur quelques km; et ceci à des prix très abordables. En résumé, un routeur proxy au Bullet, une connexion aérienne Bullet-St-Croix, puis une ligne ADSL à 512 Kb/s. C'est déjà pas mal, non ? De plus, on peut très bien dire que la connexion aérienne ne va pas à St-Croix mais à Yverdon, avec un lien encore plus rapide, etc. Donc, souplesse de choix et d'évolution... Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 02:52 11.04.02, you wrote: >On Thursday 11 April 2002 10:34, MuTECH wrote: > > > > La dernière et d'utilisé une ligne ADSL pour connecter le backbone de > > Sainte-Croix à Sainte-Croix avec une connection à 2Mbits montant et 396 en > > descente qui reviendrai à environ 280 CHF/mois mais n'authoriserai pas > > d'extension de la bande passante et n'offrant aucune aucunes adresse IP > > fixe puisque la mise en paralléle de ligne ADSL ne semble vraiment > > difficile à mettre en oeuvre. > >Mais ne peux-tu obtenir au moins une adresse IP fixe en payant un poil plus ? Il me semble que le seul qui à anoncé cela c'est Sunrise pour le début de l'années mais n'oublie pas que l'ADSL à quand même une cible sur le grand public et que dans ce cas la politique des prestataire c'est que si cela bonchonne chez eux il attende pour voir. De plus même si j'ai une adresse fixe je ne vais pas pouvoir l'utilisé sur mon serveur à moin de faire du NAT statique sur le proxy connecter à l'ADSL. Non cette solution n'aporte vraiment pas assez d'avantage permettant de défendre le projet au niveau de la commune. Par contre avec une liaison tel que celle avec la connection chez VTX sur Yverdon, je pourai utiliser des argument comme la promotion de l'établisement de petite boîtes pouvant avoir leur serveurs hebergé localement pour un prix raisonable et des adresses fixes disponibles. Mais ceci doit naturelement être confirmer après quand j'aurai tout les prix puis fait les calculs des coûts avec les amortisement du matériel info sur 4 ans et sur 10 ans pour la pose de la fibre puis de d'évluer plus concrètement le potentiel de rentrèe en démarchant plus concraitement les gros demandeur de bande passante tel que le Grand Hôtel des Rasses et la colonie de vacance prés de chez-moi qui pourai être interesé par ce type de connection afin de garder les contracts à long therme qu'il ont où qu'il voudrai avoir avec l'armée. Je pense que l'on doit pouvoir entre moi même et le Grand Hôtel des Rasses déjà sortit 1 CHF/année de location de la ligne, si la dessus l'on rajoute environ 40 connection privée (~10% de la population) avec des abonnement à environ 300 CHF/année, on rentrerait 22000 CHF/année, ce qui n'est pas négligable et qui je le pense permetrai d'envisagé la solution VTX car il resterai environ 17'000 CHF/anné pour l'amortisement et la maintenance ce qui devrait permettre un amortissement pas loin des 80'000 en matériel. >En installant un proxy tu contournes ce problème. De plus, cette solution >n'est pas trop lourde à mettre en oeuvre et tu ne payes pas pour de la >technologie qui peut s'avérer obsolète rapidement. Imagine que dans deux ans >la compagnie d'électricité propose une connection 512 Kb/s à tous les >foyers... Tes utilisateusr ne vont-ils pas te laisser tomber en te laissant >règler le reste de la facture ? Ben faut prendre des risque de temps en temps, autrement tout le monde le ferai. > > Il c'est averé qu'il existait une vieilles cannalisation d'eau vide sur une > > grande partie du chemin que devrai emprunter la fibre et qu'il était donc > > relativement pas trop cher de la faire passer la fibre à l'intérieur à > > l'aide de sorte de petit parachutes et d'air comprimé. C'est à ce moment > > que j'ai commencé à pensé à ce petit backbone et que j'ai commencé à > > m'activé sur cette liste. > >Oui, la fibre c'est l'idéal, mais n'est-ce pas un peu "canon à mouche" dans >ce cas ? Quel est le coût de la pose de la fibre ? Il existe des kits de >connection aérienne ofrants des connexion 11 Mb/s sur quelques km; et ceci à Tu parle de certain fourniseur de 802.11 ? Si c'est le cas je pense que c'est pas l'idéal pour des liaison p-p mais par contre c'est probablement ce qui va être utilisé pour couvrir Bullet et les Rasses depuis les pop. Contrairement au Grand Hôtel des Rasses ou une solution par PowerLine à été preferée car le réseau est assés propre contrairement à bullet où cette option est iréalisable etant donné la mutlitude de problème technique et administratif. >des prix très abordables. En résumé, un routeur proxy au Bullet, une >connexion aérienne Bullet-St-Croix, puis une ligne ADSL à 512 Kb/s. C'est >déjà pas mal, non ? De plus, on peut très bien dire que la connexion aérienne >ne va pas à St-Croix mais à Yverdon, avec un lien encore plus rapide, etc. >Donc, souplesse de choix et d'évolution... > >Daniel >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Wed, Apr 10, 2002 at 03:54:07PM -0700, MuTECH wrote: >* Francois Deppierraz, Pas de réaction ? Normalement ça devrait jouer pour moi mais c'est encore à confirmer. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Wed, 10 Apr 2002, MuTECH wrote: > At 01:50 10.04.02, you wrote: > >Hello, > > > > > > J'ai une petite question. Combien de "clients" potentiels tu as sur > > > > place (à St-Croix)? > > > Pourquoi poses-tu cette question? >:-( > > > >Bêtement pour savoir ce qui est envisagable et nécessaire comme > >connection, ... Merci! Mais ce n'était pas le sens de mon ``pourquoi?''. Les autorité ont déjà avancé l'argument du nombre pour se désintéresser à la chose, maintenant il faut voir que les chose évoluent et les quidams qui n'avaient rien à faire de l'informatique et du net il y a deux ans s'y intéressent aujourd'hui. En fait, il fallait lire ``Cht!!!'' ;-) > ... > J'ai casé les offres de VTX et Cabelcom aux adresses suivantes pour ceux > que cela intéresse : > * http://mutech.ch/Prix-Feed-Internet.pdf (Cabelcom) > * http://mutech.ch/Premium.pdf (VTX Premium) > * http://mutech.ch/Gold.pdf (VTX Gold) Merci! > ... > * Félix Hauri, Alors tu viens ? Sûr! Moi, si y'a rien à payer... ;-) -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On jeu, avr 11, 2002 at 12:52:48 +0200, Francois Deppierraz wrote: > On Wed, Apr 10, 2002 at 03:54:07PM -0700, MuTECH wrote: > > >* Francois Deppierraz, Pas de réaction ? > > Normalement ça devrait jouer pour moi mais c'est encore à confirmer. Idem pour moi! Gilbert -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Thu, Apr 04, 2002 at 09:27:34AM +0300, Nicolas STRINA wrote: > On Thu, 2002-04-04 at 00:52, MuTECH wrote: > > Hello, > > Zebra est quand meme un must dans le domaine du routage sous Nux et Bsd. > Il existe d'autre daemon que l'on peut trouver sur Freshmeat. A l'essai > on voit vite que zebra est beaucoup plus stable meme si l'on trouve > encore des core dump sur certaines parties. Comme ospf6 ou d'autres > fonctionnalités ipv6 récentes. Mais très utiles en tout cas pour des > sessions BGP en lab ou autres ... En tout cas CISCO reste quand meme une > garantie face à Zebra. Pour ce que dit Philippe avec CEF je suis > d'accord la dessus meme si CEF pause parfois des problèmes de mise à > jour des routes. J'ai déjà eu le cas sur de nombreux routeurs ... Encore > un bug IOS ? ca m'arrive de chier sur cisco, mais en attendant, je suis en train d'en configurer un donc... la gamme du des routeurs jusqu'au 7200 est tres bien. le soft qui va avec a peu pres maitriser (pour internet). le pire que j'ai vu c'est les switch catalyst 6500. c'est pas un design, mais une bricole du product management jetee dans un cros boitier en metal tres solide est tres cher. aplus. -- 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.
Re: FDDI ou ATM pour un backbone ?
On Thu, Apr 11, 2002 at 11:17:56AM -0700, MuTECH wrote: > bon amis. J'espère que vous ne descendrez pas Sandro en flame parce qu'il > n'est pas du gull. Non, non, le GULL n'est pas une secte :) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Thursday 11 April 2002 21:29, Francois Deppierraz wrote: > Non, non, le GULL n'est pas une secte :) On est libre de choisir sa distribution ... de GNU/linux :-[] Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 15:53 11.04.02, you wrote: >On Thursday 11 April 2002 21:29, Francois Deppierraz wrote: > > > Non, non, le GULL n'est pas une secte :) > >On est libre de choisir sa distribution ... de GNU/linux :-[] > >Daniel Merci, cela va le rassurer. Bon comme que tout le monde à donné sa réponse (certaines restes confirmer) pour la réunion de 4 mai, je pense qu'il est temps de trouver un endroit donc je propose qu'on fasse ça dans la région de Préverenges (j'ai des bon souvenir de planche à voile dans ce coin). Je m'en rapelle comme d'un endroit calme et qui pourrai offrir un bon cadre aux nombreux sujets qui vont surement être abordés et qui offres un ou deux restaurants proches du lac et de la verdure. Je n'ai pas trop le temps de consulter toutes les adresses des participants pour savoir si c'est bien centré alors si je suis dans les décors faite une autre proposition. Par ailleur si quelqu'un peut me sugerer un restaurant cela me simplifierai la vie. A+ Martial Guex Oops je viens de voir que je dois retrourner le couteau dans la plaie, excuse moi Daniel (ce n'était presque pas voulu). >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Saturday 13 April 2002 00:24, MuTECH wrote: > Oops je viens de voir que je dois retrourner le couteau dans la plaie, > excuse moi Daniel (ce n'était presque pas voulu). T'inquiète pas... j'assume :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
Quelqu'un a il déjà utilisé avec FreeBSD un des produits de "NTT Advanced Technology Corporation" suivants: http://www.ntt-at.com/products_e/pos622/pos622_index.html http://www.ntt-at.com/products_e/pos2488/pos2488_index.html Il semble que ces produits soient centrés sur FreeBSD car il n'existe aucun drivers pour MS ou linux. Cela pourai être interesant de voir le prix de ces cartes si elles ne sont pas en voient d'extinction. Est-ce que MAPOS (http://www.mapos.org/) est exploitable ? A+ Martial Guex -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Monday 15 April 2002 18:16, Martial Guex wrote: > Quelqu'un a il déjà utilisé avec FreeBSD un des produits de "NTT Advanced > Technology Corporation" suivants: Pour info uniquement - Dans la revue "Login" du mois d'avril, il y l'article suivant : Le Gigabit dépassé sous FreeBSD Le projet de recherche Trapeze à l'université de Duke aux US a réussi à dépasser la barre du gigabit avec TCP/IP sous FreeBSD 4.0 (test Netperf). La performance reste de taille lorsque l'on connaît le nombre de couches logicielles en jeu. Il n'est pas aisé d'éviter les recopies de mémoires pour réaliser le découpage en paquets imposés par le protocole, même si les machines utilisées se montrent performantes et les messages de grande taille. La carte Myrinet/PCI 64 bits exploitée pour cette expérience a é mise au point par la société Miricom. Signalons aus paasge que la barre des 1 Gbit/s avait déjà été franchie avec un protocole propriétaire l'année dernière par léquipe française du "Laboratoire de Haute Performance en Calcul" à Lyon. (j'ai recopié l'article donc soyez indulgents pour les typos). Cela démontre bien les limites de l'architecture PCI et du bus mémoire des PC. Dans ce cas, l'absence de vrai processeur I/O est très pénalisante; c'est le CPU qui doit faire tout le travail. C'est justement là que les routeurs prennent le dessus car il s'affranchissent des problèmes de couches de soft et ont du logiciel dédié au découpage, et transferts, des paquets. De plus, leur soft permet de faire de l'adressage en utilisant l'architecture cross-bar. Notez aussi que les conditions du test sont très "favorables" (gros paquets). On peut facilement immaginer que ces performances auraient difficilement été atteintes avec un flux constitués de petits paquets. Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 01:45 18.04.02, you wrote: >On Monday 15 April 2002 18:16, Martial Guex wrote: > > Quelqu'un a il déjà utilisé avec FreeBSD un des produits de "NTT Advanced > > Technology Corporation" suivants: > >Pour info uniquement >- > >Dans la revue "Login" du mois d'avril, il y l'article suivant : J'avais également remarqué cette article. Il me semble avoir également lu que FreeBSD offre un environement mieu decoupé que linux pour developer les drivers des cartes réseau, ce qui fait qu'en général ceux-ci sont un peut plus solides et plus rapidement développé sur cette plate-forme. >Cela démontre bien les limites de l'architecture PCI et du bus mémoire des >PC. Dans ce cas, l'absence de vrai processeur I/O est très pénalisante; c'est >le CPU qui doit faire tout le travail. C'est justement là que les routeurs >prennent le dessus car il s'affranchissent des problèmes de couches de soft >et ont du logiciel dédié au découpage, et transferts, des paquets. De plus, >leur soft permet de faire de l'adressage en utilisant l'architecture >cross-bar. Notez aussi que les conditions du test sont très "favorables" >(gros paquets). On peut facilement immaginer que ces performances auraient >difficilement été atteintes avec un flux constitués de petits paquets. Les constructeurs de cartes réseaux devrait penser à créer un cross-bar parallèle au bus PCI comme par example un circuits multicouche (p.e. 4 x 64 bits) qui viendrait se connecter sur les cartes du coté opposé à la carte mère. Ceci permettrait de n'utiliser le bus PCI comme un fond de panier de routeur sans le cross-bar et le routages des paquets devant transiter par d'autres cartes où en relation avec la machine elle même. Bien sur cette situation impliquerai que les cartes intègres des fonctions de routages et éventuellement d'autres fonctons tel que la QoS. Ceci déchargerai la machine mais on perdrai de la souplese. L'idéal serai d'avoir des cartes de ce type avec le firmware en open et de pouvoir travaillé également sur la méthode utilisée par les carte pour exploiter le cross-bar. Bon c'était mon petit délir de la semaine mais on peut toujours réver ! A+ Martial Guex >Daniel >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Thursday 18 April 2002 18:25, Martial Guex wrote: > > Les constructeurs de cartes réseaux devrait penser à créer un cross-bar > parallèle au bus PCI comme par example un circuits multicouche (p.e. 4 x 64 > bits) qui viendrait se connecter sur les cartes du coté opposé à la carte > mère. Ceci permettrait de n'utiliser le bus PCI comme un fond de panier de > routeur sans le cross-bar et le routages des paquets devant transiter par > d'autres cartes où en relation avec la machine elle même. Bien sur cette > situation impliquerai que les cartes intègres des fonctions de routages et > éventuellement d'autres fonctons tel que la QoS. Ceci déchargerai la > machine mais on perdrai de la souplese. En fait, ça revient à développer... un router ! > L'idéal serai d'avoir des cartes de > ce type avec le firmware en open et de pouvoir travaillé également sur la > méthode utilisée par les carte pour exploiter le cross-bar. Le vrai délire ce serait qu'un constructeur dise : Je développe du hard, je fournit les specs et vous pouvez développer le soft en open source... Sans aller jusque là, on peut rêver qu'un fabricant donne l'accès à une partie de son code/firmware. Mais bon, c'est quand même assez fantasmagorique :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 00:35 19.04.02, you wrote: >On Thursday 18 April 2002 18:25, Martial Guex wrote: > > > > Les constructeurs de cartes réseaux devrait penser à créer un cross-bar > > parallèle au bus PCI comme par example un circuits multicouche (p.e. 4 x 64 > > bits) qui viendrait se connecter sur les cartes du coté opposé à la carte > > mère. Ceci permettrait de n'utiliser le bus PCI comme un fond de panier de > > routeur sans le cross-bar et le routages des paquets devant transiter par > > d'autres cartes où en relation avec la machine elle même. Bien sur cette > > situation impliquerai que les cartes intègres des fonctions de routages et > > éventuellement d'autres fonctons tel que la QoS. Ceci déchargerai la > > machine mais on perdrai de la souplese. > >En fait, ça revient à développer... un router ! Tiens, toi aussi tu as fait le rapprochement ! > > L'idéal serai d'avoir des cartes de > > ce type avec le firmware en open et de pouvoir travaillé également sur la > > méthode utilisée par les carte pour exploiter le cross-bar. > >Le vrai délire ce serait qu'un constructeur dise : Je développe du hard, je >fournit les specs et vous pouvez développer le soft en open source... Sans >aller jusque là, on peut rêver qu'un fabricant donne l'accès à une partie de >son code/firmware. Mais bon, c'est quand même assez fantasmagorique :-) De là à faire du open hard comme il en existe que de rares examples, il n'y a qu'un pas qui n'est pas si terrible que ça. Imagine tu plante sur le cross-bar un système fifo pour les différents bus que tu peut accéder de façon multiplexé depuis les cartes (un connecteur 4x64 pin + signaux et peu crédible). Sur les cartes tu plante un convertisseur serie -> parallèle et un autre parallèle -> serie, le côté serie branché sur un circuit d'interface physique au réseau et de l'autre tu plante des mémoires fifo d'IDT (Integrated device technologie) et une mémoire à double accés pour le bus PCI. Tu chapaute ceci par un où deux PLC de d'ALTERA ou de XILINK et un proceseur avec beaucoup de péche (http://e-www.motorola.com/webapp/sps/site/taxonomy.jsp?nodeId=01M0ylsDFTQ) et son entourage de ram statique, mem flash, quartz etc. Naturelement tout le firmare en flash. Avec ça t'est capable de traiter quasiement n'inporte quelle signaux et tu est extrainement souple au niveau du firmware. Le problème c'est le temps CPU disponible pour le traitement. Si tu utilise des convertisseur s-p de 64 bits tu doit quand même traiter un groupe de 64 bits tout les 16 ns , pas possible. Par contre une sorte de mini cross-bar entre les mémoires fifo du cross-bar inter cartes et celles faisant tampon avec l'extérieur et qu'un transfer sur le mini cross-bar puisse fonctionner en parallèle avec le traitement du processeur. Ceci t'offre le temps de remplissage des tampons pour traité l'entête des paquets. C'est sur que là il faut oublier le C et passé à l'assembleur mais cela doit être possible si tu ne doit pas traiter de paquets trop petit. De plus le système de clock recovery devrai être tactique. Pour avoir une idée j'ai trouvé un schèma partielle à l'adresse http://www.centurysys.co.jp/english/oc12/S0641_02.pdf mais il doit en exister d'autre qui pourait donner de bonnes idée. Bon la j'arrête le délire. Remarque c'est le genre de projet qui me boterai pas mal hystoire de me changer du train-train cotidien. Persone ne veus faire une startup par hazard ? A+ Martial >Daniel >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Friday 19 April 2002 19:10, Martial Guex wrote: > > De là à faire du open hard comme il en existe que de rares examples, il n'y > a qu'un pas qui n'est pas si terrible que ça S'il est facile de pondre du soft le soir dans son grenier, il en va autrement pour la poduction de chips... Je me vois mal squater le four de la cuisinne pour y mettre des "Wafers" :-) > Bon la j'arrête le délire. Remarque c'est le genre de projet qui me boterai > pas mal hystoire de me changer du train-train cotidien. Persone ne veus > faire une startup par hazard ? Surtout, leproblème vient du fait qu'il n'existe pas de processeur I/O assez évolué pour effectuer des chaînes de transfert DMA sans interrompre le CPU. Par contre cette simplicité du PC permet de baisser le prix. On ne peut généraliser ce genre d'arcitecture dans le bas de gamme et les fabricants de chips/cartes préferent se concentrer soit sur un marché de masse et simple avec du PCI, et un marché de niche non standardisé, propriétaire, pour le haut de gamme. Il n'en reste pas moins que ton idée est tentante :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Fri, Apr 19, 2002 at 09:35:35AM +0200, Daniel Cordey wrote: > En fait, ça revient à développer... un router ! ... > Le vrai délire ce serait qu'un constructeur dise : Je développe du hard, je > fournit les specs et vous pouvez développer le soft en open source... Sans > aller jusque là, on peut rêver qu'un fabricant donne l'accès à une partie de > son code/firmware. Mais bon, c'est quand même assez fantasmagorique :-) un type sur la liste zebra avait poste une URL de ce fabricant: http://www.znyx.com/products/hardware/ethernetswitches.htm tentant non? http://www.pt.com/products/prod_CPC4400.html http://www.nextgenbackplanes.com/ google est mon ami: http://www.google.com/search?client=googlet&q=CompactPCI%20and%20cPSB aplus -- 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.
Re: FDDI ou ATM pour un backbone ?
At 04:46 20.04.02, you wrote: >On Friday 19 April 2002 19:10, Martial Guex wrote: > > > > De là à faire du open hard comme il en existe que de rares examples, il n'y > > a qu'un pas qui n'est pas si terrible que ça > >S'il est facile de pondre du soft le soir dans son grenier, il en va >autrement pour la poduction de chips... Je me vois mal squater le four de la >cuisinne pour y mettre des "Wafers" :-) Pas de problème j'ai quelques contacts pour les fours. Par ailleur j'ai déjà conçu quelques proto et produits de la schematique au produits final. Bon c'était que des double couches à part quelques trucs très petit mais c'était quand même en SMD et quelque un avaient des signaux proche de 500 MHz. De plus j'ai encore un peu de matos tel que fer à air chaud pour SMD, projecteur UV etc que je n'utilise plus trop alor il faudrai que je les amortises un peu. Il pourai par contre être un peut difficile de trouver des analyseur logiques si on doit faire appel à ce type d'instrument de mesure, mais on pourai éventuellement voir avec des écoles du genre EIVD où EPFL car en travaillant en openhardware, ces établissement devrai être plus accésible. Le plus gros problème et de trouver le temps et le fric, surtout si c'est de l'openhardware, ce qui risque de ne pas améliorer mes finances. > > Bon la j'arrête le délire. Remarque c'est le genre de projet qui me boterai > > pas mal hystoire de me changer du train-train cotidien. Persone ne veus > > faire une startup par hazard ? > >Surtout, leproblème vient du fait qu'il n'existe pas de processeur I/O assez >évolué pour effectuer des chaînes de transfert DMA sans interrompre le CPU. Il est toujours posible de placé une barrière commandable depuis le CPU permettant de séparer les éléments utilisés par la DMA et ceux utilisés par le CPU (data, adresses, sign. ctrl). Le problème et le décalage temporel des signaux provoqué par ce type de barrière qui peut rendre l'accés aux éléments se trouvant derrière la barrière un peut tactique. Pour ce qui est du choix du processeur, il y deux possibilités, utilisé des cicuits spécialisé comme ceux de motorola, ce qui risque de taxé dur surtout pour les protos et de posé des problème pour les outils de développement où partir sur des produits grand public style AMD Duron et de caser un peut plus de hard autour. Je pense que la deuxième solution si elle est assez performante devrai permettre une mise en oeuvre plus facile (disponibilité des compilateurs et assembleurs). Un des problème serai plutôt physique car ces petites bêtes on besoin d'un radiateur et il faudrai donc à arriver à le caser entre deux cartes PCI, ce qui ne doit être tactique même si l'on place le ventilo à l'extérieur de la carte, bon on pourai passer à un réfroidissement à eau mais faut pas abuser. >Par contre cette simplicité du PC permet de baisser le prix. On ne peut >généraliser ce genre d'arcitecture dans le bas de gamme et les fabricants de >chips/cartes préferent se concentrer soit sur un marché de masse et simple >avec du PCI, et un marché de niche non standardisé, propriétaire, pour le >haut de gamme. Il n'en reste pas moins que ton idée est tentante :-) Cela fait plaisir de voir qu'il reste quelques ravagés. Ce qui serai intéresant à mon point de vue dans ce genre de projet, c'est la réaction des dévelopeur en opensoft face à cette oportunité et la réponse (si le produit final est exploitable) des industries qui ont ciblé sur le haut de gamme car cela devrai quand même leur faire un peut d'ombre (je suis très optimiste de nature si vous ne l'avez pas encore remarqué). Mais on s'attaque toujours à MS mais pourquoi pas au developeur hard qui abuse un peut trop de leur casi monopole. A+ Martial >Daniel > >-- >http://www-internal.alphanet.ch/linux-leman/ avant de poser >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 05:15 20.04.02, you wrote: >un type sur la liste zebra avait poste une URL de ce fabricant: > >http://www.znyx.com/products/hardware/ethernetswitches.htm > >tentant non? > >http://www.pt.com/products/prod_CPC4400.html > >http://www.nextgenbackplanes.com/ > >google est mon ami: > >http://www.google.com/search?client=googlet&q=CompactPCI%20and%20cPSB > > Je pensait à un truc un peut plus ouvert, du style http://www.openhardware.net/ -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
> De là à faire du open hard comme il en existe que de rares examples, il n'y > a qu'un pas qui n'est pas si terrible que ça. > Imagine tu plante sur le cross-bar un système fifo pour les différents bus > que tu peut accéder de façon multiplexé depuis les cartes (un connecteur > 4x64 pin + signaux et peu crédible). Sur les cartes tu plante un > convertisseur serie -> parallèle et un autre parallèle -> serie, le côté > serie branché sur un circuit d'interface physique au réseau et de l'autre > tu plante des mémoires fifo d'IDT (Integrated device technologie) et une > mémoire à double accés pour le bus PCI. Tu chapaute ceci par un où deux PLC > de d'ALTERA ou de XILINK et un proceseur avec beaucoup de péche > (http://e-www.motorola.com/webapp/sps/site/taxonomy.jsp?nodeId=01M0ylsDFTQ) > et son entourage de ram statique, mem flash, quartz etc. Naturelement tout > le firmare en flash. Avec ça t'est capable de traiter quasiement n'inporte > quelle signaux et tu est extrainement souple au niveau du firmware. Le > problème c'est le temps CPU disponible pour le traitement. Si tu utilise > des convertisseur s-p de 64 bits tu doit quand même traiter un groupe de 64 > bits tout les 16 ns , pas possible. Par contre une sorte de mini cross-bar > entre les mémoires fifo du cross-bar inter cartes et celles faisant tampon > avec l'extérieur et qu'un transfer sur le mini cross-bar puisse fonctionner > en parallèle avec le traitement du processeur. Ceci t'offre le temps de > remplissage des tampons pour traité l'entête des paquets. > C'est sur que là il faut oublier le C et passé à l'assembleur mais cela > doit être possible si tu ne doit pas traiter de paquets trop petit. De plus > le système de clock recovery devrai être tactique. > Pour avoir une idée j'ai trouvé un schèma partielle à l'adresse > http://www.centurysys.co.jp/english/oc12/S0641_02.pdf mais il doit en > exister d'autre qui pourait donner de bonnes idée. > Bon la j'arrête le délire. Remarque c'est le genre de projet qui me boterai > pas mal hystoire de me changer du train-train cotidien. Persone ne veus > faire une startup par hazard ? humm ton design, c'est bien joli, un peu sapin de noel, un peu beaucoup meme. jusqu'a 1Gbps de debit total, aucune raison de prendre autre chose que PCI 64bit comme bus, pas de crossbar. au dessus, ca devient du tres haut de gamme, jusque a peu reserver au design entierement proprietaire. desormais plus, les network processor et les crossbar switch sous forme de circuits integre 'standard' commence a exister, et des modules tout cuit comme j'ai indique dans les URL. mettre un crossbar switch comme fond de panier, alors que c'est encore un cpu central qui commnute, ca n'a pas de sens car le cpu serait des le depart le goulet d'etranglement. en gros: crossbar switch implique soit un traitement des paquet en hardware dedie, ou en network processor. reciproquement, un design avec un CPU central ne merite guere plus qu'un bus passif (ou evt. plusieurs) tout a fait standard. le probleme hardware est resolu. c'est le but, le logiciel est deja un sacre bordel a gerer (cf. grandeur et decadence de Cisco system). un truc vraiment passionant est d'imaginer faire tourner des morceaux de linux sur des network processors. mais bon, encore une fois, pour 1Mbps de debit, c'est un peu lourd comme solution :))) aplus > A+ > Martial -- 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.
Re: FDDI ou ATM pour un backbone ?
At 13:15 20.04.02, you wrote: >humm >ton design, c'est bien joli, un peu sapin de noel, un peu beaucoup >meme. C'est une première analyse qui n'est peut-être pas crédible alors si tu as des arguments plus précis, je suis tout ouvert à tes remarques. >jusqu'a 1Gbps de debit total, aucune raison de prendre autre chose que >PCI 64bit comme bus, pas de crossbar. Petit calcul on prend quatre cartes à 1 GB full duplex = 1GBytes/s, un bus PCI 64 bits 66 Mhz = 528 MBytes/s (je ne sais même pas si il existe des cartes mères avec plus de 2 slots 64 bits à 66 MHz), alor il y a un petit problème. >au dessus, ca devient du tres haut de gamme, jusque a peu >reserver au design entierement proprietaire. >desormais plus, les network processor et les crossbar switch >sous forme de circuits integre 'standard' commence a exister, >et des modules tout cuit comme j'ai indique dans les URL. > >mettre un crossbar switch comme fond de panier, alors que >c'est encore un cpu central qui commnute, ca n'a pas de sens >car le cpu serait des le depart le goulet d'etranglement. Attention il y a un CPU sur chaque carte qui ne traite en parallèle que 3 flux en duplex par l'intermediare de 2 fifo e/s du cross-bar, 2 flux (e/s) et le flux avec le bus PCI ceci quelques soit le nombre de cartes. Ceci implique naturelement un cross-bar pouvant transmettre en parallèle la totalité des flux exterieur mais pas ceux qui transite par le bus PCI. Naturelement si toutes les quatres cartes recoivent et emettes des données avec la machine proprement dite cela va de toute façon bouchoné sur le PCI mais ce n'est pas l'objectif de ce type de config orienté routage. De plus les processeurs de chaques cartes ne traitent que les headers puis s'occupe de planifier la connection directe entre les fifo e/s CB-Extérieur-PCI. C'est config m'a été un peu inspirée par les schèmas de la série C-5 de motorola. Le problème le plus tactique c'est l'implantation de QoS qui implique un fifo pour chaques priorités et ceci pour chaque flux. >en gros: crossbar switch implique soit un traitement >des paquet en hardware dedie, ou en network processor. Cette config à l'avantage de pouvoir charger le soft tournant sur le processeur des cartes et même éventuellement les config des PLD comme le chargement du firmware de produits tel que les carte C4 d'AVM. On peut même utilisé l'obscure option I20 du kernel. >reciproquement, un design avec un CPU central ne merite >guere plus qu'un bus passif (ou evt. plusieurs) tout a fait >standard. > >le probleme hardware est resolu. >c'est le but, le logiciel est deja un sacre bordel a gerer >(cf. grandeur et decadence de Cisco system). > > >un truc vraiment passionant est d'imaginer faire tourner >des morceaux de linux sur des network processors. Tu pense à des micro-serveurs ou des éléments de ce genre. Il me semble qu'il existe déjà des micro-serveurs avec juste une connextion rs-232 à connecter sur un modem et quelques e/s, ils sont basé sur microcontroleurs style PIC ou tous est integré dans une puce (ram,eeprom,clock,timer etc). Il sont utilisés pour des application de domotique comme par examples pour gérer le chauffage à distance. Dans ces cas on oublie le C, c'est de l'assembleur à fond la caise hystoire de grapiller quelques bytes. Tu peux également voir ce type d'application dans les transceiver Lantronix qui comporte un micro-serveur www et d'impression. Remarque on pourait envisager de prendre un peut plus de marge avec du hard comme celui proposé à l'adresse http://www.openhardware.net/ez328simm/index.php, mais c'est quand même 340$ pour une config avec la carte ethernet. >mais bon, encore une fois, pour 1Mbps de debit, c'est >un peu lourd comme solution :))) Naturelement ce sujet n'a aucun lien avec mon petit backbone qui pour moi techniquement est assez bien définit, il ne me reste qu'à affiné le compromis financier et persuader nos conseillés communaux. C'est plutôt un exercie de style qui à de forte probalité de ne pas aboutir mais me permet d'aprofondir mes connaisances étant donné qu'il y a relativement peu de temps que je me suis interessé au réseau et que mes connaissances dans ce domaine ne sont pas très étendues. C'est un peu de l'éveil technologique, il parait que ce terme est à la mode. Il faudrait peut-être changer le sujet du mail. A+ Martial >une question. Ouais, pour se désabonner aussi. -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Sat, Apr 20, 2002 at 03:32:16PM -0700, Martial Guex wrote: > At 13:15 20.04.02, you wrote: > >humm > >ton design, c'est bien joli, un peu sapin de noel, un peu beaucoup > >meme. > > C'est une première analyse qui n'est peut-être pas crédible alors si tu as > des arguments plus précis, je suis tout ouvert à tes remarques. > > >jusqu'a 1Gbps de debit total, aucune raison de prendre autre chose que > >PCI 64bit comme bus, pas de crossbar. > > Petit calcul on prend quatre cartes à 1 GB full duplex = 1GBytes/s, un bus > PCI 64 bits 66 Mhz = 528 MBytes/s (je ne sais même pas si il existe des > cartes mères avec plus de 2 slots 64 bits à 66 MHz), alor il y a un petit > problème. Martial, j'ai compris que tu es bon en electronique, pas besoin de continuer a le prouver :) de mon cote c'est l'experience du marche de routeurs dont je parle. je parlai d'un debit TOTAL de 1Gb/s, pas de 8Gb/s. un bus de 1Gb/s c'est ce qu'il y a dans un cisco7500. c'est rare qu'on ait besoin de plus, a moins que tu veuilles commencer par contruire un routeur qui degomme Cisco et Juniper. C'est ptetre un peu ambitieux pour un projet de temps libre :) je te parle de la pratique: ca fait 10 ans qu'elle est pasee par la chez les constructeurs de routeurs. Wellfleet, Cisco. je connais les differentes architectures de leur routeurs, y compris celle qui etait sexy sur papier glace, et un cauchemard pour les developpeur logiciel. celle qui n'ont pas marche parceque trop complexe. > >car le cpu serait des le depart le goulet d'etranglement. > > Attention il y a un CPU sur chaque carte qui ne traite en parallèle que 3 ca va etre joli a gerer en logiciel. Wellfleet, devenu Bay Network, devenu Nortel, est passe par la. ils ne vendent quasi plus au marche internet depuis 95. cisco, avec le 7500, ca fait 5 ans qu'il essaient de stabiliser leur logiciel gerant un CPU par interface. c'est toujours pas tres fiable a l'heure actuelle. Bref, de realiste dans ce domaine, il ne reste plus que l'option CPU central et bus passif (un PC quoi) d'un cote (tres souple au niveau developpement logiciel, c'est un PC, limite a 200 - 400 Mbit/s), et le tres tres haut debit avec un processeur specialise par interface (network proc) et un crossbar switch reliant le tout (pour des applic de plusieurs dizaine de Gb/s). > flux en duplex par l'intermediare de 2 fifo e/s du cross-bar, 2 flux (e/s) > et le flux avec le bus PCI ceci quelques soit le nombre de cartes. Ceci > implique naturelement un cross-bar pouvant transmettre en parallèle la > totalité des flux exterieur mais pas ceux qui transite par le bus PCI. > Naturelement si toutes les quatres cartes recoivent et emettes des données > avec la machine proprement dite cela va de toute façon bouchoné sur le PCI > mais ce n'est pas l'objectif de ce type de config orienté routage. De plus > les processeurs de chaques cartes ne traitent que les headers puis s'occupe > de planifier la connection directe entre les fifo e/s CB-Extérieur-PCI. > C'est config m'a été un peu inspirée par les schèmas de la série C-5 de > motorola. Le problème le plus tactique c'est l'implantation de QoS qui > implique un fifo pour chaques priorités et ceci pour chaque flux. > >un truc vraiment passionant est d'imaginer faire tourner > >des morceaux de linux sur des network processors. > > Tu pense à des micro-serveurs ou des éléments de ce genre. Il me semble > qu'il existe déjà des micro-serveurs avec juste une connextion rs-232 à oh non, ce sont des processeurs risc avec un pipeline a 16 niveau dedie au traitement des en-tete de paquets. c'est nouveau, ca sort des lab et des fonderies depuis ~98. ils peuvent traiter jusq'a 16 paquets en meme temps. enfin ca, c'est le detail commun de deux ou trois network proc du marche. ca se programme surtout en assembleur aussi, le C est pas tres adapter a l'exploitation des 16 niveaux de pipeline. http://www.gigascale.org/mescal/forum/44.html http://www.eetimes.com/story/industry/semiconductor_news/OEG2619S0011 http://www.cise.ufl.edu/~ashenoy/net_design.html http://www.mmcnet.com/ http://www.eetimes.com/story/OEG2508S0015 > connecter sur un modem et quelques e/s, ils sont basé sur microcontroleurs .. > >mais bon, encore une fois, pour 1Mbps de debit, c'est > >un peu lourd comme solution :))) > > Naturelement ce sujet n'a aucun lien avec mon petit backbone qui pour moi > techniquement est assez bien définit, il ne me reste qu'à affiné le > compromis financier et persuader nos conseillés communaux. > C'est plutôt un exercie de style qui à de forte probalité de ne pas aboutir je suis aussi comme ca. un peu trop en fait. depuis que je l'ai remarque, j'essaie de me concentrer sur des projets de temps libre qui peuvent tout de meme deboucher sur qqchose. il y a un tas de chose a faire en electronique du cote des interfaces reseau WAN pour bus PCI: 4x 8Mbit/s serielle X.21, 45Mbit/s DS3, 155 Mbit/s STM1. et la tu trouves des chips integres que tu interconnecte com
Re: FDDI ou ATM pour un backbone ?
On Sun, 21 Apr 2002, Philippe Strauss wrote: > je parlai d'un debit TOTAL de 1Gb/s, pas de 8Gb/s. > un bus de 1Gb/s c'est ce qu'il y a dans un cisco7500. c'est > rare qu'on ait besoin de plus, a moins que tu veuilles commencer > par contruire un routeur qui degomme Cisco et Juniper. C'est > ptetre un peu ambitieux pour un projet de temps libre :) Entre ``Les Rasses'' et ``Bullet'' ... Whaouh! :-) -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 01:00 21.04.02, you wrote: >Martial, j'ai compris que tu es bon en electronique, pas besoin >de continuer a le prouver :) de mon cote c'est l'experience du marche >de routeurs dont je parle. Ce n'était pas mon objectif, je soulignai simplement une des donnée qui m'avait influencé ver l'idée de mettre un bus en parallèle au PCI. De toute façon j'ai systematiquement les yeux plus gros que le ventre. >je parlai d'un debit TOTAL de 1Gb/s, pas de 8Gb/s. >un bus de 1Gb/s c'est ce qu'il y a dans un cisco7500. c'est >rare qu'on ait besoin de plus, a moins que tu veuilles commencer >par contruire un routeur qui degomme Cisco et Juniper. C'est >ptetre un peu ambitieux pour un projet de temps libre :) Remarque degommé Cisco me ferai particulièrement plaisir car je trouve qu'il en praine un peu à leur aise et de haut en plus. Pour Juniper, je n'ai pas encore de relation assez intime pour avoir une opignon. >je te parle de la pratique: ca fait 10 ans qu'elle est pasee par >la chez les constructeurs de routeurs. >Wellfleet, Cisco. >je connais les differentes architectures de leur routeurs, y compris >celle qui etait sexy sur papier glace, et un cauchemard pour >les developpeur logiciel. celle qui n'ont pas marche parceque trop >complexe. Quand il y a un problème logiciel, j'ai une plus grande confience sur le potentiel du libre que sur celui d'une boîte, quelque soit sa grandeur. L'important c'est d'offrir une infrastructure permettant une mise en oeuvre rapide et simple des dévelopeur et de cannaliser un peu les délire sur une cible bien définie, ce que tu fait très bien entre parentèse. >http://www.gigascale.org/mescal/forum/44.html >http://www.eetimes.com/story/industry/semiconductor_news/OEG2619S0011 >http://www.cise.ufl.edu/~ashenoy/net_design.html >http://www.mmcnet.com/ >http://www.eetimes.com/story/OEG2508S0015 Ben là il va faloir le temps que j'assimile pour avoir une vue d'ensemble. > > connecter sur un modem et quelques e/s, ils sont basé sur microcontroleurs >.. > >je suis aussi comme ca. un peu trop en fait. depuis que je l'ai >remarque, j'essaie de me concentrer sur des projets de temps >libre qui peuvent tout de meme deboucher sur qqchose. > >il y a un tas de chose a faire en electronique du cote >des interfaces reseau WAN pour bus PCI: 4x 8Mbit/s serielle X.21, 45Mbit/s >DS3, >155 Mbit/s STM1. > >et la tu trouves des chips integres que tu interconnecte >comme tu veux a un bus PCI. > >regarde chez infineon (siemens) leur controlleurs de communications. > >http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=15563&cat_oid=-9289 > >PMC sierra, un fabricant specialise dans les IC de communication: >(ca je sens que tu vas aimer:) > >http://www.pmcsierra.com/ Hummm, j'aime, encore. >et ca c'est des projets tout a fait realiste au vue de tes competences, >et ayant plus d'applications 'fun' (complete la gamme d'interface >disponible pour construire des routeurs linux), ca ca serait le pied >total!! > Effectivement, cela ouvre pas mal de perspective, on pourai envisagé quelque chose de plus léger avec une carte comportant deux ports ethernet, SDH où ATM qui serai spécialisée pour les pop's d'un réseau en anneau avec un processeur sur la carte afin de de faire passer sur le bus PCI seulement ce qui rentre et sort du pop. Cela devrai couvrir un marché entre le haut et le bas de game et donc d'avoir un petite chance d'être utilisé profesionnelement. A+ Marial -- MuTECH Martial Guex Rue des Alpes 1452 Les Rasses Switzerland Phone : +41 24 454 46 35 Fax. : +41 24 454 46 32 Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users) -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Sun, Apr 21, 2002 at 05:07:40AM -0700, Martial Guex wrote: > > Remarque degommé Cisco me ferai particulièrement plaisir car je trouve > qu'il en praine un peu à leur aise et de haut en plus. Pour Juniper, je encore recemment? y a deux ans ils se la petait sec mais nettement moins ces derniers mois :)) > Quand il y a un problème logiciel, j'ai une plus grande confience sur le > potentiel du libre que sur celui d'une boîte, quelque soit sa grandeur. > L'important c'est d'offrir une infrastructure permettant une mise en oeuvre > rapide et simple des dévelopeur et de cannaliser un peu les délire sur une > cible bien définie, ce que tu fait très bien entre parentèse. hehe :) merci. oui c'est claire, c'est pour ca qu'il vaut mieux rester tant que possible dans des developpement logiciels qui puissent tourner sur du hardware commun. juste etendre la maniere d'interfacer le hardware commun (le PC) et connaitre ses limites, les optimiser evt. > >http://www.pmcsierra.com/ > > Hummm, j'aime, encore. http://www2.linuxjournal.com/lj-issues/issue82/4455.html http://www.linleygroup.com/npu/ http://www.e-insite.net/ednmag/index.asp?layout=siteInfo&doc_id=31098 http://www-3.ibm.com/chips/techlib/techlib.nsf/products/IBM_PowerNP_NP4GS3 mais c'est pas du niveau de pmc sierra. (je suis en train de faire les a fond de printemps dans mes bookmarks :) a+ -- 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.
Re: FDDI ou ATM pour un backbone ?
On Sunday 21 April 2002 12:41, Félix Hauri wrote: > On Sun, 21 Apr 2002, Philippe Strauss wrote: > > je parlai d'un debit TOTAL de 1Gb/s, pas de 8Gb/s. > > un bus de 1Gb/s c'est ce qu'il y a dans un cisco7500. c'est > > rare qu'on ait besoin de plus, a moins que tu veuilles commencer > > par contruire un routeur qui degomme Cisco et Juniper. C'est > > ptetre un peu ambitieux pour un projet de temps libre :) > > Entre ``Les Rasses'' et ``Bullet'' ... Whaouh! :-) Je suis sûr que tu envisages de démager :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
On Wednesday 10 April 2002 09:35, Félix Hauri wrote: > Si tu viens et que tu dis un seul truc qui fait avancer les choses, > alors ta présence aurra été essentielle. > Si tu ne viens pas, on ne le saura jamais! ;-) L'affaire semble reglée... chui pas libre le 4... alors vous saurez jamais... et moi non plus <[:-) (l'est joli mon chapeau... non ? c'est pour le soleil) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: FDDI ou ATM pour un backbone ?
At 08.04.02 18'52, you wrote: Hello ! > > Puis on considére le tout comme 4 ligne ethernet que l'on gére avec une > > config QoS adéquoite. > > Il te semble que c'est possible ? > >C'est un sujet très délicat dans lequel les provider ne semblent pas vouloir >s'investir. Il semble que ça leur pose pas mal de problèmes au niveau de >leurs routeurs et de la gestion DNS... Eux aussi doivent assurer de la >redondance et l'échange d'infos de ce genre entre les routeurs ne paraît pas >évidente. > >A part ça, je ne me lancerais pas dans ce genre de truc. Assurer de >l'aggrégation, du load balancing et une redondance avec cette méthode me >semble hasardeux. De plus, tu auras besoins d'une montagne de volonté et de >collaboration de la part du provider, et là... j'ai des doutes. Même un peu après coup je confirme. La solution de vouloir séparer le tout en 4 connexions n'est pas possible sans mettre un serveur chez le provider qui fasse le routage. En effet, les 4 lignes auront 4 IPs différentes, une connexion TCP ne sera donc pas possible au travers des 4 lignes de manières balancée. Ou alors si tu as beaucoup de "clients", certains sont sur un des routeurs (une des 4 machines) et d'autres sur un autre... Mais ça sera fixe pour chaque personne. Car imagine que les lignes ADSL soient en partie sur le centre de Zürich lui-même connecté sur l'Allemagne et en partie sur Genève et la France (pour illustrer le problème). Donc ta seule solution serait de tout faire passer par un serveur chez le provider où tout le traffic passerait à double, traffic qu'il faudrait sans doute payer... Par contre, tu peux imaginer mettre ta *propre* ligne louée avec tes modems jusqu'à un point bon marché ? Voilà pour quelques points en éspérant ne pas avoir été redondant ;-) Denis -- Denis Bucher, / [EMAIL PROTECTED] Tél. +41-32-7254111 \ Internet Horus Networks / www.horus.infoFax: +41-32-7254112 \ Services / USA: (206) 888-2335 US Fax: (508) 437-1261 \ Provider -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
