Poster une réponse à un sujet: [NETWORK] Test de 20 ports Ethernet
Attention, ce sujet est un sujet ancien (2514 jours sans réponse)
Jean-Christophe
Je ne sais pas très bien ce que tu veux tester exactement mais si les conditions varient entre les tests, certains résultats pourraient être caduques. Et si c'est un test binaire ça fonctionne oui/non, tu n'as pas besoin de tout ça.
Idéalement, dans une procédure de test, il n'y a que l'élément que tu testes qui varie.
Idéalement, dans une procédure de test, il n'y a que l'élément que tu testes qui varie.
blietaer
C'est un très bon point.
Je ne sais pas à quel point le côté Real-time des performances est sensible ou non.
Je pense que dans ce genre de cas de figure, c'est surtout le côté 'intègre' qui va compter.
Je ne sais pas à quel point le côté Real-time des performances est sensible ou non.
Je pense que dans ce genre de cas de figure, c'est surtout le côté 'intègre' qui va compter.
Jean-Christophe
Le problème de la solution B, c'est que le PC en question fera aussi d'autres choses en même temps. Tu n'auras donc pas une solution stable pour tes tests.
Si tu as un ralentissement sur un ou deux ports, comment peux-tu être certain que c'est ton bidule qui foire et pas que le PC était en train de faire autre chose à ce moment là et que cet autre process à ralenti le transfert ?
Si tu as un ralentissement sur un ou deux ports, comment peux-tu être certain que c'est ton bidule qui foire et pas que le PC était en train de faire autre chose à ce moment là et que cet autre process à ralenti le transfert ?
blietaer
Ha ok parfait !
Merci pour ton temps et ces pistes.
Ici ils ont une (petite) préférence pour la solution b.), dans le sens où cela implique un PC linux qui servira de toute façons de Unit Tester pour allumer/éteindre le power supply, lancer des commandes RS-422,... Du coup, avoir ce type de machine avec 20 ports réseau est une autre piste.
Mais je dois continuer à investiguer les 3 pistes (dont la tienne) de front en attendant de vraiment se décider.
Merci pour ton temps et ces pistes.
Ici ils ont une (petite) préférence pour la solution b.), dans le sens où cela implique un PC linux qui servira de toute façons de Unit Tester pour allumer/éteindre le power supply, lancer des commandes RS-422,... Du coup, avoir ce type de machine avec 20 ports réseau est une autre piste.
Mais je dois continuer à investiguer les 3 pistes (dont la tienne) de front en attendant de vraiment se décider.
Jean-Christophe
MMMh bonne piste oui !
Je pense que je devrais quand même faire un tests avec les 20 en même temps.
"Syno" comme dans....un "NAS" ?
C'est pour faire quoi l'agregation des 4 ports?
je peux envoyer un gros fichier sur lui-même et le comparer (hash) du coup? c'est ça l'idée?
Je pense que je devrais quand même faire un tests avec les 20 en même temps.
"Syno" comme dans....un "NAS" ?
C'est pour faire quoi l'agregation des 4 ports?
je peux envoyer un gros fichier sur lui-même et le comparer (hash) du coup? c'est ça l'idée?
L'agrégat sert à donner un taux de transfert plus rapide. 4 liens -> 4 fois plus rapide. Le but est que tu es certain, dans ce cas, que ce n'est pas le lien entre le stockage et le switch qui pose souci ou qui est lent.
Syno comme NAS, oui
Le but est ici d'avoir un support qui ne servent qu'à ça et dont les conditions sont stables et connues. Tu peux alors y stocker un panel de petits, moyens ou gros fichiers pour tester tes taux de transfert.
Pour tester les 20 ports à la fois, soit tu y branches 20 stockages différents, soit tu trouves un stockage et un réseau qui peut passer 20Gb/s Tu risques de peiner à trouver ça. Pour le moment, en réseau classique, on est en 10Gb/s par lien. Tu peux les agréger mais si tu trouves un switch pour gérer ça, ça va te coûter la peau des fesses.
Si tu vas vers une solution comme celle que je te propose, avec un switch malin, tu peux aussi suivre les packets lost, les taux de transfert, les erreurs, etc. en temps presque réel via SNMP et te générer un beau rapport sur base des infos recueillies.
blietaer
Ha mais ça n'a rien de secret c'était juste pour pas encombrer de détails inutiles: ce sont deux curtis-W collées ensemble pour redondance (cold start): https://www.curtisswrightds.com/products/cots-boards/ethernet-switches-routers/pc104-switch/swi-22-10.html
Le tout enrobé de chocolat développement hardware 'maison' pour le basculement du power, pendant que les 20 ports G.E. exterieurs n'y voient que du feu (à qques pckt lost près...)
Du coup...moui: ça a le gout, le couleur et l'aspect d'un switch manageable
Le tout enrobé de chocolat développement hardware 'maison' pour le basculement du power, pendant que les 20 ports G.E. exterieurs n'y voient que du feu (à qques pckt lost près...)
Du coup...moui: ça a le gout, le couleur et l'aspect d'un switch manageable
ovh
C'est quoi ton appareil secret ?
blietaer
MMMh bonne piste oui !
Je pense que je devrais quand même faire un tests avec les 20 en même temps.
"Syno" comme dans....un "NAS" ?
C'est pour faire quoi l'agregation des 4 ports?
je peux envoyer un gros fichier sur lui-même et le comparer (hash) du coup? c'est ça l'idée?
Je pense que je devrais quand même faire un tests avec les 20 en même temps.
"Syno" comme dans....un "NAS" ?
C'est pour faire quoi l'agregation des 4 ports?
je peux envoyer un gros fichier sur lui-même et le comparer (hash) du coup? c'est ça l'idée?
Jean-Christophe
Le but est de tester les 20 ports en même temps?
Si tu peux le faire en séquence, tu peux toujours trouver un switch 24 ports de qualité, brancher tes 20 ports dessus, sur les ports restant, un syno moderne avec 4 ports en agrégat et faire tes tests de transfert à ton aise, un port à la fois, sans devoir changer tout le hardware entre chaque port.
Et si tu veux éviter de devoir faire la config IP des 20 ports de ton "truc", tu peux toujours causer au switch en SNMP pour activer/désactiver ses ports pour tester un par un les ports de ton "truc". Tu laisses le switch gérer le DHCP et l'activation/désactivation des 20 ports qui sont à tester.
Si tu peux le faire en séquence, tu peux toujours trouver un switch 24 ports de qualité, brancher tes 20 ports dessus, sur les ports restant, un syno moderne avec 4 ports en agrégat et faire tes tests de transfert à ton aise, un port à la fois, sans devoir changer tout le hardware entre chaque port.
Et si tu veux éviter de devoir faire la config IP des 20 ports de ton "truc", tu peux toujours causer au switch en SNMP pour activer/désactiver ses ports pour tester un par un les ports de ton "truc". Tu laisses le switch gérer le DHCP et l'activation/désactivation des 20 ports qui sont à tester.
blietaer
Bonjour à tous,
Encore une fois je suis vraiment navré de poser ici une question en rapport avec de l'informatique: croyez bien que je me rends compte combien c'est déplacé et hors sujet par rapport aux discussions principales qui occupent ce forum.
(Bien entendu, je tenterai ma chance sur le forum d'en face, beaucoup plus à l'aise dans les transitions de sujet sur les Firewall jusqu'à Hitler: ça peut servir)
Dans le cadre du boulot, je voudrais tester un 'device' (on n'a qu'à dire que c'est un comme un switch) de 20 ports Gigabit Ethernet.
L'idée sera de tester au niveau physique/électrique la gueule des signaux (mais pour ça on a déjà le bon scope digital qui va bien), mais également d'un point de vue fonctionnel/performances.
Pour ce dernier scenario, il faudra pousser de la donnée à plein régime, mais aussi un peu comparer les packets/latences.
J'envisage alors 3 cas de figure:
a.) un jouet tout cuit qui présente nativement 20+ ports et qui permet de les diagnostiquer
(-) pas vraiment de référence en tête
(-) pris du-dit jouet
(+) pas de dev. maison
(+) pas d'étalonnage nécessaire/ rapports tout cuits.
b.) une grosse tour bien baveuse avec 5x cartes Pci-e 4 ports et un bon gros Linux
(+) Linux comporte déjà une bonne chiée d'outils (iperf, tcpdump,...) pour faire cela
(+) Tout est synchro dans une même machine
(+) Certainement la solution la moins chère
(-) Faut un peu coder/étalonner/découvrir et créer un environnement de tests/rapports.
c.) un stack de 20 cartes ODROID C2 (genre Raspberry-Pi, mais pour adulte, avec du vrai G.E. natif) et des petits Linux
(+) Linux comporte déjà une bonne chiée d'outils (iperf, tcpdump,...) pour faire cela
(-) faut synchroniser les tests/récupérer les résultats sur...20 devices
(-) Encombrement/brols
(-) Faut un peu coder/étalonner/découvrir et créer un environnement de tests/rapports.
Je peux clairement envisager d'autres scenarios, faisant appels (ou pas) à une partie de ces 3 premières solutions...
Tout avis/modèles/expérience/commentaire est bienvenu !
Merci à vous,
Et vous pouvez reprendre vos discussions sur le dernier Star Wars.
PSssst: Han shot first.
Encore une fois je suis vraiment navré de poser ici une question en rapport avec de l'informatique: croyez bien que je me rends compte combien c'est déplacé et hors sujet par rapport aux discussions principales qui occupent ce forum.
(Bien entendu, je tenterai ma chance sur le forum d'en face, beaucoup plus à l'aise dans les transitions de sujet sur les Firewall jusqu'à Hitler: ça peut servir)
Dans le cadre du boulot, je voudrais tester un 'device' (on n'a qu'à dire que c'est un comme un switch) de 20 ports Gigabit Ethernet.
L'idée sera de tester au niveau physique/électrique la gueule des signaux (mais pour ça on a déjà le bon scope digital qui va bien), mais également d'un point de vue fonctionnel/performances.
Pour ce dernier scenario, il faudra pousser de la donnée à plein régime, mais aussi un peu comparer les packets/latences.
J'envisage alors 3 cas de figure:
a.) un jouet tout cuit qui présente nativement 20+ ports et qui permet de les diagnostiquer
(-) pas vraiment de référence en tête
(-) pris du-dit jouet
(+) pas de dev. maison
(+) pas d'étalonnage nécessaire/ rapports tout cuits.
b.) une grosse tour bien baveuse avec 5x cartes Pci-e 4 ports et un bon gros Linux
(+) Linux comporte déjà une bonne chiée d'outils (iperf, tcpdump,...) pour faire cela
(+) Tout est synchro dans une même machine
(+) Certainement la solution la moins chère
(-) Faut un peu coder/étalonner/découvrir et créer un environnement de tests/rapports.
c.) un stack de 20 cartes ODROID C2 (genre Raspberry-Pi, mais pour adulte, avec du vrai G.E. natif) et des petits Linux
(+) Linux comporte déjà une bonne chiée d'outils (iperf, tcpdump,...) pour faire cela
(-) faut synchroniser les tests/récupérer les résultats sur...20 devices
(-) Encombrement/brols
(-) Faut un peu coder/étalonner/découvrir et créer un environnement de tests/rapports.
Je peux clairement envisager d'autres scenarios, faisant appels (ou pas) à une partie de ces 3 premières solutions...
Tout avis/modèles/expérience/commentaire est bienvenu !
Merci à vous,
Et vous pouvez reprendre vos discussions sur le dernier Star Wars.
PSssst: Han shot first.