comment tu mesurais tes 10 à 50kio/s? Parce que chez, glxgears en export display, c'est 9Mb/s avec des pointe à 15Mb/s!
Affichage graphique distant F18 vers F16
Avec :
Surveillance du système
Version 4.8.5 (4.8.5)
Utilisation de la plate-forme de développement de KDE 4.8.5 (4.8.5)
- Modifié
essaye avec iptraf, mais même 50ko/s ça me semble très faible pour de l'affichage déporté.
tu le lance dans une konsole, tu va dans "Detailed Interface Statistics", tu choisi l'interface utilisée pour ton export display, et tu lances tourner un peu, ça t'affichera un débits au bout de quelques secondes.
tu le lance dans une konsole, tu va dans "Detailed Interface Statistics", tu choisi l'interface utilisée pour ton export display, et tu lances tourner un peu, ça t'affichera un débits au bout de quelques secondes.
toujours avec un ssh -XC
Avec toujours des engrenages qui patinent.
et puis le résultats de iptraf-ng

$ LIBGL_ALWAYS_INDIRECT=y LIBGL_DEBUG=verbose glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
23863 frames in 5.2 seconds = 4581.430 FPS
3247 frames in 5.4 seconds = 606.593 FPS
3897 frames in 5.6 seconds = 697.014 FPS
3896 frames in 5.6 seconds = 695.394 FPS
3637 frames in 5.6 seconds = 652.209 FPS
3897 frames in 5.6 seconds = 698.012 FPS
3896 frames in 5.6 seconds = 692.007 FPS
3637 frames in 5.6 seconds = 651.793 FPS
3897 frames in 5.6 seconds = 696.637 FPS
3767 frames in 5.0 seconds = 746.958 FPS
3118 frames in 5.1 seconds = 611.253 FPS
5195 frames in 5.2 seconds = 1005.835 FPS
11950 frames in 5.2 seconds = 2318.520 FPS
5325 frames in 5.5 seconds = 961.388 FPS
Avec toujours des engrenages qui patinent.
et puis le résultats de iptraf-ng

Première étape sur les deux postes
Ensuite sur le client-F16, j'ai
Et sur le serveur :
et le iptraf-ng

Visuellement, j'ai le même rendu sur les deux machines.
En affichage distant,
- le redimensionnemet de la fenetres glxspheres est lent
- la fenetre ne quitte pas instantanement avec le clic sur la croix (quelques secondes).
En effet, ce qui rend l'utilisation distante pénible, c'est la latente entre les actions sur les menus et les réponses.
Finalement est-ce vraiment un probléme d'affichage ?
Je viens de lancer la mise à jour du serveur, il y a les choses suiantes :
un reboot pour prendre en compte le kernel.
Et nous avons :
avec

# yum install VirtualGL
Ensuite sur le client-F16, j'ai
$ glxspheres
Polygons in scene: 62464
Visual ID of window: 0xf4
Context is Direct
OpenGL Renderer: Gallium 0.4 on NV98
80.879567 frames/sec - 84.645319 Mpixels/sec
76.555158 frames/sec - 80.119566 Mpixels/sec
82.371542 frames/sec - 86.206761 Mpixels/sec
82.727103 frames/sec - 86.578877 Mpixels/sec
82.051449 frames/sec - 85.871765 Mpixels/sec
82.857736 frames/sec - 86.715592 Mpixels/sec
83.127341 frames/sec - 86.997750 Mpixels/sec
82.920753 frames/sec - 86.781543 Mpixels/sec
81.994497 frames/sec - 85.812161 Mpixels/sec
82.247579 frames/sec - 86.077026 Mpixels/sec
82.926293 frames/sec - 86.787341 Mpixels/sec
82.643598 frames/sec - 86.491484 Mpixels/sec
Et sur le serveur :
$ LIBGL_ALWAYS_INDIRECT=y LIBGL_DEBUG=verbose glxspheres
Polygons in scene: 62464
Visual ID of window: 0xf4
Context is Indirect
OpenGL Renderer: Gallium 0.4 on NV98
329.589501 frames/sec - 344.935188 Mpixels/sec
80.790592 frames/sec - 84.552202 Mpixels/sec
77.428981 frames/sec - 81.034074 Mpixels/sec
79.647391 frames/sec - 81.859175 Mpixels/sec
89.418382 frames/sec - 67.501398 Mpixels/sec
99.902072 frames/sec - 74.534138 Mpixels/sec
103.304568 frames/sec - 77.072646 Mpixels/sec
110.054869 frames/sec - 82.108856 Mpixels/sec
104.261733 frames/sec - 77.786760 Mpixels/sec
106.986103 frames/sec - 79.819336 Mpixels/sec
110.420172 frames/sec - 82.381399 Mpixels/sec
106.993268 frames/sec - 79.824681 Mpixels/sec
101.858476 frames/sec - 75.993757 Mpixels/sec
103.608751 frames/sec - 77.299588 Mpixels/sec
98.861175 frames/sec - 73.757555 Mpixels/sec
et le iptraf-ng

