Bonjour,  
Je dois acheter du matériel et j'ai une problématique sur la vitesse de mes flux.
Voici un grossier schéma, je vais expliquer :
 
camera -----1G--------
                               SG200-18 ========?======convertisseur---carte intel giga
automate---100mb----
 
 
J'ai une camera qui transmet en 1gb et un automate qui transmet en 100mb
 
J'ai un switch SG 200-18 qui avec le principe de l'auto-négociation réglé en auto est censé adapté la vitesse de ses ports, et donc je devrais avoir un port en 1gb et un autre en 100mb.
 
Ces flux doivent aller sur un PC distant.
Comme je dois parcourir une grande longueur de mètre j'ai une paire de fibre optique.
 
Pour relier la fibre optique à mon PC j'ai un convertisseur fibre optique|cuivre qui est connecté à une carte réseau intel pro 1000 donc gigabits.
 
Est-il possible de faire passer sur la fibre optique à la fois le flux de 100mb et le flux de 1000mb ?
 
Je pense que ce n'est pas possible car l'autonegociation doit se mettre d'accord sur une vitesse.
De mon point de vue, il va passer le flux de 1000 pour commencer, puis comme le switch SG ne pourras mettre en tampon tout le flux pour l'automate en 100mb, il y aura une renégociation et le flux sur la fibre optique basculera en 100mb, et du coup je perdrai ma vitesse de 1gb du flux de ma caméra, ais-je bon ?
 
Est-ce qu'il y a un moyen de pouvoir transmettre deux vitesses différentes sur un même câble ? Par exemple avec deux réseaux.
 
On m'a vendu l'idée que si je met un switch spiderII  
http://www.e-catalog.beldensolutio [...] /en/conf/0  
de chaque côté de la fibre, celui-ci est capable de transmettre deux vitesses différentes.
Sur sa fiche technique je ne vois écris que "auto-crossing, auto-negotiation, auto-polarity"
 
Donc je pense que ce n'est pas possible mais j'attend l'avis de personnes plus compétente.
 
Merci
 

qui peut le plus peut le moins .. pas de souci à te faire, tu peux brancher des équipements en 10,100 ou 1000 sur le même switch et tout communiquera sans souci !
 
le port de ton switch où sera branché ton automate négociera en 100, le port avec la caméra en 1000 et le port vers la fibre en 1000 aussi. L'autoneg fonctionne entre 2 équipements, elle ne nivelle pas par le bas

Bonjour,

Tu te représentes très mal la manière dont fonctionne un réseau ethernet. Sur chaque port du switch, la vitesse est négociée indépendamment et cette vitesse n'a de signification que pour les deux machines connectées à chaque bout du câble.
Au niveau au dessus (niveau 2 du modèle OSI si tu veux faire des recherches) on est en mode commutation de paquets, il n'est plus question de débits mais seulement de petits paquets de données qui arrivent (du point de vue du switch) plus ou moins régulièrement sur un port pour aller sur un autre port.
Il n'y a pas de circuit déterminé à l'avance : un paquet arrivant sur le port X peut aller sur le port Y, et le paquet suivant arrivant sur le port X aller sur le port Z. Le switch décide pour chaque paquet où l'envoyer. Il ne sait absolument pas si d'un côté il y a une caméra qui va ne faire qu'envoyer des paquets et toujours dans la même direction, de l'autre un PC qui va ne faire qu'en recevoir (ce qui ne sera de toute façon pas vrai mais je schématise), etc. Tout ce qu'il sait c'est qu'il a des ports sur lesquels arrivent des paquets qu'il doit aiguiller au cas par cas.
Ces ports sont limités à 100Mb/s ou 1Gb/s mais ce n'est qu'une limite haute, rien n'interdit qu'ils ne soient utilisés qu'à moitié ou même qu'il ne passe dessus d'un paquet toutes les 10 minutes. Tant qu'on n'atteint pas la limite on peut faire passer dedans le trafic de plein de machines différentes en même temps sans problème (puisque chaque paquet est traité indépendamment des autres).

