g_synchronousclients ce n'est pas la synchro verticale (ça, c'est r_swapinterval), c'est beaucoup plus compliqué et ça n'a rien à voir.
Si ta demo saccade c'est une fatalité tant que tu enregistres sur un serveur listen - en sv_fps pas beaucoup, c'est pas joli. (listen=create server dans le menu ou /map ou /devmap dans ta console).
Tu as donc deux solutions pour enregistrer des démos de tricks chez toi :
*Fais un serveur dédié et connecte toi dessus, et là on s'en fiche un petit peu du sv_fps du serveur à moins d'être en g_sync 1.
*Lance ton serveur listen, mais avec sv_fps 125. Ca fait des démos plus lourdes, mais ça saccadera plus et tu pourras te permettre de jouer en g_sync 1 pour avoir des mouvements ultra consistants.
Pour ce qui est en lag sur le net. Tes gros mégabits ne font pas la différence 
Pour être tranquille à peu près partout je suggère ça :
*rate 25000
*snaps 30 (très important. la plupart des serveurs sont en sv_fps 25 ou 30 aujourd'hui, et donc le réglage par défaut à 20 est insuffisant et fait lagger ton Q3 quelle que soit ta connection.)
*cl_maxpackets 125
*cl_timenudge 0 ou négatif (c'est limité autour de 30/-30 en interne de toutes façons). Si tu mets du positif tu te rajoutes un peu de lag.
Ah le displayrefresh c'est de la merde avec les drivers de nos jours!
Je préfère laisser à 0 et forcer le taux de l'écran avec un autre programme comme RefreshLock ou les fonctions (cachées) des drivers nVidia, ou encore PowerStrip ; il y en a pour qui apparemment, r_displayrefresh marche sans pourrir les couleurs et les derniers se contentent de r_displayrefresh sans remarquer les couleurs pourries.
Si de toutes façons ton écran ne monte pas au delà de 60 hz, pas besoin de changer r_displayrefresh de sa valeur par défaut (0), vu que tu seras déjà à 60hz. C'est seulement quand tu veux monter plus haut qu'il faut bricoler (cf méthodes plus haut).
(femme + PC ====> 2 
)
