L'informatique pour les nuls :D

FonsD · 31 décembre 2009

Sérieux anonymous, je vois mal en quoi le fait d'être en 32 ou 64 bits influencerais les débits ?

La quantité de RAM adressable à la limite. [:fonsd:17]

Crapa vient nous faire un CM

1 janvier 2010

Sérieux anonymous, je vois mal en quoi le fait d'être en 32 ou 64 bits influencerais les débits ?

La quantité de RAM adressable à la limite. [:fonsd:17]

Crapa vient nous faire un CM

Ok, mais venez pas vous plaindre que c'est trop compliqué ou trop long ensuite.

Effectivement la vitesse de transfert ne peut pas être influencée par la taille des registres processeur qu'un OS est capable de gérer. Cela n'a strictement aucun rapport (ni même aucun sens). L'OS n'a pas "d'algorithme de transfert". Il a tout au plus certaines fonctionnalités de segmentation en paquet, de numérotation des paquets, de contrôle de congestion, de contrôle de flux, etc... le reste (c'est à dire les couches basses du modèle tcp) étant inclus directement dans le matériel (généralement dans le chipset de la carte réseau, c'est notamment le cas des protocoles IP/ARP/ICMP/IGMP/RARP/etc...).

Avant de me dire que la découpe en paquet nécessite une utilisation processeur et que la taille des registres peut influencer la vitesse, je précise tout de même que les vitesses processeur étant tellement énorme en regard de la vitesse d'un réseau qu'il est impossible que cela ait un impact.

Rappel de base :

Rappelons qu'une carte réseau 1000Mbps par seconde est capable de transférer 1000 millions de bits par seconde et non des octets. En terme d'octet, cela ferait donc une vitesse théorique de la carte réseau de 1000 / 8 = 125 Mégaoctets (et nous devrions utilisé des mébioctets) par seconde.

Pourquoi cette différence entre mébi et mega octets ici car les fabriquant de carte réseau exprime une vitesse de 1000 Mbps comme étant 1000 millions de bits par seconde. Hors en info , le multiple est 1024 et non 1000.

Il faut donc encore réduire le débit brut, ce qui donne un débit théorique brut de 119 Mo/s.

Vitesse de transfert

La vitesse de transfert est déterminée par plusieurs facteurs dont les deux plus importants sont le débit brut de la ligne (la bande passante) et les temps de latence.

