# systemctl stop firewalld.service
# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.0.14 port 5001 connected with 192.168.0.12 port 54795
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.3 sec  11.6 MBytes  9.49 Mbits/sec
et 
$ iperf -c 192.168.0.14
------------------------------------------------------------
Client connecting to 192.168.0.14, TCP port 5001
TCP window size: 22.9 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.12 port 54795 connected with 192.168.0.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  11.6 MBytes  9.54 Mbits/sec

Je n'avais pas le souvenir de devoir jouer avec le pare feu pour qu'iperf fonctionne.


et avec la configuration inverse : 
$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.0.12 port 5001 connected with 192.168.0.14 port 37131
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-11.1 sec  19.4 MBytes  14.7 Mbits/sec
# iperf -c 192.168.0.12
------------------------------------------------------------
Client connecting to 192.168.0.12, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.14 port 37131 connected with 192.168.0.12 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.6 sec  19.4 MBytes  15.3 Mbits/sec
Maintenant le test avec la compression sur ssh, 
$  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.
23747 frames in 5.0 seconds = 4730.084 FPS
3506 frames in 5.3 seconds = 660.639 FPS
3637 frames in 5.6 seconds = 651.917 FPS
3897 frames in 5.7 seconds = 688.031 FPS
3896 frames in 5.6 seconds = 692.987 FPS
3637 frames in 5.7 seconds = 636.846 FPS
3768 frames in 5.1 seconds = 739.826 FPS
3246 frames in 5.1 seconds = 639.735 FPS
- l'affichage de l'engrenage est pas top du tout.
- l'utilisation reseau et de l'ordre de 10-50kio/s selon la direction.

Je suis un peu déçu du résultat.
T'es deçu d'avoir ~660FPS sur glxgears (qui n'est pas un outil de bench) en utilisant les pilotes libres?? Tu vises combien?

sinon 15Mbits/sec c'est peu, mais si tu constates une utilisation de 10 à 50ko/s lors de l'export display ça doit passer. Tu peux aussi jouer avec ping pour voir, en dehors du débit, la qualité de la connexion: 
ping -f ip_machie_distante -s taille_paquet
en testant différentes tailles de paquets (1500 max), et voir le % de paquets perdus.

ps: oui pour iperf il faut autoriser le port dans le parefeu (ou le couper temporairement comme tu as fais), ya pas trop le choix.
J'ai mal formulé les choses.
Effectivement, j'ai un en viron 660FPS avec glxgears mais la fluidité de l'affichage n'est pas celle correspondante.
comment tu mesurais tes 10 à 50kio/s? Parce que chez, glxgears en export display, c'est 9Mb/s avec des pointe à 15Mb/s!
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)
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.
toujours avec un ssh -XC
$  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

Alors du coup j'ai refait mes mesures finalement ça colle avec ce que tu as:
(j'ai 10x de FPS mais je suis avec les pilotes proprio c'est normal).

essaye avec glxspheres, qui est un peu mieux foutu que glxgears pour tester tout ça.
Première étape sur les deux postes
# 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

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.
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 
[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.
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 :

https://bugzilla.redhat.com/show_bug.cgi?id=886198