Visuellement, j'ai le même rendu sur les deux machines.
En affichage distant,
- le redimensionnemet de la fenetres glxspheres est lent
- la fenetre ne quitte pas instantanement avec le clic sur la croix (quelques secondes).
En effet, ce qui rend l'utilisation distante pénible, c'est la latente entre les actions sur les menus et les réponses.
Finalement est-ce vraiment un probléme d'affichage ?
Je viens de lancer la mise à jour du serveur, il y a les choses suiantes :
Supprimé :
kernel-PAE.i686 0:3.7.2-204.fc18
Installé :
colord.i686 0:0.1.28-1.fc18 kernel-PAE.i686 0:3.7.6-201.fc18
Dépendances installées :
colord-libs.i686 0:0.1.28-1.fc18
Mis à jour :
PackageKit-Qt.i686 0:0.8.7-1.fc18 bash.i686 0:4.2.42-3.fc18
cairo.i686 0:1.12.10-2.fc18 cairo-gobject.i686 0:1.12.10-2.fc18
dump.i686 1:0.4-0.14.b44.fc18 fedora-logos.noarch 0:17.0.3-3.fc18
firefox.i686 0:18.0.2-1.fc18 flash-plugin.i386 0:11.2.202.262-release
fpaste.noarch 0:0.3.7.1-5.fc18 iputils.i686 0:20121221-2.fc18
java-1.7.0-openjdk.i686 1:1.7.0.9-2.3.5.3.fc18 kde-runtime.i686 0:4.9.5-2.fc18
kde-runtime-drkonqi.i686 0:4.9.5-2.fc18 kde-runtime-flags.noarch 0:4.9.5-2.fc18
kde-runtime-libs.i686 0:4.9.5-2.fc18 kmod.i686 0:12-1.fc18
kmod-libs.i686 0:12-1.fc18 libblkid.i686 0:2.22.2-3.fc18
libipa_hbac.i686 0:1.9.4-2.fc18 libmount.i686 0:2.22.2-3.fc18
libsss_idmap.i686 0:1.9.4-2.fc18 libuuid.i686 0:2.22.2-3.fc18
mesa-dri-drivers.i686 0:9.0.1-4.fc18 mesa-dri-filesystem.i686 0:9.0.1-4.fc18
mesa-libEGL.i686 0:9.0.1-4.fc18 mesa-libGL.i686 0:9.0.1-4.fc18
mesa-libgbm.i686 0:9.0.1-4.fc18 mesa-libglapi.i686 0:9.0.1-4.fc18
mesa-libxatracker.i686 0:9.0.1-4.fc18 orc.i686 0:0.4.16-7.fc18
rmt.i686 1:0.4-0.14.b44.fc18 selinux-policy.noarch 0:3.11.1-74.fc18
selinux-policy-devel.noarch 0:3.11.1-74.fc18 selinux-policy-doc.noarch 0:3.11.1-74.fc18
selinux-policy-targeted.noarch 0:3.11.1-74.fc18 sssd.i686 0:1.9.4-2.fc18
sssd-client.i686 0:1.9.4-2.fc18 util-linux.i686 0:2.22.2-3.fc18
xorg-x11-server-Xorg.i686 0:1.13.2-2.fc18 xorg-x11-server-common.i686 0:1.13.2-2.fc18
xulrunner.i686 0:18.0.2-1.fc18
Remplacé :
colord.i686 0:0.1.25-1.fc18 shared-color-profiles.noarch 0:0.1.6-1.fc18
un reboot pour prendre en compte le kernel.
Et nous avons :
$ LIBGL_ALWAYS_INDIRECT=y LIBGL_DEBUG=verbose glxspheres
Polygons in scene: 62464
Visual ID of window: 0xf4
Context is Indirect
OpenGL Renderer: Gallium 0.4 on NV98
329.569772 frames/sec - 344.914541 Mpixels/sec
84.855892 frames/sec - 88.806783 Mpixels/sec
79.956647 frames/sec - 73.947097 Mpixels/sec
87.745655 frames/sec - 72.908216 Mpixels/sec
93.926168 frames/sec - 78.043628 Mpixels/sec
95.985407 frames/sec - 79.754658 Mpixels/sec
85.949835 frames/sec - 66.447204 Mpixels/sec
100.612928 frames/sec - 60.472400 Mpixels/sec
121.487021 frames/sec - 72.528116 Mpixels/sec
122.451091 frames/sec - 73.103669 Mpixels/sec
128.424103 frames/sec - 76.669575 Mpixels/sec
128.340848 frames/sec - 76.619871 Mpixels/sec
127.842160 frames/sec - 76.322153 Mpixels/sec
125.582335 frames/sec - 74.973031 Mpixels/sec
127.403881 frames/sec - 76.060499 Mpixels/sec
123.594469 frames/sec - 73.786269 Mpixels/sec
120.174555 frames/sec - 71.744570 Mpixels/sec
110.174416 frames/sec - 62.692920 Mpixels/sec
119.006754 frames/sec - 54.362942 Mpixels/sec
122.673058 frames/sec - 55.919287 Mpixels/sec
137.541958 frames/sec - 62.697126 Mpixels/sec
139.533144 frames/sec - 63.604788 Mpixels/sec
avec

