j'ai actuellement un réseau local constitué de :
- un switch routeur firewall Netgear FR114P
- une freebox V2
- 1 PC équipé d'une interface ethernet 10/100/1000
- d'autres PC équipés de cartes ethernet 10/100 (Realtek)
Je souhaite augmenter les performances pour les transferts de gros
fichiers entre mes 2 PC principaux, j'envisage donc de remplacer
une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch
10/100/1000.
Les 2 PC principaux seraient connectés au nouveau switch,
celui-ci serait connecté au switch-routeur Netgear et les vieux PC
pourraient être connectés indifféremment au nouveau switch
ou à l'ancien switch-routeur Netgear.
J'ai regardé les prix des cartes réseaux 10/100/1000,
ça va de moins de 15 EUR à plus de 60 EUR.
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte
environ 20 EUR.
Sinon dans les premiers prix, il y a des Trendnet TEG-PCITX et
TEG-PCITXR, et aussi une Peabird PEAB-GIGA-32T à base de chip
Realtek.
Jusqu'à présent j'ai toujours été satisfait des cartes à base
de chips Realtek (en 10/100) et la seule carte plus chère que
j'ai, une Netgear, est en fait moins bien : elle ne partage pas les
IRQ.
J'utilise habituellement Windows 2000 et ponctuellement Linux
Knoppix, la compatibilité avec des distributions variées et
les kernels 2.2, 2.4, 2.6 serait un point positif intéressant.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear
GS105. Le boîtier du Netgear donne l'impression de solidité,
alors que celui du Dlink fait plutôt toc.
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte environ 20 EUR.
J'utilise habituellement Windows 2000 et ponctuellement Linux Knoppix, la compatibilité avec des distributions variées et les kernels 2.2, 2.4, 2.6 serait un point positif intéressant.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear GS105. Le boîtier du Netgear donne l'impression de solidité, alors que celui du Dlink fait plutôt toc.
Merci d'avance pour vos conseils et remarques.
Salut,
j'ai la carte DLink en question et le switch DGS1005. J'en suis pleinement satisfait. Pour la carte, elle est sur une machine en Linux kernel 2.6. Jamais essayé avec des 2.4 ou 2.2. Le switch est utilisé avec 2 PC en giga et 2 connections en 100Mb, aucun soucis.
Marc.
-- L'I2C sous Windows http://perso.club-internet.fr/mbouget/index.html
ATTENTION : enlevez les X pour répondre (remove all X to reply)
Bonjour,
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte
environ 20 EUR.
J'utilise habituellement Windows 2000 et ponctuellement Linux
Knoppix, la compatibilité avec des distributions variées et
les kernels 2.2, 2.4, 2.6 serait un point positif intéressant.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear
GS105. Le boîtier du Netgear donne l'impression de solidité,
alors que celui du Dlink fait plutôt toc.
Merci d'avance pour vos conseils et remarques.
Salut,
j'ai la carte DLink en question et le switch DGS1005. J'en suis
pleinement satisfait.
Pour la carte, elle est sur une machine en Linux kernel 2.6. Jamais
essayé avec des 2.4 ou 2.2.
Le switch est utilisé avec 2 PC en giga et 2 connections en 100Mb, aucun
soucis.
Marc.
--
L'I2C sous Windows
http://perso.club-internet.fr/mbouget/index.html
ATTENTION : enlevez les X pour répondre (remove all X to reply)
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte environ 20 EUR.
J'utilise habituellement Windows 2000 et ponctuellement Linux Knoppix, la compatibilité avec des distributions variées et les kernels 2.2, 2.4, 2.6 serait un point positif intéressant.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear GS105. Le boîtier du Netgear donne l'impression de solidité, alors que celui du Dlink fait plutôt toc.
Merci d'avance pour vos conseils et remarques.
Salut,
j'ai la carte DLink en question et le switch DGS1005. J'en suis pleinement satisfait. Pour la carte, elle est sur une machine en Linux kernel 2.6. Jamais essayé avec des 2.4 ou 2.2. Le switch est utilisé avec 2 PC en giga et 2 connections en 100Mb, aucun soucis.
Marc.
-- L'I2C sous Windows http://perso.club-internet.fr/mbouget/index.html
ATTENTION : enlevez les X pour répondre (remove all X to reply)
Paul Atreides
In article , says...
Bonjour,
j'ai actuellement un réseau local constitué de : - un switch routeur firewall Netgear FR114P - une freebox V2 - 1 PC équipé d'une interface ethernet 10/100/1000 - d'autres PC équipés de cartes ethernet 10/100 (Realtek)
Je souhaite augmenter les performances pour les transferts de gros fichiers entre mes 2 PC principaux, j'envisage donc de remplacer une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch 10/100/1000.
Bonjour,
Quelles sont les performances actuelles ?
Quel gain attendez vous ?
Salutations.
-- ICQ# 114297372
In article <450290C2.FA1BBA84@ifrance.com>, nonlu@ifrance.com says...
Bonjour,
j'ai actuellement un réseau local constitué de :
- un switch routeur firewall Netgear FR114P
- une freebox V2
- 1 PC équipé d'une interface ethernet 10/100/1000
- d'autres PC équipés de cartes ethernet 10/100 (Realtek)
Je souhaite augmenter les performances pour les transferts de gros
fichiers entre mes 2 PC principaux, j'envisage donc de remplacer
une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch
10/100/1000.
j'ai actuellement un réseau local constitué de : - un switch routeur firewall Netgear FR114P - une freebox V2 - 1 PC équipé d'une interface ethernet 10/100/1000 - d'autres PC équipés de cartes ethernet 10/100 (Realtek)
Je souhaite augmenter les performances pour les transferts de gros fichiers entre mes 2 PC principaux, j'envisage donc de remplacer une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch 10/100/1000.
Bonjour,
Quelles sont les performances actuelles ?
Quel gain attendez vous ?
Salutations.
-- ICQ# 114297372
Europe
Bonjour,
Quelles sont les performances actuelles ?
Quel gain attendez vous ?
Salutations.
Très très bonne question !! Je viens de passer en gigabit et sauf à avoir des machines ultra rapide avec des disques ultra rapides, je ne pense pas que tu vois beaucoup de différence. Je devais faire évoluer du matériel, alors je l'ai pris en Giga, mais changer pour changer, non.
Bonjour,
Quelles sont les performances actuelles ?
Quel gain attendez vous ?
Salutations.
Très très bonne question !!
Je viens de passer en gigabit et sauf à avoir des machines ultra rapide avec
des disques ultra rapides, je ne pense pas que tu vois beaucoup de
différence.
Je devais faire évoluer du matériel, alors je l'ai pris en Giga, mais
changer pour changer, non.
Très très bonne question !! Je viens de passer en gigabit et sauf à avoir des machines ultra rapide avec des disques ultra rapides, je ne pense pas que tu vois beaucoup de différence. Je devais faire évoluer du matériel, alors je l'ai pris en Giga, mais changer pour changer, non.
Pascal Hambourg
Salut,
Je viens de passer en gigabit et sauf à avoir des machines ultra rapide avec des disques ultra rapides, je ne pense pas que tu vois beaucoup de différence.
Bien sûr que si. Même sans taper dans le haut de gamme, n'importe quels disque dur et machine de ces dernières années peut soutenir des débits de l'ordre de 50 Mo/s, alors que le Fast Ethernet dépasse à peine 10 Mo/s. Sur des transferts de *gros* fichiers la différence se verra.
Salut,
Je viens de passer en gigabit et sauf à avoir des machines ultra rapide avec
des disques ultra rapides, je ne pense pas que tu vois beaucoup de
différence.
Bien sûr que si. Même sans taper dans le haut de gamme, n'importe quels
disque dur et machine de ces dernières années peut soutenir des débits
de l'ordre de 50 Mo/s, alors que le Fast Ethernet dépasse à peine 10
Mo/s. Sur des transferts de *gros* fichiers la différence se verra.
Je viens de passer en gigabit et sauf à avoir des machines ultra rapide avec des disques ultra rapides, je ne pense pas que tu vois beaucoup de différence.
Bien sûr que si. Même sans taper dans le haut de gamme, n'importe quels disque dur et machine de ces dernières années peut soutenir des débits de l'ordre de 50 Mo/s, alors que le Fast Ethernet dépasse à peine 10 Mo/s. Sur des transferts de *gros* fichiers la différence se verra.
Le Gaulois
Bpnjour,
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte environ 20 EUR.
j'ai la carte DLink en question et le switch DGS1005. J'en suis pleinement satisfait. Pour la carte, elle est sur une machine en Linux kernel 2.6. Jamais essayé avec des 2.4 ou 2.2. Le switch est utilisé avec 2 PC en giga et 2 connections en 100Mb, aucun soucis.
Dans fr.comp.os.linux.configuration on me conseille plutôt la DGE-528T (à base de circuit Realtek 8169) qui vaut moins cher. Je tirerai à pile ou face, ou je prendrai ce que je trouverai dans la première boutique ou je rentrerai.
Merci pour les avis.
Bpnjour,
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte
environ 20 EUR.
j'ai la carte DLink en question et le switch DGS1005. J'en suis
pleinement satisfait.
Pour la carte, elle est sur une machine en Linux kernel 2.6. Jamais
essayé avec des 2.4 ou 2.2.
Le switch est utilisé avec 2 PC en giga et 2 connections en 100Mb, aucun
soucis.
Dans fr.comp.os.linux.configuration on me conseille plutôt la
DGE-528T (à base de circuit Realtek 8169) qui vaut moins cher.
Je tirerai à pile ou face, ou je prendrai ce que je trouverai
dans la première boutique ou je rentrerai.
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte environ 20 EUR.
j'ai la carte DLink en question et le switch DGS1005. J'en suis pleinement satisfait. Pour la carte, elle est sur une machine en Linux kernel 2.6. Jamais essayé avec des 2.4 ou 2.2. Le switch est utilisé avec 2 PC en giga et 2 connections en 100Mb, aucun soucis.
Dans fr.comp.os.linux.configuration on me conseille plutôt la DGE-528T (à base de circuit Realtek 8169) qui vaut moins cher. Je tirerai à pile ou face, ou je prendrai ce que je trouverai dans la première boutique ou je rentrerai.
Merci pour les avis.
Marc
Dans fr.comp.os.linux.configuration on me conseille plutôt la DGE-528T (à base de circuit Realtek 8169) qui vaut moins cher. Je tirerai à pile ou face, ou je prendrai ce que je trouverai dans la première boutique ou je rentrerai.
Merci pour les avis.
Je viens de vérifier, c'est également une 528T dans ma machine (et pas la 530).
Marc.
-- L'I2C sous Windows http://perso.club-internet.fr/mbouget/index.html
ATTENTION : enlevez les X pour répondre (remove all X to reply)
Dans fr.comp.os.linux.configuration on me conseille plutôt la
DGE-528T (à base de circuit Realtek 8169) qui vaut moins cher.
Je tirerai à pile ou face, ou je prendrai ce que je trouverai
dans la première boutique ou je rentrerai.
Merci pour les avis.
Je viens de vérifier, c'est également une 528T dans ma machine (et pas
la 530).
Marc.
--
L'I2C sous Windows
http://perso.club-internet.fr/mbouget/index.html
ATTENTION : enlevez les X pour répondre (remove all X to reply)
Dans fr.comp.os.linux.configuration on me conseille plutôt la DGE-528T (à base de circuit Realtek 8169) qui vaut moins cher. Je tirerai à pile ou face, ou je prendrai ce que je trouverai dans la première boutique ou je rentrerai.
Merci pour les avis.
Je viens de vérifier, c'est également une 528T dans ma machine (et pas la 530).
Marc.
-- L'I2C sous Windows http://perso.club-internet.fr/mbouget/index.html
ATTENTION : enlevez les X pour répondre (remove all X to reply)
Andre Majorel
On 2006-09-09, Le Gaulois wrote:
Je souhaite augmenter les performances pour les transferts de gros fichiers entre mes 2 PC principaux, j'envisage donc de remplacer une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch 10/100/1000.
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte environ 20 EUR.
Sinon dans les premiers prix, il y a des Trendnet TEG-PCITX et TEG-PCITXR, et aussi une Peabird PEAB-GIGA-32T à base de chip Realtek.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear GS105. Le boîtier du Netgear donne l'impression de solidité, alors que celui du Dlink fait plutôt toc.
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
Sur un serveur, c'est inadmissible. Sur un machine mono-utilisateur, ce n'est pas forcément génant. Faut voir.
En 100 Mbps, le chip Realtek 8139 avait déjà ce problème. Un chip gigabit aussi merdique serait inutilisable. J'espère que le 8169 est meilleur.
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
C'est le cas des GS1xx de fabrication récente mais pas des versions antérieures (face avant beaucoup plus large que l'harmonica). Comme Netgear garde les mêmes références, il faut demander à voir la boîte avant d'acheter.
Quand à D-Link, j'aimais bien leurs cartes DFE-530TX mais leurs petits hubs et switches... On en avait cinq au boulot, trois sont morts. Nos gros D-Link rackables (>= 16 ports) résistent bien par contre.
Pour les cartes... À ce qu'il paraît, le meilleur chip gigabit PCI serait celui des Intel Pro 1000 (driver e1000). Elle sont difficiles à trouver en magasin, mais dispo pour pas trop cher chez materiel.net et/ou ldlc.com. J'en ai chez moi et elles me donnent satisfaction mais je ne les ai encore utilisées qu'en 100 Mbps.
Le Marvell 88E8053 (PCI 11ab:4362, rev 15), théoriquement géré par le driver sky2, n'était en fait pas reconnu en 2.6.14 mais les choses ont probablement évolué depuis.
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) Religion: a magic device for turning unanswerable questions into unquestionable answers. -- Art Gecko
On 2006-09-09, Le Gaulois <nonlu@ifrance.com> wrote:
Je souhaite augmenter les performances pour les transferts de gros
fichiers entre mes 2 PC principaux, j'envisage donc de remplacer
une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch
10/100/1000.
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte
environ 20 EUR.
Sinon dans les premiers prix, il y a des Trendnet TEG-PCITX et
TEG-PCITXR, et aussi une Peabird PEAB-GIGA-32T à base de chip
Realtek.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear
GS105. Le boîtier du Netgear donne l'impression de solidité,
alors que celui du Dlink fait plutôt toc.
Le choix d'une carte gigabit est délicat parce que les trames
sont tellement rapprochées à cette vitesse que si la carte émet
une IRQ par trame, le processeur passera une bonne partie de son
temps à honorer les IRQ. À la limite, le processeur peut devenir
le goulot d'étranglement.
Sur un serveur, c'est inadmissible. Sur un machine
mono-utilisateur, ce n'est pas forcément génant. Faut voir.
En 100 Mbps, le chip Realtek 8139 avait déjà ce problème. Un
chip gigabit aussi merdique serait inutilisable. J'espère que le
8169 est meilleur.
Pour éviter cet inconvénient, on utilise les jumbo frames, des
trames de 9 k au lieu de 1500 octets habituels. Trames plus
grosses = moins de trames par unité de temps = moins de travail
pour le processeur à débit égal. Il faut que les cartes et le
switch le gèrent.
C'est le cas des GS1xx de fabrication récente mais pas des
versions antérieures (face avant beaucoup plus large que
l'harmonica). Comme Netgear garde les mêmes références, il faut
demander à voir la boîte avant d'acheter.
Quand à D-Link, j'aimais bien leurs cartes DFE-530TX mais leurs
petits hubs et switches... On en avait cinq au boulot, trois
sont morts. Nos gros D-Link rackables (>= 16 ports) résistent
bien par contre.
Pour les cartes... À ce qu'il paraît, le meilleur chip gigabit
PCI serait celui des Intel Pro 1000 (driver e1000). Elle sont
difficiles à trouver en magasin, mais dispo pour pas trop cher
chez materiel.net et/ou ldlc.com. J'en ai chez moi et elles me
donnent satisfaction mais je ne les ai encore utilisées qu'en
100 Mbps.
Le Marvell 88E8053 (PCI 11ab:4362, rev 15), théoriquement géré
par le driver sky2, n'était en fait pas reconnu en 2.6.14 mais
les choses ont probablement évolué depuis.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: ipacuk@shameful.com ikuroh@compression.com)
Religion: a magic device for turning unanswerable questions into
unquestionable answers. -- Art Gecko
Je souhaite augmenter les performances pour les transferts de gros fichiers entre mes 2 PC principaux, j'envisage donc de remplacer une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch 10/100/1000.
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte environ 20 EUR.
Sinon dans les premiers prix, il y a des Trendnet TEG-PCITX et TEG-PCITXR, et aussi une Peabird PEAB-GIGA-32T à base de chip Realtek.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear GS105. Le boîtier du Netgear donne l'impression de solidité, alors que celui du Dlink fait plutôt toc.
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
Sur un serveur, c'est inadmissible. Sur un machine mono-utilisateur, ce n'est pas forcément génant. Faut voir.
En 100 Mbps, le chip Realtek 8139 avait déjà ce problème. Un chip gigabit aussi merdique serait inutilisable. J'espère que le 8169 est meilleur.
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
C'est le cas des GS1xx de fabrication récente mais pas des versions antérieures (face avant beaucoup plus large que l'harmonica). Comme Netgear garde les mêmes références, il faut demander à voir la boîte avant d'acheter.
Quand à D-Link, j'aimais bien leurs cartes DFE-530TX mais leurs petits hubs et switches... On en avait cinq au boulot, trois sont morts. Nos gros D-Link rackables (>= 16 ports) résistent bien par contre.
Pour les cartes... À ce qu'il paraît, le meilleur chip gigabit PCI serait celui des Intel Pro 1000 (driver e1000). Elle sont difficiles à trouver en magasin, mais dispo pour pas trop cher chez materiel.net et/ou ldlc.com. J'en ai chez moi et elles me donnent satisfaction mais je ne les ai encore utilisées qu'en 100 Mbps.
Le Marvell 88E8053 (PCI 11ab:4362, rev 15), théoriquement géré par le driver sky2, n'était en fait pas reconnu en 2.6.14 mais les choses ont probablement évolué depuis.
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) Religion: a magic device for turning unanswerable questions into unquestionable answers. -- Art Gecko
Pascal Hambourg
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne pourrait-elle pas être exploitée pour réduire le nombre d'interruptions (une par rafale au lieu d'une par trame) ?
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles. Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
Le choix d'une carte gigabit est délicat parce que les trames
sont tellement rapprochées à cette vitesse que si la carte émet
une IRQ par trame, le processeur passera une bonne partie de son
temps à honorer les IRQ. À la limite, le processeur peut devenir
le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne
pourrait-elle pas être exploitée pour réduire le nombre d'interruptions
(une par rafale au lieu d'une par trame) ?
Pour éviter cet inconvénient, on utilise les jumbo frames, des
trames de 9 k au lieu de 1500 octets habituels. Trames plus
grosses = moins de trames par unité de temps = moins de travail
pour le processeur à débit égal. Il faut que les cartes et le
switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui
ne supportent pas les jumbo frames ?
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne pourrait-elle pas être exploitée pour réduire le nombre d'interruptions (une par rafale au lieu d'une par trame) ?
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles. Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
Andre Majorel
On 2006-09-13, Pascal Hambourg wrote:
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne pourrait-elle pas être exploitée pour réduire le nombre d'interruptions (une par rafale au lieu d'une par trame) ?
Sais pas.
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles. Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination mais qu'elle est capable de la réduire jusqu'à ce que ça passe. Ça marche même pour NFS qui est, que je sache, de l'UDP.
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) "Duty, honor, country" -- Douglas MacArthur "Travail, famille, patrie" -- Philippe Pétain
On 2006-09-13, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Le choix d'une carte gigabit est délicat parce que les trames
sont tellement rapprochées à cette vitesse que si la carte émet
une IRQ par trame, le processeur passera une bonne partie de son
temps à honorer les IRQ. À la limite, le processeur peut devenir
le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne
pourrait-elle pas être exploitée pour réduire le nombre d'interruptions
(une par rafale au lieu d'une par trame) ?
Sais pas.
Pour éviter cet inconvénient, on utilise les jumbo frames, des
trames de 9 k au lieu de 1500 octets habituels. Trames plus
grosses = moins de trames par unité de temps = moins de travail
pour le processeur à débit égal. Il faut que les cartes et le
switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui
ne supportent pas les jumbo frames ?
Après quelques rapides tests : ça se passe mieux que ce qu'on
pourrait craindre.
On active les jumbo frames sur une interface en faisant, par
exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une
autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU
1500), il y a un délai d'une ou deux secondes mais on finit par
y arriver.
Je suppose que la couche réseau Linux n'est pas capable de se
souvenir de la taille des paquets à utiliser par destination
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Ça marche même pour NFS qui est, que je sache, de l'UDP.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: pidaxulen@charon.com anohar@irritable.com)
"Duty, honor, country" -- Douglas MacArthur
"Travail, famille, patrie" -- Philippe Pétain
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne pourrait-elle pas être exploitée pour réduire le nombre d'interruptions (une par rafale au lieu d'une par trame) ?
Sais pas.
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles. Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination mais qu'elle est capable de la réduire jusqu'à ce que ça passe. Ça marche même pour NFS qui est, que je sache, de l'UDP.
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) "Duty, honor, country" -- Douglas MacArthur "Travail, famille, patrie" -- Philippe Pétain
Dominique ROUSSEAU
Le dim, 27 mai 2007 at 14:17 GMT, Andre Majorel a écrit :
On 2006-09-13, Pascal Hambourg wrote:
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne pourrait-elle pas être exploitée pour réduire le nombre d'interruptions (une par rafale au lieu d'une par trame) ?
Sais pas.
Parmi les cartes supportant NAPI sous Linux (je vois que plus bas ça parle de cet OS), il y en a qui supporte l'utilisation en mode polling. Coouplé à une carte possédant un buffer conséquent, ça permet au processeur d'aller voir quand il veut si la carte a des données. Si on a suffisament d'activité pour justifier de ne plus passer en mode IRQ, ça sera de toute façon toujours le cas :) Certains drivers (je pense au e1000 notamment) supportent également de ne generer des IRQ que tous les "X paquets".
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles. Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Ca doit fonctionner si l'icmp n'est pas filtré. Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut pas recevoir les données, et demander la fragmentation, par exemple.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination mais qu'elle est capable de la réduire jusqu'à ce que ça passe. Ça marche même pour NFS qui est, que je sache, de l'UDP.
NFS peut fonctionner en TCP, également.
Le dim, 27 mai 2007 at 14:17 GMT, Andre Majorel <cheney@halliburton.com> a écrit :
On 2006-09-13, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Le choix d'une carte gigabit est délicat parce que les trames
sont tellement rapprochées à cette vitesse que si la carte émet
une IRQ par trame, le processeur passera une bonne partie de son
temps à honorer les IRQ. À la limite, le processeur peut devenir
le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne
pourrait-elle pas être exploitée pour réduire le nombre d'interruptions
(une par rafale au lieu d'une par trame) ?
Sais pas.
Parmi les cartes supportant NAPI sous Linux (je vois que plus bas ça
parle de cet OS), il y en a qui supporte l'utilisation en mode polling.
Coouplé à une carte possédant un buffer conséquent, ça permet au
processeur d'aller voir quand il veut si la carte a des données.
Si on a suffisament d'activité pour justifier de ne plus passer en mode
IRQ, ça sera de toute façon toujours le cas :)
Certains drivers (je pense au e1000 notamment) supportent également de
ne generer des IRQ que tous les "X paquets".
Pour éviter cet inconvénient, on utilise les jumbo frames, des
trames de 9 k au lieu de 1500 octets habituels. Trames plus
grosses = moins de trames par unité de temps = moins de travail
pour le processeur à débit égal. Il faut que les cartes et le
switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui
ne supportent pas les jumbo frames ?
Après quelques rapides tests : ça se passe mieux que ce qu'on
pourrait craindre.
On active les jumbo frames sur une interface en faisant, par
exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une
autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU
1500), il y a un délai d'une ou deux secondes mais on finit par
y arriver.
Ca doit fonctionner si l'icmp n'est pas filtré.
Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut
pas recevoir les données, et demander la fragmentation, par exemple.
Je suppose que la couche réseau Linux n'est pas capable de se
souvenir de la taille des paquets à utiliser par destination
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Ça marche même pour NFS qui est, que je sache, de l'UDP.
Le dim, 27 mai 2007 at 14:17 GMT, Andre Majorel a écrit :
On 2006-09-13, Pascal Hambourg wrote:
Le choix d'une carte gigabit est délicat parce que les trames sont tellement rapprochées à cette vitesse que si la carte émet une IRQ par trame, le processeur passera une bonne partie de son temps à honorer les IRQ. À la limite, le processeur peut devenir le goulot d'étranglement.
La fonctionnalité d'envoi de trames en rafale du gigabit ethernet ne pourrait-elle pas être exploitée pour réduire le nombre d'interruptions (une par rafale au lieu d'une par trame) ?
Sais pas.
Parmi les cartes supportant NAPI sous Linux (je vois que plus bas ça parle de cet OS), il y en a qui supporte l'utilisation en mode polling. Coouplé à une carte possédant un buffer conséquent, ça permet au processeur d'aller voir quand il veut si la carte a des données. Si on a suffisament d'activité pour justifier de ne plus passer en mode IRQ, ça sera de toute façon toujours le cas :) Certains drivers (je pense au e1000 notamment) supportent également de ne generer des IRQ que tous les "X paquets".
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels. Trames plus grosses = moins de trames par unité de temps = moins de travail pour le processeur à débit égal. Il faut que les cartes et le switch le gèrent.
Et surtout il faut que tous les éléments du réseau soient compatibles. Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Ca doit fonctionner si l'icmp n'est pas filtré. Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut pas recevoir les données, et demander la fragmentation, par exemple.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination mais qu'elle est capable de la réduire jusqu'à ce que ça passe. Ça marche même pour NFS qui est, que je sache, de l'UDP.
