Auteur Sujet: Récapitulatif des problèmes EN COURS (et non résolus) (Lu 90648 fois)

Littlecasper · « **Réponse #564 le:** 28 mars 2022 à 17:28:40 »

Citation de: pju91 le 28 mars 2022 à 17:26:11

Quelle est donc cette application (à part ping) qui enchaîne des "échanges + acquittements" ?
Si elle s'appuie sur TCP, elle est très mal écrite et ne profite pas des dizaines d'années d'expérience de la mise au point du protocole TCP.
Si elle s'appuie sur UDP, elle n'a sans doute pas besoin d'ACK pour chaque échange

Quand on pilote des équipements / systèmes à distance, chaque commande / retour / visualisation est validé par un acquittement et la précision des commandes implique des échanges à intervalles très réduits. C'est pour cela que la 5G est une technologie qui va prendre le relais car elle est largement sous la milliseconde afin de permettre une totale fluidité.

Par exemple assistants de chirurgie à distance etc...

Gaille · « **Réponse #565 le:** 28 mars 2022 à 17:34:50 »

Citation de: Hugues le 28 mars 2022 à 16:48:56

Oui il y'a un souci de latence dans l'Ain chez K-Net, depuis décembre en fait
dire "Avant je pinguais le serveur speedtest de Genève en 5ms, maintenant 25" ça c'est correct.

