J'ai dit où le contraire ?
En disant que calculer en terme de payload est débile, ce qui équivaut à dire que calculer en terme d'overhead n'a aucun sens non plus.
Ensuite je suis d'accord sur certains de tes arguments, mais tu ne les avais pas du tout développé dans ton premier commentaire.
Peut être aurait il fallu commencer par là plutôt que jouer les oracles insultants, non ? (oui débile n'est pas un mot particulièrement gentil).
- foireux: à la base on suppose que les gens parlant de "débit théorique" voulait parler de "débit offert à la couche applicative" mais pas de "débit offert à la couche Ethernet"
Je vois pas en quoi c'est foireux, vu que c'est bien souvent le cas.
- inutile: par ce qu'après tout ca on à 4.8% d'écart sur une unité pifométrique et non définie
Elle est pas définie, normal vu que c'est une division de deux valeurs de même grandeur (et ca sera pas la seule valeur ayant une unité non définie en science).
Pifométrique non.
Ne prenant pas en compte tout, je suis d'accord (voir ton "mauvais") mais à part ça ...
- mauvais: par ce qu'on suppose du TCP/IP mais on oubli des petits truc comme des ACK et ce que ca engendre sur les 3 couches alors qu'on calcul à l'octet près l'overhead
Si la fenêtre de tcp est suffisament grande, tu n'as pas besoin de prendre en compte le ACK.
Si tu travaille en fulle duplex, même chose tu t'en fous du ack.
Si tu demandes aux gens d'être ultra précis, soit le toi aussi.
- approximatif : par ce qu'on suppose qu'un header TCP en 2010 fait 20 octets, qu'il y a pas de VLAN, qu'il y a pas de tunnel et des milliers d'autres trucs.
Clair que sur un PAN y'a toujours des vlan et qu'on fait du OpenVPN sur PPoE sur MPLS sur IP ...
Tout ca pour conclure sur quelque chose que tout le monde sait. Et ben non tout le monde ne le sait pas forcément.
[^] # Re: ...
Posté par briaeros007 . En réponse au journal De la capacité d'un lien Ethernet. Évalué à 5.
En disant que calculer en terme de payload est débile, ce qui équivaut à dire que calculer en terme d'overhead n'a aucun sens non plus.
Ensuite je suis d'accord sur certains de tes arguments, mais tu ne les avais pas du tout développé dans ton premier commentaire.
Peut être aurait il fallu commencer par là plutôt que jouer les oracles insultants, non ? (oui débile n'est pas un mot particulièrement gentil).
- foireux: à la base on suppose que les gens parlant de "débit théorique" voulait parler de "débit offert à la couche applicative" mais pas de "débit offert à la couche Ethernet"
Je vois pas en quoi c'est foireux, vu que c'est bien souvent le cas.
- inutile: par ce qu'après tout ca on à 4.8% d'écart sur une unité pifométrique et non définie
Elle est pas définie, normal vu que c'est une division de deux valeurs de même grandeur (et ca sera pas la seule valeur ayant une unité non définie en science).
Pifométrique non.
Ne prenant pas en compte tout, je suis d'accord (voir ton "mauvais") mais à part ça ...
- mauvais: par ce qu'on suppose du TCP/IP mais on oubli des petits truc comme des ACK et ce que ca engendre sur les 3 couches alors qu'on calcul à l'octet près l'overhead
Si la fenêtre de tcp est suffisament grande, tu n'as pas besoin de prendre en compte le ACK.
Si tu travaille en fulle duplex, même chose tu t'en fous du ack.
Si tu demandes aux gens d'être ultra précis, soit le toi aussi.
- approximatif : par ce qu'on suppose qu'un header TCP en 2010 fait 20 octets, qu'il y a pas de VLAN, qu'il y a pas de tunnel et des milliers d'autres trucs.
Clair que sur un PAN y'a toujours des vlan et qu'on fait du OpenVPN sur PPoE sur MPLS sur IP ...
Tout ca pour conclure sur quelque chose que tout le monde sait. Et ben non tout le monde ne le sait pas forcément.
bref un peu de tolérance que diable.