Tout le problème pour déterminer le débit utile (c'est à dire le nombre de bit de donnée transmis par seconde) et l'efficacité d'une ligne est donc de pouvoir mesurer les temps de latence. Les temps de latence dépendent principalement du protocole utilisé et de son implémentation (mécanisme d'acquittement, contrôle d'erreur, contrôle de congestion, contrôle de flux, etc..).

Je vais essayer de détailler cela le plus simplement possible en partant du postulat d'une ligne sur laquelle on envoie des données et qui ne possèdent aucun temps de latence (elle n'a donc ni mécanisme de congestion, ni mécanisme d'acquittement, etc...) On rajoutera ces éléments par la suite.

Première hypothèse :

Un canal de transmission sans erreur de 1Mbps. On envoie en continu des paquets de 500 octets (dont 40 octets d'entête - 20 en tcp et 20 en IP).

Pour calculer l'efficacité d'une ligne on a besoin de connaitre :

le temps de transmission d'un paquet, c'est à dire le temps entre l'envoie du bit 1 du paquet et du bit N. Le temps de transmission est le rapport entre le nombre de bits transmis et le débit brut de la source.
le débit utile est calculé de la manière suivante : nombre de bit de donnée transmis / Temps de transmission.

L'efficacité de la ligne est le rapport entre le débit utile et le débit brut.

Donc partant de ce postulat, l'efficacité d'une telle ligne se calcul comme suit :

Tt (temps de transmission) = (500 x 8 (on convertit les octets transmis en bits) / 10^6 (ligne à 1Mbps) = 4000/10^6 = 4ms.

Débit utile = (460 x 8) / (4 x 10^-3 (Ce sont les 4 ms du dessus)) = 920 x 10^3 bps.

Efficacité d'une telle ligne est donc de (920 x 10^3) / 10^6 (débit brut) = 0,92 ou dit autrement, 92%.

On voit donc qu'une ligne classique à 1Mbps sans gestion d'erreur, avec des paquets de 500 octets perd 8% d'efficacité uniquement à cause des entêtes que le protocole rajoute.

Cas Berlinois

Faisons le même parallèle avec une ligne classique sous Windows. Soit un transfert de paquet égale à la taille maximum du paquet prévu par Windows (soit le MTU - Maximum Transfert Unit). Le MTU est de 1492 octets par défaut et Berlinois à une vitesse de ligne de 1000 Mbps.

Tt = (1492 x 8) / 10^9 = 11936/10^9 = 0,001194 ms.

Débit utile = (1452 x 8) / 0,001194 x 10^-3 = 11616/0,001194 x 10^-3 = 9,72 x 10^8

Efficacité = 9,72x10^8 / 10^9 = 0,972 soit une efficacité de 97,2%.

La ligne à donc un débit utile théorique de 119Mo/s * 97,2% = 115Mo/s

Seconde hypothèse :

Rajoutons petit à petit les différents mécanismes propre au protocole tcp et tentons de démontrer que petit à petit on va tomber à une efficacité de 30%, ce qui nous mènera au 35Mo/s de berlinois.

Premier rajout, un mécanisme de récupération d'erreur. C'est à dire un mécanisme qui va renvoyer un accusé de réception (ACK) à l'émetteur une fois que le récepteur aura reçu le ou les paquets.

Il existe 3 type de mécanisme de récupération d'erreur:

Le Stop & Wait : J'envoie en paquet, je stop et j'attends l'accusé de réception.
Le sélective repeat : A chaque paquet envoyé on associe un timer. Si un paquet est en erreur, le destinataire stock les paquets suivants et attend que l'émetteur renvoie le paquet en erreur.
Go-Back-N : Si un paquet est en erreur, l'émetteur renvoie le paquet en erreur et tous les suivants déjà transmis.

Tcp emploie la seconde méthode. Je ne m'attarderai donc pas sur les autres.

Pour ceux que cela intéresse, voici un applet java qui montre comment fonctionne le sélective repeat : http://media.pearsoncmg.com/aw/aw_kurose_network_3/applets/SelectRepeat/SR.html

On va simplement considéré dans le calcul d'efficacité suivant qu'il n'y a pas eu d'erreur de transmission. Pour connaitre l'efficacité dans le cas du selective repeat, nous devons intégrer des nouvelles données.

L'efficacité va se calculer toujours de la même façon, c'est à dire le débit utile / débit brut. Ce qui va changer c'est la façon de calculer le débit utile :

Débit utile = Nombre de bit de donnée dans un paquet / (Temps de transmission paquet + Temps de transmission de l'ACK + 2 Temps de propagation).
On constate donc que l'on a intégré le temps de propagation dans notre calcul. Il se calcul comme suit : Tp = Distance (en m) / Vitesse de propagation en m/s (pour un réseau câblé, la vitesse de propagation est de 2*10^8 m/s).

On connait déjà le temps de transmission d'un paquet. Il est de :

Tpaquet = (1492 x 8) / 10^9 = 11936/10^9 = 0,001194 ms.

Tacquit = (40 x 8) / 10^9 = 0,00032 ms

Le délai de propagation (admettons que le réseau de Berlinois fasse 10m) : 10 / 2 x 10^8 = 0,00005 ms.

Le débit utile est donc de : (1452 x 8) / (0,000011936 + 0,00000032 + (2 * 0,00000005)) = 0,94 soit 94%.

De 119Mo/s, on n'est plus qu'à 111Mo/s.

Dans ce cas-ci, nous n'avons pas considéré la moindre retransmission de paquet. Pas d'erreur, juste l'intégration d'un mécanisme d'accusé de réception qui, avec la gestion des entêtes, nous faire perdre 6% d'efficacité de la ligne.

Troisième hypothèse :

Ajoutons un mécanisme de contrôle de flux : c'est à dire un mécanisme qui évite de noyer le récepteur avec une quantité de donnée qu'il serait incapable de traiter.

On va donc avoir une fenêtre d'émission qui correspond en fait à un nombre de paquet qui peuvent être envoyé en continu sans avoir été acquitter. Admettons par exemple que la taille de la fenêtre d'émission est de 5, je ne peux pas envoyer plus de 5 paquets sans recevoir d'ACK. Si j'envoie 5 paquets, et que je recois un ACK pour le premier, la fenêtre glisse d'un cran (revoir l'applet java montré plus haut), je peux donc continuer à envoyer en continu.

Le but ici sera de montrer par un calcul simple que le choix de la taille de la fenêtre peut avoir un impact important sur l'efficacité d'une ligne.

Pour ce faire, on aura besoin de :

W qui sera la taille de la fenêtre de contrôle de flux.
d = Tpaquet + Tacquit + 2 * Tpropagation + Ttraitement => nous donnera le délai pour envoyé un paquet de donnée.

Si d <= W * Tpaquet, alors je peux émettre en continu.

Je peux donc émettre à la vitesse maximale de 1 / Tpaquet par sec. (le contrôle de flux n'est donc pas actif).

L'efficacité se calcul donc comme suit : D / (D + H) ou D est le nombre de bit de Data et H le nombre de bit de l'entête.

Si d > W * Tpaquet, alors je suis bloqué en attente d'un acquit.

Je ne peux donc émettre qu'à W/d paquet par sec.

L'efficacité se calcul alors comme suit : (WD/débit brut)/d

Postulat : Admettons que la taille de ma fenêtre soit de 1 paquet.

d = 0,000012356 seconde.

W = 1.

Est ce que 0,000012356 <= 0,000011936 ? La réponse est non, je peux donc émettre à un rythme de 80932 paquets secondes.

Ce qui nous donne une efficacité de (1452/10^9)/0,000012356 = 0,117513758 soit 11%. Soit du 14Mo/s

Je prouve donc que le choix de la taille de ma fenêtre d'émission doit être intelligent (il peut être calculé). Ainsi un mauvais choix ne me permet pas d'exploiter + de 11% de la ligne.

Qui définit la taille de cette fenêtre ? c'est le récepteur et il adaptera la taille de la fenêtre en fonction de sa capacité à traiter les paquets reçus. Voici donc un élément qui n'est pas fixe et que je ne peux quantifier de façon exacte. Même si dans les faits, l'algorithme qui calcul la taille de la fenêtre d'émission est suffisamment optimisé pour ne pas faire d'ineptie comme je viens de le faire dans ce calcul.

Quatrième hypothèse :

Ajoutons un mécanisme de contrôle de congestion dont le but est de s'assurer que l'on envoie pas trop d'informations sur la ligne. Ce mécanisme est là pour s'assurer que l'on émet pas plus vite que la capacité de la ligne la plus lente.

Ce mécanisme va donc augmenter progressivement la charge du réseau jusqu'à ce que cela sature. Dès qu'il y a saturation, il baissera la charge. Ce jeu de yoyo se répètera régulièrement pour optimiser l'utilisation de la bande passante disponible.

On utilise ici l'algorithme du Slow Start pour contrôler la congestion des lignes et éviter ainsi une dégradation de la connexion réseau suite à une augmentation de retransmission de paquet perdu.

On va donc également avoir une fenêtre mais dite de congestion.

On va aborder la notion de MSS (Maximum Size Segment) qui désigne la quantité de donnée utile maximale que peut contenir un segment (remplacez segment par paquet pour mieux comprendre).

Au départ, la taille de la fenêtre de congestion est initialisé à 1 MSS. La taille de la fenêtre augmente de façon exponentielle jusqu'à un certain seuil. Ensuite ça devient une progression linéaire.

Si la taille de la fenêtre de congestion >= à la fenêtre de réception, alors la taille de la fenêtre de congestion est fixé à la taille de la fenêtre de réception.

Si un segment n'est pas acquitté après un certain temps, la taille de la fenêtre de congestion est réinitialisé à 1 et le seuil de progression linéaire est divisé par 2.

Ca donne ça graphiquement :

LA vitesse max est donc déterminé soit par la taille de la fenêtre de congestion, soit par la taille de la fenêtre de réception.

Bon, je suis trop crever pour faire le calcul démontrant qu'à ce stade l'efficacité de la ligne chute sensiblement et ce afin de garantir un partage des ressources le plus équitable possible.

Si quelqu'un le veut, je le fais demain, mais faut que je dorme là (je viens de passer 1h à taper cette merde et j'en ai marre). En plus je suis sur que personne n'a lu jusqu'au bout

Donc bonne année les Geeks, bisous. :rs:PS: Si quelqu'un veut la suite, il suffit de le dire.

CaL_bE · 1 janvier 2010

FonsD · 1 janvier 2010

Je veux la suite

J'aurais bien voulu t'avoir comme prof crapa fonsd.gif.840b40988e8b0237c1f9823e76133905.gif

1 janvier 2010

Sérieux anonymous, je vois mal en quoi le fait d'être en 32 ou 64 bits influencerais les débits ?

La quantité de RAM adressable à la limite. [:fonsd:17]

Crapa vient nous faire un CM

Ok, mais venez pas vous plaindre que c'est trop compliqué ou trop long ensuite.

Effectivement la vitesse de transfert ne peut pas être influencée par la taille des registres processeur qu'un OS est capable de gérer. Cela n'a strictement aucun rapport (ni même aucun sens). L'OS n'a pas "d'algorithme de transfert". Il a tout au plus certaines fonctionnalités de segmentation en paquet, de numérotation des paquets, de contrôle de congestion, de contrôle de flux, etc... le reste (c'est à dire les couches basses du modèle tcp) étant inclus directement dans le matériel (généralement dans le chipset de la carte réseau, c'est notamment le cas des protocoles IP/ARP/ICMP/IGMP/RARP/etc...).

Avant de me dire que la découpe en paquet nécessite une utilisation processeur et que la taille des registres peut influencer la vitesse, je précise tout de même que les vitesses processeur étant tellement énorme en regard de la vitesse d'un réseau qu'il est impossible que cela ait un impact.

C'est là que je vais être chiant...
Rappel de base :

Rappelons qu'une carte réseau 1000Mbps par seconde est capable de transférer 1000 millions de bits par seconde et non des octets. En terme d'octet, cela ferait donc une vitesse théorique de la carte réseau de 1000 / 8 = 125 Mégaoctets (et nous devrions utilisé des mébioctets) par seconde.

Pourquoi cette différence entre mébi et mega octets ici car les fabriquant de carte réseau exprime une vitesse de 1000 Mbps comme étant 1000 millions de bits par seconde. Hors en info , le multiple est 1024 et non 1000.

Il faut donc encore réduire le débit brut, ce qui donne un débit théorique brut de 119 Mo/s.

Vitesse de transfert

La vitesse de transfert est déterminée par plusieurs facteurs dont les deux plus importants sont le débit brut de la ligne (la bande passante) et les temps de latence.

Tout le problème pour déterminer le débit utile (c'est à dire le nombre de bit de donnée transmis par seconde) et l'efficacité d'une ligne est donc de pouvoir mesurer les temps de latence. Les temps de latence dépendent principalement du protocole utilisé et de son implémentation (mécanisme d'acquittement, contrôle d'erreur, contrôle de congestion, contrôle de flux, etc..).

Je vais essayer de détailler cela le plus simplement possible en partant du postulat d'une ligne sur laquelle on envoie des données et qui ne possèdent aucun temps de latence (elle n'a donc ni mécanisme de congestion, ni mécanisme d'acquittement, etc...) On rajoutera ces éléments par la suite.

Première hypothèse :

Un canal de transmission sans erreur de 1Mbps. On envoie en continu des paquets de 500 octets (dont 40 octets d'entête - 20 en tcp et 20 en IP).

Pour calculer l'efficacité d'une ligne on a besoin de connaitre :

le temps de transmission d'un paquet, c'est à dire le temps entre l'envoie du bit 1 du paquet et du bit N. Le temps de transmission est le rapport entre le nombre de bits transmis et le débit brut de la source.

le débit utile est calculé de la manière suivante : nombre de bit de donnée transmis / Temps de transmission.

L'efficacité de la ligne est le rapport entre le débit utile et le débit brut.

Donc partant de ce postulat, l'efficacité d'une telle ligne se calcul comme suit :

Tt (temps de transmission) = (500 x 8 (on convertit les octets transmis en bits) / 10^6 (ligne à 1Mbps) = 4000/10^6 = 4ms.
Débit utile = (460 x 8) / (4 x 10^-3 (Ce sont les 4 ms du dessus)) = 920 x 10^3 bps.

Efficacité d'une telle ligne est donc de (920 x 10^3) / 10^6 (débit brut) = 0,92 ou dit autrement, 92%.

On voit donc qu'une ligne classique à 1Mbps sans gestion d'erreur, avec des paquets de 500 octets perd 8% d'efficacité uniquement à cause des entêtes que le protocole rajoute.

Cas Berlinois

Faisons le même parallèle avec une ligne classique sous Windows. Soit un transfert de paquet égale à la taille maximum du paquet prévu par Windows (soit le MTU - Maximum Transfert Unit). Le MTU est de 1492 octets par défaut et Berlinois à une vitesse de ligne de 1000 Mbps.

Tt = (1492 x 8) / 10^9 = 11936/10^9 = 0,001194 ms.
Débit utile = (1452 x 8) / 0,001194 x 10^-3 = 11616/0,001194 x 10^-3 = 9,72 x 10^8

Efficacité = 9,72x10^8 / 10^9 = 0,972 soit une efficacité de 97,2%.

La ligne à donc un débit utile théorique de 119Mo/s * 97,2% = 115Mo/s

Seconde hypothèse :

Rajoutons petit à petit les différents mécanismes propre au protocole tcp et tentons de démontrer que petit à petit on va tomber à une efficacité de 30%, ce qui nous mènera au 35Mo/s de berlinois.

Premier rajout, un mécanisme de récupération d'erreur. C'est à dire un mécanisme qui va renvoyer un accusé de réception (ACK) à l'émetteur une fois que le récepteur aura reçu le ou les paquets.

Il existe 3 type de mécanisme de récupération d'erreur:

Le Stop & Wait : J'envoie en paquet, je stop et j'attends l'accusé de réception.

Le sélective repeat : A chaque paquet envoyé on associe un timer. Si un paquet est en erreur, le destinataire stock les paquets suivants et attend que l'émetteur renvoie le paquet en erreur.

Go-Back-N : Si un paquet est en erreur, l'émetteur renvoie le paquet en erreur et tous les suivants déjà transmis.

Tcp emploie la seconde méthode. Je ne m'attarderai donc pas sur les autres.

Pour ceux que cela intéresse, voici un applet java qui montre comment fonctionne le sélective repeat : http://media.pearsoncmg.com/aw/aw_kurose_network_3/applets/SelectRepeat/SR.html

On va simplement considéré dans le calcul d'efficacité suivant qu'il n'y a pas eu d'erreur de transmission. Pour connaitre l'efficacité dans le cas du selective repeat, nous devons intégrer des nouvelles données.

L'efficacité va se calculer toujours de la même façon, c'est à dire le débit utile / débit brut. Ce qui va changer c'est la façon de calculer le débit utile :

Débit utile = Nombre de bit de donnée dans un paquet / (Temps de transmission paquet + Temps de transmission de l'ACK + 2 Temps de propagation).

On constate donc que l'on a intégré le temps de propagation dans notre calcul. Il se calcul comme suit : Tp = Distance (en m) / Vitesse de propagation en m/s (pour un réseau câblé, la vitesse de propagation est de 2*10^8 m/s).

On connait déjà le temps de transmission d'un paquet. Il est de :

Tpaquet = (1492 x 8) / 10^9 = 11936/10^9 = 0,001194 ms.
Tacquit = (40 x 8) / 10^9 = 0,00032 ms

Le délai de propagation (admettons que le réseau de Berlinois fasse 10m) : 10 / 2 x 10^8 = 0,00005 ms.

Le débit utile est donc de : (1452 x 8) / (0,000011936 + 0,00000032 + (2 * 0,00000005)) = 0,94 soit 94%.

De 119Mo/s, on n'est plus qu'à 111Mo/s.

Dans ce cas-ci, nous n'avons pas considéré la moindre retransmission de paquet. Pas d'erreur, juste l'intégration d'un mécanisme d'accusé de réception qui, avec la gestion des entêtes, nous faire perdre 6% d'efficacité de la ligne.

Troisième hypothèse :

Ajoutons un mécanisme de contrôle de flux : c'est à dire un mécanisme qui évite de noyer le récepteur avec une quantité de donnée qu'il serait incapable de traiter.

On va donc avoir une fenêtre d'émission qui correspond en fait à un nombre de paquet qui peuvent être envoyé en continu sans avoir été acquitter. Admettons par exemple que la taille de la fenêtre d'émission est de 5, je ne peux pas envoyer plus de 5 paquets sans recevoir d'ACK. Si j'envoie 5 paquets, et que je recois un ACK pour le premier, la fenêtre glisse d'un cran (revoir l'applet java montré plus haut), je peux donc continuer à envoyer en continu.

Le but ici sera de montrer par un calcul simple que le choix de la taille de la fenêtre peut avoir un impact important sur l'efficacité d'une ligne.

Pour ce faire, on aura besoin de :

W qui sera la taille de la fenêtre de contrôle de flux.

d = Tpaquet + Tacquit + 2 * Tpropagation + Ttraitement => nous donnera le délai pour envoyé un paquet de donnée.

Si d <= W * Tpaquet, alors je peux émettre en continu.

Je peux donc émettre à la vitesse maximale de 1 / Tpaquet par sec. (le contrôle de flux n'est donc pas actif).
L'efficacité se calcul donc comme suit : D / (D + H) ou D est le nombre de bit de Data et H le nombre de bit de l'entête.

Si d > W * Tpaquet, alors je suis bloqué en attente d'un acquit.

Je ne peux donc émettre qu'à W/d paquet par sec.
L'efficacité se calcul alors comme suit : (WD/débit brut)/d

Postulat : Admettons que la taille de ma fenêtre soit de 1 paquet.

d = 0,000012356 seconde.
W = 1.

Est ce que 0,000012356 <= 0,000011936 ? La réponse est non, je peux donc émettre à un rythme de 80932 paquets secondes.
Ce qui nous donne une efficacité de (1452/10^9)/0,000012356 = 0,117513758 soit 11%. Soit du 14Mo/s

Je prouve donc que le choix de la taille de ma fenêtre d'émission doit être intelligent (il peut être calculé). Ainsi un mauvais choix ne me permet pas d'exploiter + de 11% de la ligne.

Qui définit la taille de cette fenêtre ? c'est le récepteur et il adaptera la taille de la fenêtre en fonction de sa capacité à traiter les paquets reçus. Voici donc un élément qui n'est pas fixe et que je ne peux quantifier de façon exacte. Même si dans les faits, l'algorithme qui calcul la taille de la fenêtre d'émission est suffisamment optimisé pour ne pas faire d'ineptie comme je viens de le faire dans ce calcul.

Quatrième hypothèse :

Ajoutons un mécanisme de contrôle de congestion dont le but est de s'assurer que l'on envoie pas trop d'informations sur la ligne. Ce mécanisme est là pour s'assurer que l'on émet pas plus vite que la capacité de la ligne la plus lente.

Ce mécanisme va donc augmenter progressivement la charge du réseau jusqu'à ce que cela sature. Dès qu'il y a saturation, il baissera la charge. Ce jeu de yoyo se répètera régulièrement pour optimiser l'utilisation de la bande passante disponible.

On utilise ici l'algorithme du Slow Start pour contrôler la congestion des lignes et éviter ainsi une dégradation de la connexion réseau suite à une augmentation de retransmission de paquet perdu.

On va donc également avoir une fenêtre mais dite de congestion.

On va aborder la notion de MSS (Maximum Size Segment) qui désigne la quantité de donnée utile maximale que peut contenir un segment (remplacez segment par paquet pour mieux comprendre).

Au départ, la taille de la fenêtre de congestion est initialisé à 1 MSS. La taille de la fenêtre augmente de façon exponentielle jusqu'à un certain seuil. Ensuite ça devient une progression linéaire.

Si la taille de la fenêtre de congestion >= à la fenêtre de réception, alors la taille de la fenêtre de congestion est fixé à la taille de la fenêtre de réception.

Si un segment n'est pas acquitté après un certain temps, la taille de la fenêtre de congestion est réinitialisé à 1 et le seuil de progression linéaire est divisé par 2.

Ca donne ça graphiquement :

LA vitesse max est donc déterminé soit par la taille de la fenêtre de congestion, soit par la taille de la fenêtre de réception.

Bon, je suis trop crever pour faire le calcul démontrant qu'à ce stade l'efficacité de la ligne chute sensiblement et ce afin de garantir un partage des ressources le plus équitable possible.

Si quelqu'un le veut, je le fais demain, mais faut que je dorme là (je viens de passer 1h à taper cette merde et j'en ai marre). En plus je suis sur que personne n'a lu jusqu'au bout

Donc bonne année les Geeks, bisous. :rs:PS: Si quelqu'un veut la suite, il suffit de le dire.

Je veux la suite

J'aurais bien voulu t'avoir comme prof crapa

Moi aussi

1 janvier 2010

Oui enfin c'est plus trop L'informatique pour les nuls là mais l'informatique pour les pros

1 janvier 2010

Oui enfin c'est plus trop L'informatique pour les nuls là mais l'informatique pour les pros

On est toujours le nul de qq'un.

Pob est celui de tout le monde.

Bonne année Pob

2 janvier 2010

Moi aussi

Tu peux être aussi chiant que tu veux concernant le processeur, je rappel qu'un simple processeur Core 2 Duo est capable d'exécuter + de 22 milliards d'instruction à la seconde. Un processeur à l'heure actuelle à donc la capacité de faire transiter plusieurs Go/s de données entre ses registres (rien qu'en 32 bits). Ce qui est largement supérieur à la vitesse d'un transfert réseau.

La seule chose qui peut freiner, ce sont plutôt les vitesses d'écriture sur disque dur. Mais la le système d'exploitation n'est absolument plus responsable des limitations matériels des fabricants. Et ceci peut être un véritable problème puisque le récepteur va devoir indiquer à l'émetteur que le contrôle de flux doit être activé en diminuant la taille de la fenêtre.

A l'heure actuelle, à moins d'être avec des disques dur SSD, la majorité des disques sont incapable de tenir une performance moyenne en écriture qui soit supérieur à la vitesse du débit brut théorique d'un réseau gigabit (sauf quelques exceptions utilisant du SCSI ou autre technologie du même acabit).

Reprenons :

1 MSS est égale à la taille du MTU sur une ligne ADSL classique, soit 1492 octets.
Débit brut = 10^9 bps.
La taille de la fenêtre sera de maximum 65 535 octets. L'entête tcp ne prévoit qu'un codage de 16 bits pour déterminer la taille de la fenêtre (soit une impossibilité d'envoyer un flot continu. La taille de la fenêtre sera adapté tous les 44 paquets maximum).
Le RTT (c'est à dire le temps entre l'envoie du premier bit d'un paquet et la réception du dernier bit de l'ACK) sera arbitrairement déterminé à 1ms (en faisant un ping sur mon réseau, j'obtiens un RTT supérieur à 1ms. +- 1,3 à 1,5ms en moyenne).

Je peux donc envoyer 1000 fenêtres maximum (1 sec divisé par le RTT) toutes les secondes. Ce qui donne concrètement un débit réel de 62,5Mo/s (Nombre de fenêtre de congestion * 65535).

J'obtiens donc une efficacité maximum de 0,52 (toujours le débit utile / débit brut). J'obtiens donc avec mon postulat une efficacité de la ligne de 52%.

Je vais donc tenter de déterminer la taille de la fenêtre de congestion maximum que devrait avoir un tel réseau (44 MSS étant beaucoup trop).

Déterminantion de la taille de la fenêtre de congestion :

Si (rwnd (c'est à dire la taille de la fenêtre de réception) * (MSS + entête)) / d <= que le débit de la ligne la plus lente, alors c'est la fenêtre du récepteur qui va limiter la vitesse maximale. En résumé, c'est le contrôle de flux qui agit.

Sinon, c'est la capacité réseau qui limite la vitesse max. Il faut donc résoudre : (cwnd (taille de la fenêtre de congestion) * (MSS + entête))/d <= débit de la ligne la plus lente.

(rwnd . MSS) / d (soit Tpaquet + Tacquit + 2 * Tpropagation) <= 1 Gbps.

(25 (taille de la fenêtre de réception fixé arbitrairement et qui n'a pas d'incidence sur ce calcul) * (1492 * 8)) / 0,000012356 <= 10^9

24,15 * 10^9 <= 10^9 ? Non. Donc la taille de la fenêtre de congestion est donc limité par le réseau.

On doit alors connaitre la taille de la fenêtre de congestion avant de pouvoir procéder à une évaluation de l'efficacité. On part donc de l'équation suivante :

(cwnd . MSS) / d <= 1 Gbps.

cwnd_max <= 1 Gbps * d / MSS

(10^9 * 0,000012356) / MSS

Soit une fenêtre de congestion maximum qui serait égale à 123560/(1492 * 8) = 10. cwnd_max <= 10 MSS < rwnd

La taille de la fenêtre de congestion est donc égale à 10. En reprenant le calcul fait juste avant, et un RTT mesuré sur mon réseau à 0,3 sec. J'obtiens la possibilité de transmettre 3300 fenêtres à la seconde. Chaque fenêtre pouvant envoyé 10 (MSS) x 1452 octets utile (j'ai enlevé les entêtes). J'obtiens donc un débit utile maximum de ma ligne de 45,7Mo/s.

Soit une efficacité de l'ordre de 38%.

berlinois · 2 janvier 2010

Merci crapahut pour ces beaux cours en électronique/informatique.

Mais cela ne me dit toujours pas pourquoi j'ai une telle disparité de débits sur mon réseau.

2 janvier 2010

Merci crapahut pour ces beaux cours en électronique/informatique.

Mais cela ne me dit toujours pas pourquoi j'ai une telle disparité de débits sur mon réseau.

Normal, je répondais à la question de FonsD sur la possibilité ou non qu'un OS 64 bits puisse avoir un impact sur les performances réseau.

Tu nous as juste expliqué que tu avais une légère différence entre un linux et ton windows 7. De l'ordre de 5Mo/s. Pas de quoi fouettez un chat puisque cela peut venir de l'implémentation même du protocole tcp entre linux et windows qui utilisera peut être des algorithmes qui optimiseront certaines fonctionnalités comme la congestion et/ou le contrôle de flux.

Pour ce qui est de ton XP à 12Mo/s, cela peut venir de plein de trucs. Si tout ton matériel est bien en Gbps, alors cela peut-être simplement la taille du MTU qui fixe des segments maximum à une taille inférieur à la moyenne. Il faut vérifier dans la base de registre qu'elle est la valeur par défaut. Il peut y avoir d'autre raisons comme un disque dur trop lent, le chipset de la carte réseau en 100Mbps, etc.... C'est de la voyance à ce stade.

Je vérifierais d'abord le round time trip moyen avec la commande ping sur chaque machine et tu verras si les temps de latence sont + important ou pas sur l'XP.

2 janvier 2010

On est toujours le nul de qq'un.

Pob est celui de tout le monde.

Bonne année Pob

C'est sur, mais je pensais que l'algo de transfert etait plus rapide en 64 bits :/

2 janvier 2010

2 janvier 2010

Merci crapahut pour ces beaux cours en électronique/informatique.

Mais cela ne me dit toujours pas pourquoi j'ai une telle disparité de débits sur mon réseau.

Pour avoir egalement un reseau en Gigabit, j'ai été confronté a la meme limite, je plafonnais a 35Mo/S, quel que soit l'OS.

Sauf quand je transfere sur mon portable, qui lui a un SSD.

Donc ca voudrait dire que la limite est en ecriture au niveau des disques.

Cependant, quand je fait des transfert de DD a DD sur la meme machine, j'arrive a 60Mo/s...

2 janvier 2010

C'est sur, mais je pensais que l'algo de transfert etait plus rapide en 64 bits :/

Ah toi aussi, tu t'es laissé abusé par des comparatifs à la con.

Ca va. :q

3 janvier 2010

vous oubliez aussi le cache en lecture / Ecriture d'un module bbwc d'une carte raid :bah; ca peu varier de 50mo/S a plusieurs centaine de Mo/s selon les perfs des hdd et leur mode de fonctionnement

un SE c'est un tout, et si tu ne connais pas la chaine logique des choses, tu peu chercher LONGTEMPS, entre le réseau, le hardware, la config de l'os et du matos en low level

berlinois · 3 janvier 2010

Normal, je répondais à la question de FonsD sur la possibilité ou non qu'un OS 64 bits puisse avoir un impact sur les performances réseau.

Tu nous as juste expliqué que tu avais une légère différence entre un linux et ton windows 7. De l'ordre de 5Mo/s. Pas de quoi fouettez un chat puisque cela peut venir de l'implémentation même du protocole tcp entre linux et windows qui utilisera peut être des algorithmes qui optimiseront certaines fonctionnalités comme la congestion et/ou le contrôle de flux.

Pour ce qui est de ton XP à 12Mo/s, cela peut venir de plein de trucs. Si tout ton matériel est bien en Gbps, alors cela peut-être simplement la taille du MTU qui fixe des segments maximum à une taille inférieur à la moyenne. Il faut vérifier dans la base de registre qu'elle est la valeur par défaut. Il peut y avoir d'autre raisons comme un disque dur trop lent, le chipset de la carte réseau en 100Mbps, etc.... C'est de la voyance à ce stade.

Je vérifierais d'abord le round time trip moyen avec la commande ping sur chaque machine et tu verras si les temps de latence sont + important ou pas sur l'XP.

En fait c'est totalement aléatoire.

Si toutes mes bécanes tournaient autour de 40 Mo/s je serais satisfait.

Mais c'est surtout les machines sous XP qui me chagrinent car elles ont des taux de transferts très variables, allant de moins de 12 Mo/s à 35-40 Mo/s sans que je comprenne pourquoi.

Les ordi sous XP sous tous en pro, mis à jour parfaitement et mis à part le hardware sont tous installés avec les mêmes logiciels pouvant impacter les transferts réseaux.

Quant aux temps de latence, pas de problème particulier à signaler les réponses sont les mêmes d'ordi à ordi.

pataratapat · 3 janvier 2010

Salut à tous, et bonne année 2010 .

Ma chère et tendre m'a offert à Noël un joli petit iPod Shuffle, 4Go .

MAIS... je suis sous Windows XP x64... avec lequel il m'est impossible d'installer une version récente d'iTunes : j'ai la 7.5 en 32 bits, et cette version n'est pas compatible avec mon iPod.

J'ai tenté d'installer iTunes version 8 (32bits) et versions 9 (32 et 64 bits), mais impossible, il y a toujours une couille qui annule l'installation...

Les modes "Compatibilité Windows XP" ne changent rien.

J'ai alors fouillé la toile et ai téléchargé 2 softs sensés permettre l'usage d'un iPod sans iTunes.

- Le 1er fut "iShuffle-Without-iTunes", mais même si je procède comme indiqué (et que tout semble OK), j'ai toujours le message "Please use iTunes to sync your music with this iPod", ou un truc du genre...

- 2eme essais avec "yam-win_v1.8" (Yamipod en fait), mais lui ne détecte pas le baladeur...

Quelque un aurait une idée ?

Merci...

p@+

didier_76 · 3 janvier 2010

Salut à tous,

Je vous soumets un problème rencontré avec mon DELL Inspiron 6400

Subitement mon écran s'est effacé pour devenir inutilisable et grisâtre... Après 2 minutes il est redevenu normal... Pour 10 minutes... Depuis il reste gris...

J'ai cru que le câble de liaison LCD/carte graphique était HS... Je viens de réinstaller le nouveau mais rien de mieux...

Après de nombreuses recherches, j'ai découvert que des problèmes d'inverter lcd pouvaient être à l'origine de ceci...

En avez-vous une quelconque expérience ?

Merci...

Lorent2 · 4 janvier 2010

Salut à tous, et bonne année 2010 .

Ma chère et tendre m'a offert à Noël un joli petit iPod Shuffle, 4Go .

MAIS... je suis sous Windows XP x64... avec lequel il m'est impossible d'installer une version récente d'iTunes : j'ai la 7.5 en 32 bits, et cette version n'est pas compatible avec mon iPod.
J'ai tenté d'installer iTunes version 8 (32bits) et versions 9 (32 et 64 bits), mais impossible, il y a toujours une couille qui annule l'installation...
Les modes "Compatibilité Windows XP" ne changent rien.

J'ai alors fouillé la toile et ai téléchargé 2 softs sensés permettre l'usage d'un iPod sans iTunes.

- Le 1er fut "iShuffle-Without-iTunes", mais même si je procède comme indiqué (et que tout semble OK), j'ai toujours le message "Please use iTunes to sync your music with this iPod", ou un truc du genre...
- 2eme essais avec "yam-win_v1.8" (Yamipod en fait), mais lui ne détecte pas le baladeur...

Quelque un aurait une idée ?
Merci...

p@+

CopyTransManager : http://fr.copytrans.net/download-zip.php?program=CTM

4 janvier 2010

Yo

J'ai un pc acer caca (oui je sais ) avec un win vista familial officiel qui va bien (enfin bien... c'est vista quoi)... Installé d'origine sur mon pc carrouf.

Pas de CD d'install, truc classique.

La question est : est ce possible de choper le dur du pc et de le mettre dans un nouveau pc tout neuf sans galerer ? Y'a t il des protections de numéro de série sur la CM ou je ne sais quoi ?

Merci d'avance

4 janvier 2010

Yo

J'ai un pc acer caca (oui je sais ) avec un win vista familial officiel qui va bien (enfin bien... c'est vista quoi)... Installé d'origine sur mon pc carrouf.
Pas de CD d'install, truc classique.

La question est : est ce possible de choper le dur du pc et de le mettre dans un nouveau pc tout neuf sans galerer ? Y'a t il des protections de numéro de série sur la CM ou je ne sais quoi ?
Merci d'avance

Tu pourras uniquement mettre ton DD sur un autre pc portable oui tu peux il y aura certainement des trucs a regler mais c'est possible

4 janvier 2010

Bon, moi j'ai un problème bien plus grave

J'ai sur un PC un problème, quand je vais dans "gestionnaire de périphérique" j'ai des cartes réseau fantômes, et je n'arrive pas a les supprimer

la seule solution est d'aller dans les registre, avant de faire des conneries quelqu'un peut il m'aider ?

pataratapat · 4 janvier 2010

CopyTransManager : http://fr.copytrans.net/download-zip.php?program=CTM

Ce soft a besoin d'une 1ere initialisation de l'iPod par iTunes pour pouvoir fonctionner correctement...

Toujours pareil... :/ Idem avec Winamp j'ai l'impression.

Il reconnait bien mon iPod, je peux transférer des morceaux dessus (comme je peux le faire via Windows directement, puisque l'iPod est reconnu comme un disque externe).

Mais toujours le message d'erreur quand je lance une écoute...

J'ai l'impression que tous ces softs externes sont surtout là pour remplacer iTunes une fois l'iPod initialisé une 1ere fois via... iTunes justement bizzik.gif.10d5d2e68dced7e0fdf852a3c26369f3.gif .

Mon problème est que j'ai besoin d'utiliser mon iPod sans JAMAIS recourir à iTunes, puisqu'il n'existe pas d'iTunes compatible à la fois avec cet iPod Shuffle et avec Windows XP x64...

Ce que je ne comprend pas non plus, c'est l'impossibilité d'installer une version 32bits récente d'iTunes...

p@+

4 janvier 2010

Ce soft a besoin d'une 1ere initialisation de l'iPod par iTunes pour pouvoir fonctionner correctement...

Toujours pareil... :/ Idem avec Winamp j'ai l'impression.
Il reconnait bien mon iPod, je peux transférer des morceaux dessus (comme je peux le faire via Windows directement, puisque l'iPod est reconnu comme un disque externe).

Mais toujours le message d'erreur quand je lance une écoute...

J'ai l'impression que tous ces softs externes sont surtout là pour remplacer iTunes une fois l'iPod initialisé une 1ere fois via... iTunes justement .

Mon problème est que j'ai besoin d'utiliser mon iPod sans JAMAIS recourir à iTunes, puisqu'il n'existe pas d'iTunes compatible à la fois avec cet iPod Shuffle et avec Windows XP x64...
Ce que je ne comprend pas non plus, c'est l'impossibilité d'installer une version 32bits récente d'iTunes...

p@+

Itunes, c'est de la merde en barre, rien d'etonnant au fait que ca plante a l'install

Sinon, pour les ipod, j'avais trouvé a l'epoque un pti soft (en fait un bete executable) que tu colles a la racine de ton ipod, et que tu lances apres avoir copié/collé tes mp3 dna la memoire de l'ipod.

pataratapat · 4 janvier 2010

Bah moi iTunes me convient pour écouter de la zik, par contre la où Apple déconne, c'est de verrouiller autant leur lecteur alors qu'ils n'assurent pas le support pour tous les OS...

Sinon, le soft dont tu parles me fait penser au 1er que j'ai essayé : "iShuffle-Without-iTunes".

p@+

4 janvier 2010

Bah moi iTunes me convient pour écouter de la zik, par contre la où Apple déconne, c'est de verrouiller autant leur lecteur alors qu'ils n'assurent pas le support pour tous les OS...

Sinon, le soft dont tu parles me fait penser au 1er que j'ai essayé : "iShuffle-Without-iTunes".

p@+

Ouais, ca me dit qchose ce nom..

Ca marche tres bien

Sinon, ecouter de la musique avec itunes apalta.gif.df6d34180c296835044c7949d391da86.gif

pataratapat · 4 janvier 2010

4 janvier 2010

Je cherche désespéremment un logiciel de montage de vidéo simple genre Movie Maker mais qui prenne les vidéos Full HD 60fps et 30 fps.

J'ai télechargé la version d'essai de Magix Easy chépakoi mais les vidéos ressortent toutes hâchées...

Je pense que c'est fait expres étant donné qu'il s'agit d'une version d'essai et qu'ils font cela pour éviter qu'on tente de la craquer mais j'ai des doutes

Qu'en pensez vous?

Microsoft pourrait pondre une mise à jour de son Movie Maker pour qu'il accepte le HD

5 janvier 2010

J'ai encore un soucis, j'ai filmé des trucs avec une Sanyo Xacti FH1 full HD 190x1080 60fps et j'y ai posté sur Youtube, je lance la lecture et c'est hâché :/

La qualité que j'ai mon pc n'y est plus du tout.

pataratapat · 5 janvier 2010

Ce soft a besoin d'une 1ere initialisation de l'iPod par iTunes pour pouvoir fonctionner correctement...

Toujours pareil... :/ Idem avec Winamp j'ai l'impression.
Il reconnait bien mon iPod, je peux transférer des morceaux dessus (comme je peux le faire via Windows directement, puisque l'iPod est reconnu comme un disque externe).

Mais toujours le message d'erreur quand je lance une écoute...

J'ai l'impression que tous ces softs externes sont surtout là pour remplacer iTunes une fois l'iPod initialisé une 1ere fois via... iTunes justement .

Mon problème est que j'ai besoin d'utiliser mon iPod sans JAMAIS recourir à iTunes, puisqu'il n'existe pas d'iTunes compatible à la fois avec cet iPod Shuffle et avec Windows XP x64...
Ce que je ne comprend pas non plus, c'est l'impossibilité d'installer une version 32bits récente d'iTunes...

p@+

YES !

J'ai trouvé une solution, grâce à ce lien.

Je vous copie-colle ci-dessous les conseils que j'ai suivis et qui me permettent aujourd'hui d'avoir iTunes 8.2.1.6 version 64bits, compatible XP x64 ET iPod Shuffle 3eme génération .

Got it! To install iTunes x64 on XP x64:

1. Download iTunes x64 (iTunesSetup64.exe)
2. Unzip.
3. Modify with Orca the AppleMobileDeviceSupport64.msi file: delete Launch Condition's table and, in InstallUISequence's table, delete de LaunchCondition's row. Save overwriting existing file.
4. Modify with Orca the iTunes64.msi file: delete Launch Condition's table and, in InstallUISequence, delete de LaunchCondition's row; finally (and that's the trick) delete ServiceControl and ServiceInstall tables. Save overwriting existing file.
5. Install, in this order:

- AppleApplicationSupport.msi (<-- note de moi : j'ai pas ce programme dans le 8.2.1.6 décompressé, je suis donc directement passé à l'étape suivante)
- AppleMobileDeviceSupport64.msi
- iTunes64.msi

Maybe you have to install Quicktime first, if iTunes.msi doesn't, or other msi files.

6. Finally, first time you launch iTunes, gives you an error (something about ipodservice.exe) and automatically close iTunes. Just repair the installation executing the original package (iTunes.exe without Orcas' modifications) and.... done!

It works for me. I hope it works for you!

Please excuse my limited English (I'm spanish). Corrections are welcome!

Bye!!!

PD: just in case, I disabled firewall and antivirus first. I didn't try to conect iPod after install iTunes, so I don't now if it will work fine.

p@+

6 janvier 2010

Salut bande de moules

J'ai actuellement une tour reliée à un moniteur par un cable à la con classique

J'aimerais dans le même temps relier ma tour à ma TV via la prise PC.

Et j'ai pas envie de débrancher/rebrancher à chaque foisque je basculerai du bureau au canapé

Il existe des commutateurs/switchs qui me permettent de laisser brancher les 2 cables sur la tour en continu?

Merci

6 janvier 2010

Les 2 câbles sur la tour, je ne sais pas, mais il existe des switchs que tu branches sur ton PC et qui ont 2, 4, 8 sorties, voir plus encore.

Tu en as qui bascule en appuyant sur une touche du clavier, donc plus besoin d'intervenir physiquement sur le switch ce qui te permet de le planquer quelque part.

Prends ton moteur de recherche préféré et cherche KVM.

6 janvier 2010

Salut bande de moules

J'ai actuellement une tour reliée à un moniteur par un cable à la con classique
J'aimerais dans le même temps relier ma tour à ma TV via la prise PC.

Et j'ai pas envie de débrancher/rebrancher à chaque foisque je basculerai du bureau au canapé

Il existe des commutateurs/switchs qui me permettent de laisser brancher les 2 cables sur la tour en continu?

Merci

c'etait super dur a trouver

http://www.materiel.net/ctl/Cables_video/33389-Doubleur_VGA.html

http://www.materiel.net/live/34165.jpg

6 janvier 2010

Les 2 câbles sur la tour, je ne sais pas, mais il existe des switchs que tu branches sur ton PC et qui ont 2, 4, 8 sorties, voir plus encore.

Tu en as qui bascule en appuyant sur une touche du clavier, donc plus besoin d'intervenir physiquement sur le switch ce qui te permet de le planquer quelque part.

Prends ton moteur de recherche préféré et cherche KVM.

Tu sais ce que ca veux dire, KVM ???

6 janvier 2010

c'etait super dur a trouver

http://www.materiel.net/ctl/Cables_video/33389-Doubleur_VGA.html

http://www.materiel.net/live/34165.jpg

Pourquoi me faire chier j'ai le petit personnel à disposition

Merci

Edit : Ca risque pas de faire foirer un peu l'image le doubleur?

Toute l'actu Caradisiac

Essais par catégories

Tous les guides d'achat

Les services Caradisiac

Conseils

Entretien

Les forums

Top marques

Toutes les marques

Connexion

L'informatique pour les nuls :D

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Invité §Cra883ru

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité §ano721zW

Lien vers le commentaire

Partager sur d’autres sites

Invité §mou628SZ

Lien vers le commentaire

Partager sur d’autres sites

Invité §ano721zW

Lien vers le commentaire

Partager sur d’autres sites

Invité §Cra883ru

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité §Cra883ru

Lien vers le commentaire

Partager sur d’autres sites

Invité §pob474iW

Lien vers le commentaire

Partager sur d’autres sites

Invité §Cra883ru

Lien vers le commentaire

Partager sur d’autres sites

Invité §pob474iW

Lien vers le commentaire

Partager sur d’autres sites

Invité §ano721zW

Lien vers le commentaire

Partager sur d’autres sites

Invité §smo086WD

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité §sak288gW

Lien vers le commentaire

Partager sur d’autres sites

Invité §chr408md

Lien vers le commentaire

Partager sur d’autres sites

Invité §chr408md

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité §pob474iW

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Invité §pob474iW

Lien vers le commentaire

Partager sur d’autres sites