Donc la question à te poser est : quel est la somme des débits nécessaires pour ta caméra et ton automate ? ils n'utilisent probablement pas à fond leur port ethernet et si le lien entre ton switch et ton PC est effectivement en gigabit, ça suffira probablement. A toi de te renseigner sur le besoin.

Merci de ta réponse mais je suis sceptique par rapport à la situation :
L'autoneg fonctionne entre deux équipements, sur la fibre il y a du 1000, le switch va recevoir 1000mb/s et ne peux en envoyer que 100 de l'autre côté, ne va t'il pas devoir faire un cache ? ça me parait techniquement impossible sauf si sur la fibre les données sont envoyé à la fois en 1000 et en 100, mais pourtant l'autoneg va en choisir qu'un.
 
fibre 10000------switch------automat 100méga

Merci pour ta réponse.
Si on parle en paquet pour moi ca revient au meme, imaginons que la fibre optique fait passer à une vitesse de 1000mbs des paquets, le switch reçoit un paquet à une vitesse de 1000mb/s et l'envoi à l'automate à une vitesse de 100mb/s, au bout de 10000000 paquets envoyés, il y a forcément un engorgement dans le switch ca me parait logique. Donc le switch créé un buffer, et ma question c'est est ce que une fois le buffer est trop grand, est ce que les paquets sont simplement supprimés ou alors est ce que cela peut jouer sur l'autonegociation du débit sur la fibre

Ton raisonnement se tient, si effectivement tes interfaces sont toutes utilisées à fond ça ne va pas marcher, en effet on ne peut pas faire passer 1100Mb/s dans un tuyau de 1000Mb/s.
Maintenant vérifie, il y a de très grandes chances que tu aies en fait besoin de beaucoup moins que ça, et que ça passe sans souci dans ta fibre 1Gb/s.

Merci pour ton message j'ai compris ce point là et je ne pense pas du tout surcharger un tuyau de 1000mb/s.
 
Je reste cependant toujours ignorant pour la suppression des trames dans le switchs,  j'ai besoin d'explication technique :
 