- Modifié
C'est que mon avis, mais si tu cherches la performances surtout avec de l'openGL:
- Passage obligé avec les pilotes nvidia
- pas de PAE ni de kernel 32bits
- virtualGL si tu veux utiliser la carte graphique du serveur distant en OpenGL
J'ai tester dxcp le truc de compression pour les flux X11, ça ne change rien. En tout cas le ssh -C fait déjà du très bon boulot.
Par contre, j'avais souvenir qu'ouvrir une session XDMCP (le protocole X11 pour l'ouverture de session à distance), c'était bien mieux en terme de ressenti. A voir si c'est toujours vrai.
- Passage obligé avec les pilotes nvidia
- pas de PAE ni de kernel 32bits
- virtualGL si tu veux utiliser la carte graphique du serveur distant en OpenGL
J'ai tester dxcp le truc de compression pour les flux X11, ça ne change rien. En tout cas le ssh -C fait déjà du très bon boulot.
Par contre, j'avais souvenir qu'ouvrir une session XDMCP (le protocole X11 pour l'ouverture de session à distance), c'était bien mieux en terme de ressenti. A voir si c'est toujours vrai.
J'avais pas forcement mesuré le niveau d'exigence.
Je partais avec l'image de nedit (vi c'est bien mais pas tous les jours) que j'utilise avec un ssh -X via internet.
J'étais d'une part à des kilometres de ce que demande l'opengl et d'autre part j'étais confiant en étant sur un réseau local.
Je viens de tester avec XDMCP.
- modification de /etc/kde/kdm/kdmrc
- lancement du client vers le serveur

Le besoin en bande passante devient critique dans ce cas.
Reste le premier point de ta suggestion.
A suivre.
Je partais avec l'image de nedit (vi c'est bien mais pas tous les jours) que j'utilise avec un ssh -X via internet.
J'étais d'une part à des kilometres de ce que demande l'opengl et d'autre part j'étais confiant en étant sur un réseau local.
Je viens de tester avec XDMCP.
- modification de /etc/kde/kdm/kdmrc
[Xdmcp]
# Whether KDM should listen to incoming XDMCP requests. Default is true
Enable=true
#Enable=false
- ajout de l'adresse IP de mon client dans /etc/kde/kdm/Xaccess- lancement du client vers le serveur
Xorg -terminate -query 192.168.0.14 :1
Cool ça marche mais c'est encore moins fluide et en plus dans ce cas iptraf me donne.
Le besoin en bande passante devient critique dans ce cas.
Reste le premier point de ta suggestion.
A suivre.
XDMCP en effet prend plus de bande passante parce que fait passer toute la session graphique et pas qu'une fenêtre. Bon pas contre si c'est encore plus "lent" c'est naze. Alors est-ce le reseau? 11Mbps/, sur de l'ethernet 100Mbps ça passe à l'aise, donc c'est bizare. Bon j'ai pas retester ça depuis un bail. J'ai remarqué que l'export display de glxgears par ex, ralentissait tout l'environnement graphique sur le client, du coup est-ce que l'environnement graphique joue un role? Je testerais bien sur un truc light genre lxde plutot qu'un machin blindé d'effets graphiques (genre Gnome3/KDE).
Sinon une autre piste serait FreeNX par ex, les avis sont pas mal concernant l'usage de session à distance avec ce truc. A voir si les appli OpenGL passent bien.
Sinon une autre piste serait FreeNX par ex, les avis sont pas mal concernant l'usage de session à distance avec ce truc. A voir si les appli OpenGL passent bien.
Pour XDMP, je suis pas surpris outre mesure. Mais pour avoir utilisé cela en entreprise (solaris/linux) il y a quelques années j'avais plutot un bon souvenir. Cela dit, il y avait une infrastruture matériel et un support système/réseau que je n'ai pas.
Si je comprends bien, tu pense que l'environnement de la machine cliente à une influence ?
J'ai effectivement identifié freenx.
-> J'ai fais un test rapide sans succés.
-> Decouverte du Truc/Tatonnement/Bricole : Je reprend proprement dés que je peut cette semaine.
-> Alors que beaucoup utlise le client de nomachine, j'ai utilisé le client disponible dans les dépôts (freenx-server-0.7.3-23.fc16.x86_64).
Je viens aussi de voir qu'il y a un fil sur le sujet dans le forum. J'arrive dés que possible.
Cependant, il semble que le paquet ne soit pas le plus "uptodate" voir le lien ci-dessous :

Si je comprends bien, tu pense que l'environnement de la machine cliente à une influence ?
J'ai effectivement identifié freenx.
-> J'ai fais un test rapide sans succés.
-> Decouverte du Truc/Tatonnement/Bricole : Je reprend proprement dés que je peut cette semaine.
-> Alors que beaucoup utlise le client de nomachine, j'ai utilisé le client disponible dans les dépôts (freenx-server-0.7.3-23.fc16.x86_64).
Je viens aussi de voir qu'il y a un fil sur le sujet dans le forum. J'arrive dés que possible.
Cependant, il semble que le paquet ne soit pas le plus "uptodate" voir le lien ci-dessous :