Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère
jamais exactement un mégabit de données à la seconde, parce que l'on
doit soustraire à ce chiffre :
1)- le temps de silence entre les trames,
2)- le volume des entêtes pour chaque paquet,
3)- le trafic icmp nécessaire au contrôle de la liaison,
4)- Éventuellement, les erreurs CRC,
...
Y a-t-il des règles pour calculer le volume de chacun de ces
paramètres à soustraire ?
Y en a-t-il que j'oublie ici ?
En bref, comment calcule-t-on le débit réellement utilisable à partir
du débit annoncé au départ ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Yttrium
"Guillaume" a écrit dans le message de news: 42c26151$0$26267$
Bonjour,
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère jamais exactement un mégabit de données à la seconde, parce que l'on doit soustraire à ce chiffre : 1)- le temps de silence entre les trames, 2)- le volume des entêtes pour chaque paquet, 3)- le trafic icmp nécessaire au contrôle de la liaison, 4)- Éventuellement, les erreurs CRC, ...
Y a-t-il des règles pour calculer le volume de chacun de ces paramètres à soustraire ? Y en a-t-il que j'oublie ici ? En bref, comment calcule-t-on le débit réellement utilisable à partir du débit annoncé au départ ?
Bonjour, L'idéal est par exemple de faire un test en transférant le contenu d'un DVD (un seul trés gros fichier), puis le contenu d'un disque dur avec de multiples petits fichiers. Tu chronomètres, et tu fais une moyenne. Salutations.
"Guillaume" <guillaume.en.@.marre.du.spam> a écrit dans le message de news:
42c26151$0$26267$626a14ce@news.free.fr...
Bonjour,
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère
jamais exactement un mégabit de données à la seconde, parce que l'on
doit soustraire à ce chiffre :
1)- le temps de silence entre les trames,
2)- le volume des entêtes pour chaque paquet,
3)- le trafic icmp nécessaire au contrôle de la liaison,
4)- Éventuellement, les erreurs CRC,
...
Y a-t-il des règles pour calculer le volume de chacun de ces
paramètres à soustraire ?
Y en a-t-il que j'oublie ici ?
En bref, comment calcule-t-on le débit réellement utilisable à partir
du débit annoncé au départ ?
Bonjour,
L'idéal est par exemple de faire un test en transférant le contenu d'un DVD
(un seul trés gros fichier), puis le contenu d'un disque dur avec de
multiples petits fichiers.
Tu chronomètres, et tu fais une moyenne.
Salutations.
"Guillaume" a écrit dans le message de news: 42c26151$0$26267$
Bonjour,
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère jamais exactement un mégabit de données à la seconde, parce que l'on doit soustraire à ce chiffre : 1)- le temps de silence entre les trames, 2)- le volume des entêtes pour chaque paquet, 3)- le trafic icmp nécessaire au contrôle de la liaison, 4)- Éventuellement, les erreurs CRC, ...
Y a-t-il des règles pour calculer le volume de chacun de ces paramètres à soustraire ? Y en a-t-il que j'oublie ici ? En bref, comment calcule-t-on le débit réellement utilisable à partir du débit annoncé au départ ?
Bonjour, L'idéal est par exemple de faire un test en transférant le contenu d'un DVD (un seul trés gros fichier), puis le contenu d'un disque dur avec de multiples petits fichiers. Tu chronomètres, et tu fais une moyenne. Salutations.
Dominique Blas
Bonjour,
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère jamais exactement un mégabit de données à la seconde,
Si ! En utilisant un générateur de données on transfère bien 1Mbit/s dans les 2 sens à la fois. Du reste, on n'a pas le choix : le train d'horloge est à la fréquence correspondante à la modulation employée.
Lorqu'on utilise en sus des protocoles divers et variés (et donc différents niveaux d'encapsulation) les données véhiculées le sont toujours à 1Mbits/s (il ne saurait en être autrement) mais si l'on utilise celles-ci pour effectuer des mesures, c'est une erreur, bien évidemment. Car, dans ce cas, on n'appréciera pas le débit réel.
db
--
Courriel : usenet blas net
Bonjour,
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère
jamais exactement un mégabit de données à la seconde,
Si !
En utilisant un générateur de données on transfère bien 1Mbit/s dans les
2 sens à la fois. Du reste, on n'a pas le choix : le train d'horloge est
à la fréquence correspondante à la modulation employée.
Lorqu'on utilise en sus des protocoles divers et variés (et donc
différents niveaux d'encapsulation) les données véhiculées le sont
toujours à 1Mbits/s (il ne saurait en être autrement) mais si l'on
utilise celles-ci pour effectuer des mesures, c'est une erreur, bien
évidemment.
Car, dans ce cas, on n'appréciera pas le débit réel.
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère jamais exactement un mégabit de données à la seconde,
Si ! En utilisant un générateur de données on transfère bien 1Mbit/s dans les 2 sens à la fois. Du reste, on n'a pas le choix : le train d'horloge est à la fréquence correspondante à la modulation employée.
Lorqu'on utilise en sus des protocoles divers et variés (et donc différents niveaux d'encapsulation) les données véhiculées le sont toujours à 1Mbits/s (il ne saurait en être autrement) mais si l'on utilise celles-ci pour effectuer des mesures, c'est une erreur, bien évidemment. Car, dans ce cas, on n'appréciera pas le débit réel.
db
--
Courriel : usenet blas net
Guillaume
Dominique Blas a wroté :
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère jamais exactement un mégabit de données à la seconde,
Si ! En utilisant un générateur de données on transfère bien 1Mbit/s dans les 2 sens à la fois. Du reste, on n'a pas le choix : le train d'horloge est à la fréquence correspondante à la modulation employée.
Lorqu'on utilise en sus des protocoles divers et variés (et donc différents niveaux d'encapsulation) les données véhiculées le sont toujours à 1Mbits/s (il ne saurait en être autrement) mais si l'on utilise celles-ci pour effectuer des mesures, c'est une erreur, bien évidemment. Car, dans ce cas, on n'appréciera pas le débit réel.
OK. Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
Merci pour votre réponse,
-- Guillaume
Dominique Blas a wroté :
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère
jamais exactement un mégabit de données à la seconde,
Si !
En utilisant un générateur de données on transfère bien 1Mbit/s dans les
2 sens à la fois. Du reste, on n'a pas le choix : le train d'horloge est
à la fréquence correspondante à la modulation employée.
Lorqu'on utilise en sus des protocoles divers et variés (et donc
différents niveaux d'encapsulation) les données véhiculées le sont
toujours à 1Mbits/s (il ne saurait en être autrement) mais si l'on
utilise celles-ci pour effectuer des mesures, c'est une erreur, bien
évidemment.
Car, dans ce cas, on n'appréciera pas le débit réel.
OK.
Cependant ma problématique demeure : comment puis-je apprécier *en*
*TCP/IP* (donc après un premier niveau d'encapsulation) mon débit
utile réel ?
Sur une liaison donnée, disons à 1 Mbit / seconde, on ne transfère jamais exactement un mégabit de données à la seconde,
Si ! En utilisant un générateur de données on transfère bien 1Mbit/s dans les 2 sens à la fois. Du reste, on n'a pas le choix : le train d'horloge est à la fréquence correspondante à la modulation employée.
Lorqu'on utilise en sus des protocoles divers et variés (et donc différents niveaux d'encapsulation) les données véhiculées le sont toujours à 1Mbits/s (il ne saurait en être autrement) mais si l'on utilise celles-ci pour effectuer des mesures, c'est une erreur, bien évidemment. Car, dans ce cas, on n'appréciera pas le débit réel.
OK. Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
Merci pour votre réponse,
-- Guillaume
Olivier Masson
OK. Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
Merci pour votre réponse,
La réponse de Dominique est la seule qui est valable. Sinon tout dépend de quoi tu parles ; il faut utiliser des termes très précis en réseaux. Déjà tu parles de TCP/IP comme un premier niveau d'encapsulation, mais il s'agit déjà là respectivement de la couche transport et réseau (dans le modèle OSI). Ce que rajoute TCP puis IP, c'est bien beau, mais ça te sert à quoi ? Il y a des couches au-dessus (surtout application) et en-dessous.
OK.
Cependant ma problématique demeure : comment puis-je apprécier *en*
*TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile
réel ?
Merci pour votre réponse,
La réponse de Dominique est la seule qui est valable.
Sinon tout dépend de quoi tu parles ; il faut utiliser des termes très
précis en réseaux.
Déjà tu parles de TCP/IP comme un premier niveau d'encapsulation, mais
il s'agit déjà là respectivement de la couche transport et réseau (dans
le modèle OSI).
Ce que rajoute TCP puis IP, c'est bien beau, mais ça te sert à quoi ? Il
y a des couches au-dessus (surtout application) et en-dessous.
OK. Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
Merci pour votre réponse,
La réponse de Dominique est la seule qui est valable. Sinon tout dépend de quoi tu parles ; il faut utiliser des termes très précis en réseaux. Déjà tu parles de TCP/IP comme un premier niveau d'encapsulation, mais il s'agit déjà là respectivement de la couche transport et réseau (dans le modèle OSI). Ce que rajoute TCP puis IP, c'est bien beau, mais ça te sert à quoi ? Il y a des couches au-dessus (surtout application) et en-dessous.
jdx
Bnsr,
par exemple une reponse : NetPerf http://www.netperf.org/netperf/training/Netperf.html (en complétant avec Ethereal pour verifier la trame effectivement transmise) car il y a parfois un piege : la trame transmie peut etre completee avec des octets de bourrage... Tester plutot avec UDP_STREAM
PS marche sous Linux et Windows (en cherchant un peu... puddy_netserver.exe )
Bnsr,
par exemple une reponse : NetPerf
http://www.netperf.org/netperf/training/Netperf.html
(en complétant avec Ethereal pour verifier la trame effectivement
transmise)
car il y a parfois un piege :
la trame transmie peut etre completee avec des octets de bourrage...
Tester plutot avec UDP_STREAM
PS marche sous Linux et Windows (en cherchant un peu...
puddy_netserver.exe )
par exemple une reponse : NetPerf http://www.netperf.org/netperf/training/Netperf.html (en complétant avec Ethereal pour verifier la trame effectivement transmise) car il y a parfois un piege : la trame transmie peut etre completee avec des octets de bourrage... Tester plutot avec UDP_STREAM
PS marche sous Linux et Windows (en cherchant un peu... puddy_netserver.exe )
jdx
Une unité souvent utilisée en réseau le pps (voire Kpps) Paquet(s) par seconde... mais (cf.Olivier & Dominique) quels paquets....quelle longueur..... JDX
Une unité souvent utilisée en réseau le pps (voire Kpps)
Paquet(s) par seconde...
mais (cf.Olivier & Dominique) quels paquets....quelle longueur.....
JDX
Une unité souvent utilisée en réseau le pps (voire Kpps) Paquet(s) par seconde... mais (cf.Olivier & Dominique) quels paquets....quelle longueur..... JDX
Dominique Blas
[...]
OK. Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
On applique des ratios fonction des protocoles utilisés. C'est approximatif mais l'erreur est réduite (inférieure à 5% si l'on tient vraiment compte de tout, que l'on s'assure de remplir les trames de niveau 2 au maximum et qu'on n'a pas une couche 2 trop bavarde ou trop hachée [comme l'ATM]).
Ainsi lorsque sur une liaison (possédant une méthode d'accès sans contention d'accès), vendue pour 1Mbit/s on trouve, approximativement, 970 kbits/s on se dit qu'il est effectivement probable (à 5%) que la liaison soit de 1Mbits/s. Et, en tant qu'utilisateur, on s'en contente en général. Ce qui ne sera pas le cas du personnel technique d'un opérateur.
Pour être clair, en effectuant un transfert de gros fichier sous FTP et sur une liaison (sans contention) à 1Mbit/s il y a de fortes chances que l'on trouve un débit global (vu par le logiciel) de 970-980 kbit/s. En considérant que les entêtes cumulés IP et TCP et la gestion interviennent pour 3% et que l'entête et la gestion de la couche 2 interviennent pour 1% on se dit qu'on a une liaison d'un débit nominal de 1 à 1,1 Mbit/s.
Si on ne trouvait que 700 kbit/s pour une liaison vendue de 1Mbit/s on pourrait et devrait râler mais si on ne trouvait que 950 kbit/s difficile de prétendre à quoi que ce soit sans mesure plus précise.
db
--
Courriel : usenet blas net
[...]
OK.
Cependant ma problématique demeure : comment puis-je apprécier *en*
*TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile
réel ?
On applique des ratios fonction des protocoles utilisés.
C'est approximatif mais l'erreur est réduite (inférieure à 5% si l'on
tient vraiment compte de tout, que l'on s'assure de remplir les trames
de niveau 2 au maximum et qu'on n'a pas une couche 2 trop bavarde ou
trop hachée [comme l'ATM]).
Ainsi lorsque sur une liaison (possédant une méthode d'accès sans
contention d'accès), vendue pour 1Mbit/s on trouve, approximativement,
970 kbits/s on se dit qu'il est effectivement probable (à 5%) que la
liaison soit de 1Mbits/s. Et, en tant qu'utilisateur, on s'en contente
en général.
Ce qui ne sera pas le cas du personnel technique d'un opérateur.
Pour être clair, en effectuant un transfert de gros fichier sous FTP et
sur une liaison (sans contention) à 1Mbit/s il y a de fortes chances que
l'on trouve un débit global (vu par le logiciel) de 970-980 kbit/s.
En considérant que les entêtes cumulés IP et TCP et la gestion
interviennent pour 3% et que l'entête et la gestion de la couche 2
interviennent pour 1% on se dit qu'on a une liaison d'un débit nominal
de 1 à 1,1 Mbit/s.
Si on ne trouvait que 700 kbit/s pour une liaison vendue de 1Mbit/s on
pourrait et devrait râler mais si on ne trouvait que 950 kbit/s
difficile de prétendre à quoi que ce soit sans mesure plus précise.
OK. Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
On applique des ratios fonction des protocoles utilisés. C'est approximatif mais l'erreur est réduite (inférieure à 5% si l'on tient vraiment compte de tout, que l'on s'assure de remplir les trames de niveau 2 au maximum et qu'on n'a pas une couche 2 trop bavarde ou trop hachée [comme l'ATM]).
Ainsi lorsque sur une liaison (possédant une méthode d'accès sans contention d'accès), vendue pour 1Mbit/s on trouve, approximativement, 970 kbits/s on se dit qu'il est effectivement probable (à 5%) que la liaison soit de 1Mbits/s. Et, en tant qu'utilisateur, on s'en contente en général. Ce qui ne sera pas le cas du personnel technique d'un opérateur.
Pour être clair, en effectuant un transfert de gros fichier sous FTP et sur une liaison (sans contention) à 1Mbit/s il y a de fortes chances que l'on trouve un débit global (vu par le logiciel) de 970-980 kbit/s. En considérant que les entêtes cumulés IP et TCP et la gestion interviennent pour 3% et que l'entête et la gestion de la couche 2 interviennent pour 1% on se dit qu'on a une liaison d'un débit nominal de 1 à 1,1 Mbit/s.
Si on ne trouvait que 700 kbit/s pour une liaison vendue de 1Mbit/s on pourrait et devrait râler mais si on ne trouvait que 950 kbit/s difficile de prétendre à quoi que ce soit sans mesure plus précise.
db
--
Courriel : usenet blas net
Guillaume
Olivier Masson a wroté :
Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
La réponse de Dominique est la seule qui est valable.
Ben oui, je suis prêt à l'admettre, mais ici en exploitation, il faut bien que je m'appuie sur un protocole avant même d'avoir des infos pertinentes sur la charge de mes liens...en l'occurence TCP/IP (voilà pourquoi je poste ici, et pas sur fcr.supervision).
Sinon tout dépend de quoi tu parles ; il faut utiliser des termes très précis en réseaux.
Soit. Je vais donc préciser ma problématique. Je me trouve sur le noeud central d'un réseau en étoile, dont les informations en termes de débit me parviennent des différents routeurs via snmp (donc je suis déjà en TCP/IP).
La qualité de service n'est pas mise en oeuvre sur tous ces liens, et sur la partie de ces liens qui ne sont pas gérés en QoS, je constate -outre un trafic moyen ... "moyen", quoi ;)- des pics de débit durant lesquels le trafic s'engorge, au point que les "get" snmp ne me parviennent même plus durant ces congestions. Or, je perds la main en nsupervision autour de 80 % de charge sur mes liens. Au-delà, plus de remontées d'info via snmp. Je veux donc savoir ou sont les 20 % restants, et par conséquent si c'est une marge raisonnable à retirer du débit du débit nominal de la ligne une fois qu'on en a retiré les temps de silence, les entêtes etc. , ou si mon outil de supervision me ment, ou si France Télécon m'a carotté 20 % de débit utile (auquel cas ça va saigner).
Déjà tu parles de TCP/IP comme un premier niveau d'encapsulation, mais il s'agit déjà là respectivement de la couche transport et réseau (dans le modèle OSI). Ce que rajoute TCP puis IP, c'est bien beau, mais ça te sert à quoi > ?
Les ip accountings des routeurs de part et d'autre de ces liens me donnent la source et la destination des trafics responsables de ces engorgements. Donc en IP, je vais pouvoir qualifier à quelles machines s'adressera ma QoS. Ensuite, la nature des échanges et des applis sur ces machines va me permettre de gérer la priorité de mes flux en TCP/UDP. Pour bien dimensionner tout ça, je dois cependant prendre en compte tout le débit disponible, et même considérer aussi le volume utilisé pour contrôler ce débit (mes remontées snmp).
Il y a des couches au-dessus (surtout application) et en-dessous.
Certes, mais elles ne sont plus prises en charge par les routeurs : elles ne sont plus de mon ressort :) .
-- Guillaume
Olivier Masson a wroté :
Cependant ma problématique demeure : comment puis-je apprécier *en*
*TCP/IP* (donc après un premier niveau d'encapsulation) mon débit
utile réel ?
La réponse de Dominique est la seule qui est valable.
Ben oui, je suis prêt à l'admettre, mais ici en exploitation, il faut
bien que je m'appuie sur un protocole avant même d'avoir des infos
pertinentes sur la charge de mes liens...en l'occurence TCP/IP (voilà
pourquoi je poste ici, et pas sur fcr.supervision).
Sinon tout dépend de quoi tu parles ; il faut utiliser des termes très
précis en réseaux.
Soit. Je vais donc préciser ma problématique.
Je me trouve sur le noeud central d'un réseau en étoile, dont les
informations en termes de débit me parviennent des différents routeurs
via snmp (donc je suis déjà en TCP/IP).
La qualité de service n'est pas mise en oeuvre sur tous ces liens, et
sur la partie de ces liens qui ne sont pas gérés en QoS, je constate
-outre un trafic moyen ... "moyen", quoi ;)- des pics de débit durant
lesquels le trafic s'engorge, au point que les "get" snmp ne me
parviennent même plus durant ces congestions. Or, je perds la main en
nsupervision autour de 80 % de charge sur mes liens. Au-delà, plus de
remontées d'info via snmp. Je veux donc savoir ou sont les 20 %
restants, et par conséquent si c'est une marge raisonnable à retirer
du débit du débit nominal de la ligne une fois qu'on en a retiré les
temps de silence, les entêtes etc. , ou si mon outil de supervision me
ment, ou si France Télécon m'a carotté 20 % de débit utile (auquel cas
ça va saigner).
Déjà tu parles de TCP/IP comme un premier niveau d'encapsulation,
mais il s'agit déjà là respectivement de la couche transport et
réseau (dans le modèle OSI).
Ce que rajoute TCP puis IP, c'est bien beau, mais ça te sert à quoi > ?
Les ip accountings des routeurs de part et d'autre de ces liens me
donnent la source et la destination des trafics responsables de ces
engorgements. Donc en IP, je vais pouvoir qualifier à quelles machines
s'adressera ma QoS. Ensuite, la nature des échanges et des applis sur
ces machines va me permettre de gérer la priorité de mes flux en
TCP/UDP. Pour bien dimensionner tout ça, je dois cependant prendre en
compte tout le débit disponible, et même considérer aussi le volume
utilisé pour contrôler ce débit (mes remontées snmp).
Il y a des couches au-dessus (surtout application) et en-dessous.
Certes, mais elles ne sont plus prises en charge par les routeurs :
elles ne sont plus de mon ressort :) .
Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
La réponse de Dominique est la seule qui est valable.
Ben oui, je suis prêt à l'admettre, mais ici en exploitation, il faut bien que je m'appuie sur un protocole avant même d'avoir des infos pertinentes sur la charge de mes liens...en l'occurence TCP/IP (voilà pourquoi je poste ici, et pas sur fcr.supervision).
Sinon tout dépend de quoi tu parles ; il faut utiliser des termes très précis en réseaux.
Soit. Je vais donc préciser ma problématique. Je me trouve sur le noeud central d'un réseau en étoile, dont les informations en termes de débit me parviennent des différents routeurs via snmp (donc je suis déjà en TCP/IP).
La qualité de service n'est pas mise en oeuvre sur tous ces liens, et sur la partie de ces liens qui ne sont pas gérés en QoS, je constate -outre un trafic moyen ... "moyen", quoi ;)- des pics de débit durant lesquels le trafic s'engorge, au point que les "get" snmp ne me parviennent même plus durant ces congestions. Or, je perds la main en nsupervision autour de 80 % de charge sur mes liens. Au-delà, plus de remontées d'info via snmp. Je veux donc savoir ou sont les 20 % restants, et par conséquent si c'est une marge raisonnable à retirer du débit du débit nominal de la ligne une fois qu'on en a retiré les temps de silence, les entêtes etc. , ou si mon outil de supervision me ment, ou si France Télécon m'a carotté 20 % de débit utile (auquel cas ça va saigner).
Déjà tu parles de TCP/IP comme un premier niveau d'encapsulation, mais il s'agit déjà là respectivement de la couche transport et réseau (dans le modèle OSI). Ce que rajoute TCP puis IP, c'est bien beau, mais ça te sert à quoi > ?
Les ip accountings des routeurs de part et d'autre de ces liens me donnent la source et la destination des trafics responsables de ces engorgements. Donc en IP, je vais pouvoir qualifier à quelles machines s'adressera ma QoS. Ensuite, la nature des échanges et des applis sur ces machines va me permettre de gérer la priorité de mes flux en TCP/UDP. Pour bien dimensionner tout ça, je dois cependant prendre en compte tout le débit disponible, et même considérer aussi le volume utilisé pour contrôler ce débit (mes remontées snmp).
Il y a des couches au-dessus (surtout application) et en-dessous.
Certes, mais elles ne sont plus prises en charge par les routeurs : elles ne sont plus de mon ressort :) .
-- Guillaume
Guillaume
Dominique Blas a wroté :
Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
[...]
En considérant que les entêtes cumulés IP et TCP et la gestion interviennent pour 3% et que l'entête et la gestion de la couche 2 interviennent pour 1% on se dit qu'on a une liaison d'un débit nominal de 1 à 1,1 Mbit/s.
Je vous remercie tous pour vos précisions, et pour vous être intéressés à ma problématique. Vos contributions vont m'aider à mieux discerner et -j'espère- à cerner puis résoudre ce qui cloche.
Si on ne trouvait que 700 kbit/s pour une liaison vendue de 1Mbit/s on pourrait et devrait râler
J'en trouve 800. Donc je vais râler :)
Merci et bon week-end.
-- Guillaume
Dominique Blas a wroté :
Cependant ma problématique demeure : comment puis-je apprécier *en*
*TCP/IP* (donc après un premier niveau d'encapsulation) mon débit
utile réel ?
[...]
En considérant que les entêtes cumulés IP et TCP et la gestion
interviennent pour 3% et que l'entête et la gestion de la couche 2
interviennent pour 1% on se dit qu'on a une liaison d'un débit nominal
de 1 à 1,1 Mbit/s.
Je vous remercie tous pour vos précisions, et pour vous être
intéressés à ma problématique. Vos contributions vont m'aider à mieux
discerner et -j'espère- à cerner puis résoudre ce qui cloche.
Si on ne trouvait que 700 kbit/s pour une liaison vendue de 1Mbit/s on
pourrait et devrait râler
Cependant ma problématique demeure : comment puis-je apprécier *en* *TCP/IP* (donc après un premier niveau d'encapsulation) mon débit utile réel ?
[...]
En considérant que les entêtes cumulés IP et TCP et la gestion interviennent pour 3% et que l'entête et la gestion de la couche 2 interviennent pour 1% on se dit qu'on a une liaison d'un débit nominal de 1 à 1,1 Mbit/s.
Je vous remercie tous pour vos précisions, et pour vous être intéressés à ma problématique. Vos contributions vont m'aider à mieux discerner et -j'espère- à cerner puis résoudre ce qui cloche.
Si on ne trouvait que 700 kbit/s pour une liaison vendue de 1Mbit/s on pourrait et devrait râler