Ce qui est mon cas, de 2 à 25 depuis longtemps maintenant.
Mais je suis navré de dire que mauvais ping ou latence (je n'arrive plus à suivre), je sus formel, tout est plus lent.
Chargement de pages, les connexions de pas mal de logiciels sur ordi ou + sur nos iBidules.
Donc, je ne sais pas qu'est ce est bien ou pas, mais je peux dire que «c'était mieux avant».

pju91 · « **Réponse #566 le:** 28 mars 2022 à 17:35:00 »

Citation de: Littlecasper le 28 mars 2022 à 17:28:40

Quand on pilote des équipements / systèmes à distance, chaque commande / retour / visualisation est validé par un acquittement et la précision des commandes implique des échanges à intervalles très réduits. C'est pour cela que la 5G est une technologie qui va prendre le relais car elle est largement sous la milliseconde afin de permettre une totale fluidité.

Par exemple assistants de chirurgie à distance etc...

Dans ce cas, au sens "strict", Internet n'est pas fait pour transporter ce type de trafic réseau
- un équipement intermédiaire peut décider de ne pas router un paquet (ex : congestion). Internet a toujours été considéré comme un réseau en "best effort delivery" et il appartient aux applications et protocoles de niveau transport d'en tenir compte
car :
- un paquet peut être "abimé" en route (d'où les checksums dans les entêtes) et dans ce cas il n'est pas pris en compte
- on ne maîtrise pas le cheminement, qui d'ailleurs peut varier d'un paquet à l'autre
- il y a de la "gigue" (jitter)
- la QOS n'est pas forcément bien implémentée de bout en bout pour favoriser ce trafic considéré comme prioritaire
etc

Dirk-Pitt · « **Réponse #567 le:** 28 mars 2022 à 17:35:12 »

Citation de: Littlecasper le 28 mars 2022 à 17:28:40

... Par exemple assistants de chirurgie à distance etc ...

Tu fais ça depuis chez toi ? Cool

Dirk-Pitt · « **Réponse #568 le:** 28 mars 2022 à 17:37:37 »

Citation de: Gaille le 28 mars 2022 à 17:34:50

... Donc, je ne sais pas qu'est ce est bien ou pas, mais je peux dire que «c'était mieux avant» ...

Je suis aussi dans le 01 et je n'ai rien remarqué

patrick_01 · « **Réponse #569 le:** 28 mars 2022 à 17:38:48 »

Citation de: Littlecasper le 28 mars 2022 à 17:28:40

Quand on pilote des équipements / systèmes à distance, chaque commande / retour / visualisation est validé par un acquittement et la précision des commandes implique des échanges à intervalles très réduits. C'est pour cela que la 5G est une technologie qui va prendre le relais car elle est largement sous la milliseconde afin de permettre une totale fluidité.

Par exemple assistants de chirurgie à distance etc...

Oui, bon exemple. Tout ce qui est contrôle de processus industriels, ou encore guidage de véhicules semi-autonomes. C'est clair, là on touche quelques applications de niche pour lesquelles la latence devient critique. Ce qui s'en approche le plus dans les utilisations grand plubic, c'est peut être le jeu en ligne.
(Remarque, le petit robot sur Mars, il se démerde pas si mal, même avec un ping un peu longuet...)

Maintenant, celui qui utilise ce genre d'applications dans le monde réel, il construit le réseau qui va avec. On parle quand même de FTTH ici, je doute que beaucoup de chirurgiens opèrent à distance depuis le bout de leur fibre K-Net.

bolemo · « **Réponse #570 le:** 28 mars 2022 à 17:39:47 »

Citation de: Littlecasper le 28 mars 2022 à 17:28:40

Quand on pilote des équipements / systèmes à distance, chaque commande / retour / visualisation est validé par un acquittement et la précision des commandes implique des échanges à intervalles très réduits. C'est pour cela que la 5G est une technologie qui va prendre le relais car elle est largement sous la milliseconde afin de permettre une totale fluidité.

Par exemple assistants de chirurgie à distance etc...

Oui enfin la 5G va gagner un peu de temps entre le téléphone et la tour, mais ensuite, c'est pareil.

Sinon, pour le pilotage, c'est donc du temps réel, et la latence ne s'accumule donc pas… On reste à un décalage de 28 ms voir un peu plus s'il y a un échange à chaque fois, mais le décalage reste constant.
S'il y a 1 000 échanges pour chaque commande envoyée, c'est un système très peu efficace…

patrick_01 · « **Réponse #571 le:** 28 mars 2022 à 17:49:21 »

Citation de: bolemo le 28 mars 2022 à 17:39:47

Oui enfin la 5G va gagner un peu de temps entre le téléphone et la tour, mais ensuite, c'est pareil.

Il y a quand même la notion de edge computing avec la 5G, ça évite des allers-retours sur le cloud pour les traitements qui ont besoin de faibles latences... enfin, ça c'est la théorie, j'attends de voir qui l'implémentera et comment.

Citation de: bolemo le 28 mars 2022 à 17:39:47

Sinon, pour le pilotage, c'est donc du temps réel, et la latence ne s'accumule donc pas… On reste à un décalage de 28 ms voir un peu plus s'il y a un échange à chaque fois, mais le décalage reste constant.
S'il y a 1 000 échanges pour chaque commande envoyée, c'est un système très peu efficace…

Une application qui a besoin d'une boucle de rétroaction rapide pourrait être pénalisée, mais encore une fois, à mon avis c'est pas des trucs qu'on pose sur la FTTH...

bolemo · « **Réponse #572 le:** 28 mars 2022 à 17:52:04 »

Citation de: patrick_01 le 28 mars 2022 à 17:49:21

Il y a quand même la notion de edge computing avec la 5G, ça évite des allers-retours sur le cloud pour les traitements qui ont besoin de faibles latences... enfin, ça c'est la théorie, j'attends de voir qui l'implémentera et comment.
Une application qui a besoin d'une boucle de rétroaction rapide pourrait être pénalisée, mais encore une fois, à mon avis c'est pas des trucs qu'on pose sur la FTTH...

Comme le gaming quoi… et un ping à 28, c'est vraiment très bien pour le gaming (même de compétition).

Steph · « **Réponse #573 le:** 28 mars 2022 à 17:58:35 »

Citation de: patrick_01 le 28 mars 2022 à 17:16:23

Moi j'ai un ping négatif, c'est pas pour autant que je passe moins de temps sur internet...

3 4 pages pour un ping de 25ms...

Quand Littlecasper va s’apercevoir qu'entre lui et son voisin chez K-net, il y a aussi 25ms parce que l'interco passe par Paris, ça va faire un choc!

Si tu avances quand je recule, comment veux-tu que je t'enc*le.

Désolé d'alimenter le flood...

bolemo · « **Réponse #574 le:** 28 mars 2022 à 18:02:07 »

Citation de: Steph le 28 mars 2022 à 17:58:35

3 4 pages pour un ping de 25ms...
Quand Littlecasper va s’apercevoir qu'entre lui et son voisin chez K-net, il y a aussi 25ms parce que l'interco passe par Paris, ça va faire un choc!

Si tu avances quand je recule, comment veux-tu que je t'enc*le.

Désolé d'alimenter le flood...

Qu'est-ce que ça serait pour un ping à 40 !!!!!

VincentO2 · « **Réponse #575 le:** 28 mars 2022 à 18:40:49 »

Citation de: Littlecasper le 28 mars 2022 à 17:12:04

J'ai essayé ces autres routes (France à Lyon, Suisse, Italie), pas vraiment d'influence par rapport à la distance

Ce n'est pas la distance à vol d'oiseau qui compte, c'est la distance parcouru par les paquets.

Citation de: Littlecasper le 28 mars 2022 à 17:16:32

Je ne suis pas d'accord, si vous avez 1000 échanges entre un client et un serveur (échange + acquittement),
2 ms de latence par échange cela fera 2 secondes de latence totale pour finaliser l'échange
28 ms de latence par échange cela fera 28 secondes de latence totale pour finaliser l'échange
Ce n'est plus négligeable...

Pour la majorité des échanges, il n'y a pas d'acquittement à chaque paquet envoyé.

En UDP, pas d'acquittement du tout au niveau L3, ça peut éventuellement être fait au niveau L7 (par l'application elle-même) comme avec QUIC.
En TCP, il y a un acquittement pour le 3 way handshake, puis régulièrement mais pas pour chaque paquet de la même connexion. Et la plupart des applications (en tout cas celles bien codées) vont réutiliser une connexion ouverte (voire en avoir plusieurs en parallèle avec un système de pools de connexions) pour plusieurs requêtes vers un même serveur.

Donc non, dans le vrai monde, ça ne prendra pas 28 secondes.