v_atekor : C’est très étrange que tu aies à ce niveau de paquets mals fichus…
je pensais que chez hisvin, ça ne fctionnait plus du tt
Nan,ça fonctionnait plus en root non plus.[:anti_bisounours]
M’enfin,le problème doit être aussi grotesque que mon problème d’automount dont je vous avez bourré le mou.La solution étant de …
.
.
…
.
.
.
.
…
.
d’activer la fonction mount dans le kernel [:amidamaru]
[:alala]
fakbill : ouaips, surtout qu’après vérification, ca ne se passe qu’avec NFSv4, dans les échanges initiés par le serveur lors d’un lookup/compound… Ca sent fort le pointeur foireux qui va écrire sur un champs IP…
Edit: Perdu ca fait aussi ça en v3, encore une mauvaise piste, bien que ça reste très étrange.
Edit2: Par contre ça ne le fait pas avec ftp, ni ssh… Et j’ai maintenant des perfs lamentables avec NFSv3 :heink: 
C’est où qu’il y a des marchands de cordes ?
Edit3: j’ai compris!!! 
c’est ethereal qui merdouille sur les captures de paquets avec le gb: ça va trop vite pour lui, et il en loupe pas mal (1/3 environ) et comme ce ne sont pas les mêmes sur les deux machines ça fait bizarre
Ca n’arrange pas mes pbs de perfs.
v_atekor : Le soir arrive et le lance une idée fumeuse :
Tu es sûr que tes pbs de perfs ne sont pas un artefact dû à l’outil de mesure? C’est surment idiot mais je n’ai plus en tête ta façon de mesurer les vitesses donc je posse la question dsl.
Ha oui vu comme ça ok. dsl pour le bruit. En étant 20fois au dessous du débit théorique, le pb n’est pas la méthode de mesure.
qq a essayé le patch ac ?
http://kerneltrap.org/node/view/3799
- C’est sympa que Alan soit revenu bosser sur le noyau (Il n’est jamais vraiment parti)
- Ce patch touche a l’IDE donc prudence
oui :jap:
Sinon j’essaie de voir en mono proc. Conclusion: ce n’est pas un pb de smp. Je m’en doutais, mais comme j’avais une fonction __migrate_process qui me prend un peu de temps, je préfère vérifier.
Vu de l’extérieur, le point principal semble être qu eça ne le fait qu’avec des petits fichiers. Qu’est ce qui est appelé plus souvent quand on a des petits fichiers que des gros? Réponse : Des tonnes de choses…dsl je réfléchis en tapant
YYYYYYYYYYYYYEEEEEEEEEEEEEEAAAAAAAAAAAAAHHHHHHHHHHH!
Désolé, c’est juste avant le we que j’ai eu la révélation!!!
Les perfs en monoprocs sont superbasses mais, uniformément basses (10ko/s), pas de super trous… et seulement pour les fichiers > 128ko
Réflexion… le cache NFS fait 128ko… Cheminements divers: c’est quoi qui rame vraiment sur un ordi? C’est le disque dur!!!
Oui, mais je n’inclue pas le flush dans le test, donc théoriquement tout devrait être écrit sur la vmm, en ram, comme pour NFSv3 et pas sur le disque…
Conclusion : un bug sur le flush asynchronne de NFSv4!!!
Même si je spécifie async, il me prends le temps de fsync = bug en perfs!!!
AaaaaaaaaaaHhhhhhhh c’est bon de temps en temps!!!
En tout cas merci Fakbill d’avoir suivit mes tracas!!!
ha le meilleur moment du debuggage -> quand on trouve le problême
tu vas passer un bon we comme ça =)
Wow depuis le temps que tu te prends la tete avec ca 
Tiens, tu t’etait pas mis a autre chose?
Souvant c’est en ne cherchant pas qu’on trouve
Bravo!!!
“En tout cas merci Fakbill d’avoir suivit mes tracas!!!” De rien du tout ! Je n’ai vraiment pas été d’un grand secours. Désolé en ce moment, je commence ma thèse et que je suis très occupé donc je n’ai regardé ça que de très très loin.
Est ce que c’est le code de fsync qui s’exécute quand même si tu mets async (ce serait rageant que ce soit si simple^^) ou est un bug qui fait que le code de async se traine.
Oui, le fsync s’exécute dans tous les cas, même si je suis en async… mais ce n’est pas forcément un bug: le programme de test peut être paramétré pour attendre le flush.
La ou est sans doute le bug, c’est si on demande au programme de test de ne pas inclure le flush, le débit est toujours aussi pourri. En fait, le problème n’est plus un pb de flush, mais de cache.
Le cache est bloqué à 128ko, ce qui est ridiculement bas : dès que des fichiers plus gros sont écrits ils sont forcément écrits sur le disque faute de place dans le cache. Et là, tout se passe “comme si” on avait demandé un flush, même si ce n’est pas le cas, puisqu’il faut bien plus de temps pour écrire sur le disque qu’en ram.
Par contre, je pense qu’il y a un bug sur le flush … de nfsv3, car même en demandant d’inclure le temps de flush, j’ai toujours des débits de l’ordre de 75Mo/s, ce qui veut dire que les données ne sont pas écrites sur les disques.
NFSv3 gère correctement le cache et augmente la taille du cache si des fichiers plus gros sont transférés. J’ai essayé avec des fichiers de 1Go, 2Go, et 4Go en ayant 2Go de ram, et le débit est constant pour des fichiers de moins de 1Go et décroit à partir de 2Go … un belle courbe avec une belle asymptote correspondant au débit… du disque.
cqfd.
Donc ça nous fait 2 problèmes :
1/ gérer correctement le cache de NFSv4
2/ Vérifier que le fsync de NFSv3 fonctionne normalement (c’est peut être une optimisation pour les vieux programmes écrits pour NFSv1 en 1982)
benj : tu as testé les nitro-sources ? Ça semble intéressant (mais pas forcément très stable, du moins pour les 2 avt dernières versions chez moi :/) :
[fixed]* sys-kernel/nitro-sources :
[ ~ ] 2.6.8_rc2-r3 (2.6.8.1) OVERLAY
[ ~ ] 2.6.8_rc2-r4 (2.6.8.1) OVERLAY
[ ~ ] 2.6.9_rc1-r3 (2.6.8.1) OVERLAY
[ ~I] 2.6.9_rc1-r4 (2.6.8.1) OVERLAY
[/fixed]
http://forums.gentoo.org/viewtopic.php?t=221173
[fixed]2.6.9-rc1-nitro4 “It works better if you plug it in”
Start of CK7 base
from_2.6.8.1_to_staircase8.0 | A complete scheduler policy rewrite
schedrange.diff | Infrastructure for more policies
schedbatch2.4.diff | Batch scheduling
schediso2.5.diff | Isochronous scheduling
sched-adjust-p4gain | Optimize scheduler for Pentium 4
mapped_watermark.diff | Lighter caching, very unlikely to swap
defaultcfq.diff | Enables the CFQ (completely fair queueing) I/O scheduler by default
config_hz.diff | Set the internal clock frequency
1g_lowmem_i386.diff | Allows 1G ram without enabling highmem
akpm-latency-fix.patch | Minor latency improvement hack
9000-SuSE-117-writeback-lat.patch | Writeback latency fix
cddvd-cmdfilter-drop.patch | cdrecord fix
cool-spinlocks-i386.diff | reduces kernel text size + better cache utilisation
bio_uncopy_user-mem-leak.patch | fixes memory leak
bio_uncopy_user2.diff | fixes memory leak
supermount-ng205.diff | automaticly mount removable media
fbsplash-0.9-r8-2.6.9-rc1.patch | Gensplash, a bootsplash replacement for Gentoo
make-tree_lock-an-rwlock.patch | Convert tree_lock to an rwlock, improves performance at Oracle
invalidate_inodes-speedup.patch | add seperate list for searching in the inode lists
2.6.8.1-mm2-reiser4.diff | The Reiser4 filesystem
change_reiser4_config.diff | Do not allow 4k stacks with Reiser4
s8.0_s8.1 | Update Staircase 8.0 to 8.1
mapped_watermark_fix.diff | Fix a watermark bug
sc_mw.diff | Staircase fix
1g_change_config.diff | Set default to N for 1g_lowmem patch
lenient_uw.diff | page alloc fix
s8.1_test1 | Staircase update
s8.1test1_test2 | Staircase update
s8.1_smtfix | Staircase fix
cfq_iosched_v2.patch | Completely Fair Queueing v2
vesafb-tng-0.9-rc4-r2-2.6.8.1.patch | a new and more functional version of the vesafb Linux driver
vesafb_change_config.diff | change default fb
back_journal_clean_checkpoint_list-latency-fix.patch | Minor latency improvement patch
End of CK7 base
acpi-dsdt-initrd-patch-v0.6-2.6.9.patch | Custom acpi dsdt
viafb_02.diff | VIA Framebuffer
via-v4l-1.4a-drm.patch | VIA Video4Linux
cpu-vendor-select.diff | select more than 1 CPU vendor
alsa-bk-2004-08-26.patch | new drivers for Advanced Linux Sound System
lirc-2.6.5-mm1-20040406 | Linux InfraRed Control support
use_KERNELRELEASE_more.patch | needed for the new menuconfig-NAME patch
menuconfig-NAME-v2.1-dev5.patch | Show kernel name in menuconfig
squashfs2.0-patch | SquashFS v2.0, a squashed read-only filesystem for Linux
gcloop-2.6-20040527.patch | Gentoo Compressed loopback support for 2.6
lufs-0.9.7-2.6.0-test9.patch | Linux Userland FileSystem (mount ftp connections, etc …)
omnibook-2.6.8-rc2-bk2.diff | omnibook support
config-nr-tty-devices.diff | config /dev/tty* count for a cleaner /dev
cdfs-2.6.3a.diff | exports all tracks and boot images on a CD as normal files
ipw2100-2.6.8-patch | Intel Pro Wireless 2100 drivers
acx100-2.6.8-rc2-bk2.diff | ACX WLAN drivers
acerhk.patch | Acer HotKeys support (UNTESTED!)
iteraid_1.44.diff | Giga Raid
configurable-hid-mouse-polling-2.6.9-rc1.patch | usb 500hz mouse hack
packet-2.6.8-2.patch | packet writing support for CD/DVD RW’s
journal_clean_checkpoint_list-latency-fix.patch | minor latency improvement hack
pty_write-latency-fix.patch | minor latency improvement hack
igxb-speedup.patch | speed up interrupt routine call
kallsyms-data-size-reduction–lookup-speedup.patch | speedup kallsyms
get_user_pages-latency-fix.patch | minor latency improvement hack [/fixed]
Au moment ou ls permieres nitro sources étaient sorties, j’en avait discuté avec OneOfOne, celui qui fait les love actuellement, car je trouvais qu’au niveau patch c’était très ressemblant pour voir ce que lui en pensait. Il à trouvé que c’était un pack de patches à la chie dedans. Les loves, malgré leur caractère “edge of the earth” sont franchement stables, et j’avais pas envie de tester quelque chose de brouillon. maintenant si tu me dis que c’est pas mal…
Oui, c’est ce que je pensais aussi, mais je n’ai pas testé la dernière version des nitros (juste installé les sources quoi).
Qd aux love-sources, je suis aussi d’accord que c’est du bon travail :).
Le 2.6.9-rc2 va peut être sortir aujourd’hui (car les bk ne st plus affichés).