j'ai un serveur Linux qui tourne avec un serveur vnc.
Je cherche =E0 l'administrer depuis Chicken of the vnc et la souris sur
le client est d'une lenteur limite inutilisable.
Auparavant j'utilisais une machine linux et ca fonctionnait =E0 une
vitesse tout =E0 fait correcte.
Maintenant que je suis sur mac, c'est trop lent.
Le r=E9seau n'a pas chang=E9, sauf que je suis connect=E9 en wifi en
54mbps. Une option mal r=E9gl=E9e qque part ?
Il faudrait que je reteste en me branchant en filaire et repasser en
100 pour voir.
Dans l'article <eh1tpg$6et$, Franck <franck+ écrit:
ceci dit, je n'avais pas essayé longtemps, car Connexion Bureau à Distance est bien meilleur que VNC...
Ce qui est normal, car la fonction "Bureau à distance" est intégrée à windows (coté serveur), et fonctionne par envoi au client d'ordres graphiques à exécuter (exemple : tracer une ligne de tel point à tel autre),
Comme XWindow? (Sauf que dans la pratique, XWindow est en général bien plus lent que VNC, enfin c'est ce que j'ai remarqué...)
ce qui ne consomme rien coté réseau (hormis lorsque l'on veut afficher un bitmap), alors que VNC effectue des copies d'écran, ce qui consomme énormément plus de bande passante.
Ce sont plutôt des copies de rectangles (pleins). Ensuite, tout est dans le découpage de la zone à rafraîchir en rectangles, mais aussi dans la fréquence de rafraîchissement: inutile de demander au serveur des rectangles à rafraîchir si on n'est pas capable de suivre; c'est pourtant le problème de CotVNC, semble-t-il: en bougeant rapidement la souris, je pouvais voir le rafraîchissement continuer au bout de plusieurs secondes, avec des opérations qui s'annulaient mutuellement.
Dans l'article <eh1tpg$6et$1@tous.apoal.com>,
Franck <franck+news@_remove_apoal.com> écrit:
ceci dit, je n'avais pas essayé longtemps, car Connexion Bureau à
Distance est bien meilleur que VNC...
Ce qui est normal, car la fonction "Bureau à distance" est intégrée à
windows (coté serveur), et fonctionne par envoi au client d'ordres
graphiques à exécuter (exemple : tracer une ligne de tel point à tel
autre),
Comme XWindow? (Sauf que dans la pratique, XWindow est en général bien
plus lent que VNC, enfin c'est ce que j'ai remarqué...)
ce qui ne consomme rien coté réseau (hormis lorsque l'on veut
afficher un bitmap), alors que VNC effectue des copies d'écran, ce
qui consomme énormément plus de bande passante.
Ce sont plutôt des copies de rectangles (pleins). Ensuite, tout est
dans le découpage de la zone à rafraîchir en rectangles, mais aussi
dans la fréquence de rafraîchissement: inutile de demander au serveur
des rectangles à rafraîchir si on n'est pas capable de suivre; c'est
pourtant le problème de CotVNC, semble-t-il: en bougeant rapidement
la souris, je pouvais voir le rafraîchissement continuer au bout de
plusieurs secondes, avec des opérations qui s'annulaient mutuellement.
Dans l'article <eh1tpg$6et$, Franck <franck+ écrit:
ceci dit, je n'avais pas essayé longtemps, car Connexion Bureau à Distance est bien meilleur que VNC...
Ce qui est normal, car la fonction "Bureau à distance" est intégrée à windows (coté serveur), et fonctionne par envoi au client d'ordres graphiques à exécuter (exemple : tracer une ligne de tel point à tel autre),
Comme XWindow? (Sauf que dans la pratique, XWindow est en général bien plus lent que VNC, enfin c'est ce que j'ai remarqué...)
ce qui ne consomme rien coté réseau (hormis lorsque l'on veut afficher un bitmap), alors que VNC effectue des copies d'écran, ce qui consomme énormément plus de bande passante.
Ce sont plutôt des copies de rectangles (pleins). Ensuite, tout est dans le découpage de la zone à rafraîchir en rectangles, mais aussi dans la fréquence de rafraîchissement: inutile de demander au serveur des rectangles à rafraîchir si on n'est pas capable de suivre; c'est pourtant le problème de CotVNC, semble-t-il: en bougeant rapidement la souris, je pouvais voir le rafraîchissement continuer au bout de plusieurs secondes, avec des opérations qui s'annulaient mutuellement.
Dans l'article <1hncojx.1x9vdr6txa97mN%, Benoit Leraillez écrit:
*Il me semble qu'un écran en 1024*768 fait dans les 3 Mo en millions de couleurs, 800 Ko en 256 et si on passe en 800*600 on devrait tomber dans les 400 Ko soit pas loin de 10 fois moins de données à transférer avant compression.
La résolution de l'écran n'influe pas beaucoup (sauf si le but est d'avoir une meilleure qualité au lieu de plus d'espace pour les différentes fenêtres). Pour info, avec un serveur sur mon PowerBook G4 sous Linux (1152x768) et mon client sur Iyonix (RISC OS) en 16 bpp, les rafraîchissements étaient quasiment immédiats. Avec le même client sur mon ancienne machine (Risc PC sous RISC OS, mais avec une carte réseau à 10 Mbps cette fois, et un bus processeur - carte graphique d'il y a 12 ans), c'était plus lent, mais ça restait largement utilisable. Alors le fait d'utiliser un écran en 1024x768 et 32 bpp n'explique pas à lui seul la lenteur de CotVNC.
Dans l'article <1hncojx.1x9vdr6txa97mN%benoit.sansspam@leraillez.sansspam.com>,
Benoit Leraillez <benoit.sansspam@leraillez.sansspam.com> écrit:
*Il me semble qu'un écran en 1024*768 fait dans les 3 Mo en millions
de couleurs, 800 Ko en 256 et si on passe en 800*600 on devrait tomber
dans les 400 Ko soit pas loin de 10 fois moins de données à transférer
avant compression.
La résolution de l'écran n'influe pas beaucoup (sauf si le but est
d'avoir une meilleure qualité au lieu de plus d'espace pour les
différentes fenêtres). Pour info, avec un serveur sur mon PowerBook G4
sous Linux (1152x768) et mon client sur Iyonix (RISC OS) en 16 bpp, les
rafraîchissements étaient quasiment immédiats. Avec le même client sur
mon ancienne machine (Risc PC sous RISC OS, mais avec une carte réseau
à 10 Mbps cette fois, et un bus processeur - carte graphique d'il y a
12 ans), c'était plus lent, mais ça restait largement utilisable. Alors
le fait d'utiliser un écran en 1024x768 et 32 bpp n'explique pas à lui
seul la lenteur de CotVNC.
Dans l'article <1hncojx.1x9vdr6txa97mN%, Benoit Leraillez écrit:
*Il me semble qu'un écran en 1024*768 fait dans les 3 Mo en millions de couleurs, 800 Ko en 256 et si on passe en 800*600 on devrait tomber dans les 400 Ko soit pas loin de 10 fois moins de données à transférer avant compression.
La résolution de l'écran n'influe pas beaucoup (sauf si le but est d'avoir une meilleure qualité au lieu de plus d'espace pour les différentes fenêtres). Pour info, avec un serveur sur mon PowerBook G4 sous Linux (1152x768) et mon client sur Iyonix (RISC OS) en 16 bpp, les rafraîchissements étaient quasiment immédiats. Avec le même client sur mon ancienne machine (Risc PC sous RISC OS, mais avec une carte réseau à 10 Mbps cette fois, et un bus processeur - carte graphique d'il y a 12 ans), c'était plus lent, mais ça restait largement utilisable. Alors le fait d'utiliser un écran en 1024x768 et 32 bpp n'explique pas à lui seul la lenteur de CotVNC.