Le switch reçoit des trames
il les stock dans un buffer jusqu'à qu'il puisse vérifier le checksum des trames
si c'est ok il les place dans le buffer d'un port en sortie
le buffer en sortie sort les trames à une vitesse de 100mb/s (cable fast ethernet lié à l'automate).  
 
Le switch reçoit des trames à une vitesse de 1gb/s, son buffer va grossir avant l'envoi sur le port de sortie, et le port de sortie est limité à 100mb/s, comment fait-il quand le buffer grossi ?
 
Il supprime les nouvelle trames à destinations de l'automate ? (solution raisonnable car ça ne bride pas le reste)
Il supprime toutes les trames venant du port de la fibre le temps de décharger son buffer central ?
Autre ?
 
Merci
 

Je ne pense pas qu'il faille prendre le problème comme ca.
Ton switch ne va pas réserver un buffer pour toutes les trames qui arrivent.
il ne fait pas une sorte de tampon de toutes les trames qui arrivent et qui seraient en attente du destinataire.
 
Quand une trame arrive, il l'envoie vers le destinataire.
Le destinataire dit qu'il peut envoyer la suivante et ainsi de suite.
S'il peut fonctionner à la vitesse maxi il le fait, sinon il se base sur la vitesse la plus lente.

Je pense que le switch fait la plupars du temps un buffer pour chaque trame (il existe l'autre méthode ou il envoi directement la trame morcelée, mais cela signifie que les erreurs sont vu à l'arrivé ce qui peut encombrer le flux pour rien, mais les carte réseau ne l'accepte pas).
Et dans mon cas mes trames sont des jumbo trames donc j'avais un peu peur mais...
 
Mais tu as tout a fait raison pour les acknowledge et je te remercie de m'avoir fait chercher de nouveau dans cette direction !
 
J'y ai pensé tout à l'heure qu'avant d'envoyer d'autre trame je pouvais recevoir un acknowledge ethernet sur le port 100mb et donc que je ne peux pas aller plus vite que le port 100 mb mais je ne trouvais pas l'information d'accusé de réception sur le protocole ethernet !
 
Et là je suis tombé sur ce super lien https://books.google.fr/books?id=CC [...] cu&f=false
 
 
On voit bien le fonctionnement rassurant de l’acquittement :
une trame est envoyée, elle attend une réponse, et seulement suivant le temps de réponse elle se permet d'envoyer une fenêtre d'anticipation de trame, c'est dynamique, c'est cool, j'ai l'explication technique qui me permet de comprendre pourquoi il n'y a pas de risque pour le switch d'avoir son buffer surchargé
 
Merci pour votre aide

Si ton automate est branché en 100Mb/s et que tu essayes de lui envoyer plus de 100Mb/s (que ce soit depuis un port 1Gb/s ou plusieurs liens 100Mb/s bien chargés), oui des trames à destination de l'automate seront détruites par le switch.
Mais bon là c'est pareil, j'imagine qu'en réalité tu vas envoyer bien moins que 100Mb/s à ton automate donc pas de problème.

non, stop ! il n'y a pas du tout de mécanisme d'acknowledge en ethernet, ni de fenêtres temporelles ou de mécanisme de contrôle de flux. Ton lien ne parle pas d'ethernet (plutôt de quelque chose qui ressemble à TCP).

Un switch peut tout à fait avoir un buffer surchargé et dropper des paquets à cause de cela.

Ah je me suis donc emporté trop vite.
En fait ce mécanisme d'acknowledge est relatif au controle d'erreur ARQ qu'on retrouve dans le controle de liaison logique LLC qui est pas dans ethernet...
j'ai trop vite fait le lien.. le LLC est dans les réseaux sans-fil mais pas dans les protocoles LAN comme Ethernet
l'explication : "comme les erreurs de bit sont rares sur des fils courts. Dans ce dernier cas, seules la détection d'erreur et l'annulation de paquets erronés sont fournies."
 
Donc quand le buffer est plein, le switch ne peut même plus recevoir de trame complète donc il envoi un bourrage d'erreur lié à cette trame sur le port 1gb/s pour que la trame soit renvoyée ?
Parce qu'il faut bien que ma carte réseau sache qu'il faut renvoyer la trame..
Du coup cela peut polluer le flux d'1Gb tous ces bits de bourrages, heureusement qu'il y a du full duplex.
 
J'ai bien compris que le problème serait seulement si sur ma fibre optique j'envoi à une vitesse de 1100mb/s mais j'ai pas encore les mesures, et il faut savoir que j'enregistre de la vidéo HD.
 
Merci
 
 
 

 
non il ne droppe le paquet et n'envoie rien du tout, le but d'ethernet n'est pas d'assurer la fiabilité du transfert. La carte réseau n'a pas besoin de savoir s'il faut renvoyer la trame, ce genre de question est gérée plus haut, dans l'OS, au niveau de TCP (ou au niveau applicatif si l'application utilise UDP).

Merci pour ton réponse, cela s'éclaircit. Je comprend mieux pourquoi le surcharge ne se fait que si les tuyaux sont pleins.
 
Est-ce que cela se fait de calculer le poids des données transmis en udp avant d'obtenir un ack par l'application pour calculer combien il faut de jumbo frames (9K) avant d'avoir un ack udp ?

ya pas de ack en udp. C'est à l'appli au dessus de s'assurer si elle en a besoin de la retransmission.

La gestion des contentions se fait plus haut :  
TCP gère le contrôle de flux et mettra "en attente" lors d'une contention, ou rejouera les paquets qui n'auront pas été acknowledgés.
UDP par contre envoie tant qu'il peut. S'il manque des paquets, c'est à la couche supérieure de gérer.

Oui c'est pourquoi j'ai précisé un ack transmis par l'application (sous entendu la couche supérieur)
Je me demandai si je pouvais calculer le nombre de jumbo trame transmis avant d'avoir un accusé de réception de l'application, et donc je pense que non car le nombre de trames va dépendre des erreurs transmises sur la couche 2 et pas seulement des données transmise en couche application