A voir également:
- Calcul débit LS
- Calcul moyenne excel - Guide
- Logiciel calcul plancher bois gratuit - Télécharger - Architecture & Déco
- Formule de calcul excel - Guide
- Logiciel gratuit calcul surface m2 - Télécharger - Outils professionnels
- Logiciel gratuit calcul valeur nutritionnelle - Télécharger - Santé & Bien-être
6 réponses
ianvs
Messages postés
539
Date d'inscription
mardi 26 juin 2007
Statut
Membre
Dernière intervention
29 avril 2009
209
26 oct. 2007 à 20:44
26 oct. 2007 à 20:44
Bonjour,
J'en déduit qu'il y a d'autres éléments que tes postes TSE ... qui utilisent du RDP à 90% normalement.
Combien y a-t-il de PC ?
J'en déduit qu'il y a d'autres éléments que tes postes TSE ... qui utilisent du RDP à 90% normalement.
Combien y a-t-il de PC ?
ianvs
Messages postés
539
Date d'inscription
mardi 26 juin 2007
Statut
Membre
Dernière intervention
29 avril 2009
209
27 oct. 2007 à 13:04
27 oct. 2007 à 13:04
Bonjour,
Alors le calcul est assez simple : débit requis pour un poste TES x 35 + 20% de marge (les flux auquels on n'a pas pensé avant et les extensions. Si beaucou d'extensions sont prévues tu peux doubler ...
Donc 15 kbps x 35 +20% = 525 kbps + 20% => 630 kbps (soit 650 kbps pour arrondir)
J'ai pris 15kbps par session TSE (RDP) mais c'est à valider ...
Bye bye
Alors le calcul est assez simple : débit requis pour un poste TES x 35 + 20% de marge (les flux auquels on n'a pas pensé avant et les extensions. Si beaucou d'extensions sont prévues tu peux doubler ...
Donc 15 kbps x 35 +20% = 525 kbps + 20% => 630 kbps (soit 650 kbps pour arrondir)
J'ai pris 15kbps par session TSE (RDP) mais c'est à valider ...
Bye bye
Thanks janvs, enfin quelqu'un qui répond correctement à ma question !! LOL
Allé ++ et bonne journée.
Allé ++ et bonne journée.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
brupala
Messages postés
109497
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
3 mai 2024
13 627
29 oct. 2007 à 20:26
29 oct. 2007 à 20:26
bof,
le calcul ne peut pas être linéaire avec le nombre de postes .
l'occupation de la bande passante est loin d' etre proportionnelle au nombre de postes.
"sans que ça rame" : ça ne veut rien dire : ça ramera toujours de trop , pour plein de diverses raisons .
les applications à part le streaming occupent rarement un débit fixe constant .
Dans ces conditions définir le débit d'une liaison relève de l'expérimentation plus que du calcul et le meilleur résultat est toujours le compromis inférieur entre budget et patience des utilisateurs .
en mettant toutefois en place une QOS qui privilégie les applications interactives (RDP) sur les transferts de fichiers en fond (pop, smtp, ftp et http) .
ceci dit 10 à 15 Kbit/s par utilisateur sont une bonne base de départ , si ce flux est prioritaire , pour arriver à 5Kbit/s/poste pour une vingtaine .
attention aussi, pour une bonne QOS , une minorité des fluxs doivent être prioritaires , donc une 512 K serait un bon départ .
le calcul ne peut pas être linéaire avec le nombre de postes .
l'occupation de la bande passante est loin d' etre proportionnelle au nombre de postes.
"sans que ça rame" : ça ne veut rien dire : ça ramera toujours de trop , pour plein de diverses raisons .
les applications à part le streaming occupent rarement un débit fixe constant .
Dans ces conditions définir le débit d'une liaison relève de l'expérimentation plus que du calcul et le meilleur résultat est toujours le compromis inférieur entre budget et patience des utilisateurs .
en mettant toutefois en place une QOS qui privilégie les applications interactives (RDP) sur les transferts de fichiers en fond (pop, smtp, ftp et http) .
ceci dit 10 à 15 Kbit/s par utilisateur sont une bonne base de départ , si ce flux est prioritaire , pour arriver à 5Kbit/s/poste pour une vingtaine .
attention aussi, pour une bonne QOS , une minorité des fluxs doivent être prioritaires , donc une 512 K serait un bon départ .
ianvs
Messages postés
539
Date d'inscription
mardi 26 juin 2007
Statut
Membre
Dernière intervention
29 avril 2009
209
30 oct. 2007 à 13:53
30 oct. 2007 à 13:53
Bonjour,
Je suis d'accord avec toi sur le raisonnement, mais dans la question (j'avais fait préciser) il ne doit y avoir sur place QUE des terminaux TSE (d'où mon calcul) car (sauf erreur) ces terminaux ouvrent des sessions TSE/RDP et tous les flux ultérieurs sont initié par le serveur TSE (comme Citrix).
De fait, la QoS me semble difficile puisqu'il n'y a que des sessions RDP qui circulent, à moins de mettre des boîtiers de compressions / QoS.
Je suis d'accord avec toi sur le raisonnement, mais dans la question (j'avais fait préciser) il ne doit y avoir sur place QUE des terminaux TSE (d'où mon calcul) car (sauf erreur) ces terminaux ouvrent des sessions TSE/RDP et tous les flux ultérieurs sont initié par le serveur TSE (comme Citrix).
De fait, la QoS me semble difficile puisqu'il n'y a que des sessions RDP qui circulent, à moins de mettre des boîtiers de compressions / QoS.
brupala
Messages postés
109497
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
3 mai 2024
13 627
>
ianvs
Messages postés
539
Date d'inscription
mardi 26 juin 2007
Statut
Membre
Dernière intervention
29 avril 2009
30 oct. 2007 à 15:51
30 oct. 2007 à 15:51
effectivement,
par contre,
la compression, si elle est efficace pour du transfert de fichiers, est plutôt un handicap pour du dialogue interactif (temps de latence dû à la compression /decompression ) et n'est donc vraiment efficace que sur des liaisons bas débit où le temps de transmission est long par rapport au temps de compression/decompression.
par contre,
la compression, si elle est efficace pour du transfert de fichiers, est plutôt un handicap pour du dialogue interactif (temps de latence dû à la compression /decompression ) et n'est donc vraiment efficace que sur des liaisons bas débit où le temps de transmission est long par rapport au temps de compression/decompression.
