Conversation
precedente ou
suivante
Page: 2 sur 4
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
panthere noire
mhmm déjà si tu prouvai donner les détail de ta config matériel. +ta distrib + gnome ou kde autre ?
Ensuite que donne un cat /boot/config-`uname -r` |grep 1000 et uname -a et colle aussi un ps aux
net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3
Ensuite que donne un cat /boot/config-`uname -r` |grep 1000 et uname -a et colle aussi un ps aux
net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3
Poste le Monday 14 July 2008 15:02:33
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
Mes problèmes sont indépendant du matos, car il sont commun à toute les config (du p3 500MHz que j'ai tester, au AMD Phenom et au Core2duo), et aussi sur toute les distro de moins d'un ans (gentoo netinstall, debian, suse, redhat, ...), j'ai meme tester les version non stable de xorg, et kde4, meme résultat. J'ai aussi tester sur fluxbox, sur kde4, sur ces 2 environnement je n'avais presque rien de lancer.
Mon mon pc principal sont les quel je fait les testes avant de les confirmer sur des autres pc:
AMD X2 BE-2400 @ 2.3Ghz en ondemand soit 1GHz en idle
Gentoo netinstall elle doit dater de 1 mois sur architecture amd64.
Kde 3.5 (Qt 4.3.3)
gentoo-sources fait main
Je pense que tu veux ça:
Ca:
Et le ps aux, tout les pc on été nettoyé coté service, et sont trés différent:
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Mon mon pc principal sont les quel je fait les testes avant de les confirmer sur des autres pc:
AMD X2 BE-2400 @ 2.3Ghz en ondemand soit 1GHz en idle
Gentoo netinstall elle doit dater de 1 mois sur architecture amd64.
Kde 3.5 (Qt 4.3.3)
gentoo-sources fait main
Je pense que tu veux ça:
# CONFIG_HZ_1000 is not set CONFIG_BLK_DEV_RZ1000=m CONFIG_PATA_RZ1000=m # CONFIG_NET_SB1000 is not set CONFIG_NETDEV_1000=y CONFIG_E1000=y # CONFIG_E1000_NAPI is not set # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set CONFIG_E1000E=y # CONFIG_IP1000 is not set # CONFIG_NETDEV_10000 is not set
Ca:
Linux bureau 2.6.25-gentoo-r6 #1 SMP Thu Mar 13 07:36:11 CET 2008 x86_64 AMD Athlon(tm) X2 Dual Core Processor BE-2400 AuthenticAMD GNU/Linux
Et le ps aux, tout les pc on été nettoyé coté service, et sont trés différent:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 804 316 ? Ss Jul13 0:00 init [3] root 2 0.0 0.0 0 0 ? S< Jul13 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S< Jul13 0:00 [migration/0] root 4 0.0 0.0 0 0 ? S< Jul13 0:00 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S< Jul13 0:00 [migration/1] root 6 0.0 0.0 0 0 ? S< Jul13 0:01 [ksoftirqd/1] root 7 0.0 0.0 0 0 ? S< Jul13 0:00 [events/0] root 8 0.0 0.0 0 0 ? S< Jul13 0:00 [events/1] root 9 0.0 0.0 0 0 ? S< Jul13 0:00 [khelper] root 71 0.0 0.0 0 0 ? S< Jul13 0:00 [kblockd/0] root 72 0.0 0.0 0 0 ? S< Jul13 0:00 [kblockd/1] root 76 0.0 0.0 0 0 ? S< Jul13 0:00 [kacpid] root 77 0.0 0.0 0 0 ? S< Jul13 0:00 [kacpi_notify] root 187 0.0 0.0 0 0 ? S< Jul13 0:00 [ksuspend_usbd] root 193 0.0 0.0 0 0 ? S< Jul13 0:00 [khubd] root 196 0.0 0.0 0 0 ? S< Jul13 0:00 [kseriod] root 216 0.0 0.0 0 0 ? S< Jul13 0:00 [kondemand/0] root 217 0.0 0.0 0 0 ? S< Jul13 0:00 [kondemand/1] root 245 0.0 0.0 0 0 ? S Jul13 0:00 [pdflush] root 246 0.0 0.0 0 0 ? S Jul13 0:01 [pdflush] root 247 0.0 0.0 0 0 ? S< Jul13 0:01 [kswapd0] root 248 0.0 0.0 0 0 ? S< Jul13 0:00 [aio/0] root 249 0.0 0.0 0 0 ? S< Jul13 0:00 [aio/1] root 250 0.0 0.0 0 0 ? S< Jul13 0:00 [cifsoplockd] root 251 0.0 0.0 0 0 ? S< Jul13 0:00 [cifsdnotifyd] root 253 0.0 0.0 0 0 ? S< Jul13 0:00 [aufsd] root 254 0.0 0.0 0 0 ? S< Jul13 0:00 [aufsd] root 255 0.0 0.0 0 0 ? S< Jul13 0:00 [aufsd] root 256 0.0 0.0 0 0 ? S< Jul13 0:00 [aufsd] root 427 0.0 0.0 0 0 ? S< Jul13 0:00 [kpsmoused] root 489 0.0 0.0 0 0 ? S< Jul13 0:00 [rpciod/0] root 490 0.0 0.0 0 0 ? S< Jul13 0:11 [rpciod/1] root 491 0.0 0.0 0 0 ? S< Jul13 0:00 [krxrpcd/0] root 492 0.0 0.0 0 0 ? S< Jul13 0:00 [krxrpcd/1] bin 1130 0.0 0.0 3696 392 ? Ss Jul13 0:00 /sbin/portmap root 1132 0.0 0.0 3720 620 ? Ss Jul13 0:00 /sbin/rpc.statd root 1136 0.0 0.0 0 0 ? S Jul13 0:00 [lockd] root 1237 0.0 0.0 12824 1288 ? S<s Jul13 0:00 /sbin/udevd --daemon root 2208 0.0 0.0 0 0 ? S< Jul13 0:00 [ata/0] root 2209 0.0 0.0 0 0 ? S< Jul13 0:00 [ata/1] root 2210 0.0 0.0 0 0 ? S< Jul13 0:00 [ata_aux] root 2239 0.0 0.0 0 0 ? S< Jul13 0:00 [scsi_eh_0] root 2240 0.0 0.0 0 0 ? S< Jul13 0:00 [scsi_eh_1] root 2243 0.0 0.0 0 0 ? S< Jul13 0:00 [scsi_eh_2] root 2244 0.0 0.0 0 0 ? S< Jul13 0:00 [scsi_eh_3] 101 3395 0.0 0.0 14676 936 ? Ss Jul13 0:00 /usr/bin/dbus-daemon --system root 3579 0.0 0.0 19612 652 ? Ss Jul13 0:00 /usr/kde/3.5/bin/kdm root 3613 2.0 4.7 940744 97020 tty7 SLs+ Jul13 42:45 /usr/bin/X -br -nolisten tcp +extension DOUBLE-BUFFER -br -nolisten tcp +extension DOUBLE-BUFFER :0 vt7 -auth /var/run/xauth/A:0-sIAYMm root 3734 0.0 0.0 28016 1060 ? S Jul13 0:00 -:0 root 4539 0.0 0.0 6356 404 ? Ss Jul13 0:01 /usr/sbin/gpm -m /dev/input/mice -t ps2 102 4583 0.0 0.1 25912 3196 ? Ss Jul13 0:00 /usr/sbin/hald --use-syslog --verbose=no root 4611 0.0 0.0 15484 1116 ? S Jul13 0:00 hald-runner root 4735 0.0 0.1 19812 3940 ? Ss Jul13 0:15 /bin/bash /usr/sbin/fancontrol /etc/fancontrol 102 4922 0.0 0.0 16496 948 ? S Jul13 0:00 hald-addon-keyboard: listening on /dev/input/event0 102 4923 0.0 0.0 16496 952 ? S Jul13 0:00 hald-addon-keyboard: listening on /dev/input/event1 102 4924 0.0 0.0 16496 952 ? R Jul13 0:00 hald-addon-keyboard: listening on /dev/input/event2 root 4926 0.0 0.0 17596 1140 ? S Jul13 0:00 /usr/libexec/hald-addon-cpufreq 102 4927 0.0 0.0 16496 944 ? S Jul13 0:00 hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event nobody 4980 0.0 0.0 10004 836 ? Ss Jul13 0:00 /sbin/rpc.statd --no-notify root 4981 0.0 0.0 16356 536 ? Ss Jul13 0:00 /usr/sbin/rpc.idmapd root 5004 0.0 0.0 0 0 ? S< Jul13 0:13 [cifsd] user 5015 0.0 0.0 9232 1344 ? Ss Jul13 0:00 /bin/sh /usr/kde/3.5/bin/startkde distcc 5028 0.0 0.0 14624 288 ? SNs Jul13 0:00 /usr/bin/distccd --pid-file /var/run/distccd/distccd.pid -N 19 --user distcc --user distcc --jobs 2 --port 3632 --log-level warning --allow 192.168.0.0/16 distcc 5029 0.0 0.0 14624 240 ? SN Jul13 0:00 /usr/bin/distccd --pid-file /var/run/distccd/distccd.pid -N 19 --user distcc --user distcc --jobs 2 --port 3632 --log-level warning --allow 192.168.0.0/16 distcc 5039 0.0 0.0 14624 240 ? SN Jul13 0:00 /usr/bin/distccd --pid-file /var/run/distccd/distccd.pid -N 19 --user distcc --user distcc --jobs 2 --port 3632 --log-level warning --allow 192.168.0.0/16 root 5077 0.0 0.0 1436 152 ? S Jul13 0:00 /opt/vmware/workstation/bin/vmnet-bridge -d /var/run/vmnet-bridge-0.pid /dev/vmnet0 eth0 user 5131 0.0 0.0 25668 720 ? S Jul13 0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session user 5132 0.0 0.0 14676 844 ? Ss Jul13 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session root 5151 0.0 0.0 3556 152 ? S Jul13 0:00 start_kdeinit --new-startup +kcminit_startup user 5152 0.0 0.3 110108 7260 ? Ss Jul13 0:02 kdeinit Running... user 5155 0.0 0.1 111972 3732 ? S Jul13 0:08 dcopserver [kdeinit] --nosid user 5157 0.0 0.3 115900 7272 ? S Jul13 0:02 klauncher [kdeinit] --new-startup user 5159 0.0 1.1 257472 23820 ? S Jul13 0:40 kded [kdeinit] --new-startup user 5164 0.0 0.0 3692 400 ? S Jul13 0:00 kwrapper ksmserver user 5166 0.0 0.4 124504 9604 ? S Jul13 0:00 ksmserver [kdeinit] user 5167 0.0 0.6 133072 13672 ? S Jul13 0:27 kwin [kdeinit] -session 10c3ea7265000121000894800000052800000_1217 user 5169 0.0 1.2 186580 24752 ? S Jul13 0:30 kdesktop [kdeinit] user 5171 0.0 1.0 165344 22152 ? S Jul13 1:32 kicker [kdeinit] user 5173 0.0 0.0 21724 1620 ? S Jul13 0:08 ksysguardd user 5179 2.3 0.5 78680 11052 ? RL Jul13 48:18 /usr/kde/3.5/bin/artsd -F 10 -S 4096 -s 60 -m artsmessage -c drkonqi -l 3 -f user 5181 0.0 0.4 126496 8936 ? S Jul13 0:01 kaccess [kdeinit] user 5184 0.0 0.6 134768 14184 ? S Jul13 0:00 kmix [kdeinit] -session 10c3ea7265000119419980400000054730008_1217 user 5185 0.0 0.7 107744 15684 ? S Jul13 1:42 knetstats -session 10c3ea7265000120569970300000059360061_1217409072_317095 user 5187 0.0 0.6 112408 12392 ? S Jul13 0:25 ksensors -session 10c3ea7265000121000901500000052800011_1217409072_316780 user 5191 0.0 1.5 181048 31652 ? S Jul13 0:15 akregator -session 10c3ea7265000121343912700000055620893_1217409072_316766 user 5194 0.0 0.5 171552 12080 ? S Jul13 0:02 knotify [kdeinit] user 5195 0.0 0.9 209936 19756 ? S Jul13 0:01 kalarm -session 10c3ea7265000121394700500000052680009_1217409072_316909 user 5206 0.0 0.3 126444 8228 ? S Jul13 0:01 kalarmd --autostart user 5209 0.0 0.5 138944 11700 ? S Jul13 0:00 kpowersave [kdeinit] user 5211 0.0 0.5 128956 11636 ? S Jul13 0:05 klipper [kdeinit] root 5244 0.0 0.0 5800 692 tty1 Ss+ Jul13 0:00 /sbin/agetty 38400 tty1 linux root 5245 0.0 0.0 5800 692 tty2 Ss+ Jul13 0:00 /sbin/agetty 38400 tty2 linux root 5246 0.0 0.0 5800 696 tty3 Ss+ Jul13 0:00 /sbin/agetty 38400 tty3 linux root 5247 0.0 0.0 5800 700 tty4 Ss+ Jul13 0:00 /sbin/agetty 38400 tty4 linux root 5248 0.0 0.0 5800 700 tty5 Ss+ Jul13 0:00 /sbin/agetty 38400 tty5 linux root 5249 0.0 0.0 5800 692 tty6 Ss+ Jul13 0:00 /sbin/agetty 38400 tty6 linux user 5274 0.8 1.2 145880 26720 ? S Jul13 17:20 konsole [kdeinit] -caption=ssh amber -icon konsole -miniicon konso user 5275 0.0 0.1 17464 2076 pts/1 Ss+ Jul13 0:37 ssh root@192.168.0.10 user 8334 0.0 0.1 90804 2620 ? S Jul13 0:00 /usr/kde/3.5/bin/kdesud user 8354 0.0 0.6 128880 12488 ? S Jul13 0:03 kio_uiserver [kdeinit] user 8858 0.0 2.6 306076 54788 ? S Jul13 0:45 kopete -caption Kopete -icon kopete -miniicon kopete user 19237 0.0 0.0 1664 244 ? Ss 12:26 0:00 ssh-agent user 19258 0.0 0.0 1664 244 ? Ss 12:28 0:00 ssh-agent user 19265 0.0 0.0 1664 244 ? Ss 12:28 0:00 ssh-agent user 19271 0.0 0.0 1664 244 ? Ss 12:28 0:00 ssh-agent user 19277 0.0 0.0 1664 244 ? Ss 12:29 0:00 ssh-agent user 19307 0.0 0.0 1664 244 ? Ss 12:31 0:00 ssh-agent user 19312 0.0 0.0 1664 244 ? Ss 12:31 0:00 ssh-agent user 19318 0.0 0.0 1664 248 ? Ss 12:32 0:00 ssh-agent user 19380 0.0 0.0 1664 244 ? Ss 12:39 0:00 ssh-agent user 19385 0.0 0.0 1664 244 ? Ss 12:39 0:00 ssh-agent root 21043 0.0 0.4 76892 9056 ? S 15:05 0:00 /usr/kde/3.5/bin/artsd -F 10 -S 4096 -s 60 -m artsmessage -l 3 -f user 24989 1.3 1.2 144612 25356 ? R 20:20 1:33 konsole [kdeinit] -caption=ssh amber -icon konsole -miniicon konso user 24990 0.3 0.0 17492 2036 pts/4 Ss+ 20:20 0:23 ssh root@192.168.0.10 user 25752 0.1 1.3 185268 26892 ? S 21:54 0:02 konqueror [kdeinit] -mimetype inode/directory file:///mnt/ user 25846 0.0 0.4 117000 9944 ? S 22:00 0:00 kdialogd3 user 25917 5.5 2.7 536676 56584 ? Sl 22:04 0:29 kaffeine /mnt/disk2/clip/clip/Zaho - Cest Chelou MC4.mpg user 25919 0.0 0.2 113592 5940 ? S 22:04 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so user 25934 0.0 0.0 9200 1280 ? S 22:05 0:00 /bin/bash /usr/local/bin/firefox user 25942 0.0 0.0 8940 1256 ? S 22:05 0:00 /bin/bash /usr/bin/kgtk2-wrapper /usr/bin/firefox user 25944 0.0 0.1 87112 3180 ? S 22:05 0:00 /bin/bash /usr/libexec/mozilla-launcher user 25953 4.0 4.0 490968 84312 ? Sl 22:05 0:19 /usr/lib64/mozilla-firefox/firefox-bin user 25986 0.0 0.0 9364 1528 ? S 22:05 0:00 /bin/bash /usr/libexec/mozilla-launcher user 25996 0.8 2.3 443288 49044 ? Sl 22:05 0:04 /usr/lib64/mozilla-thunderbird/thunderbird-bin user 26062 0.0 0.0 17744 1836 pts/2 Ss 22:11 0:00 /bin/bash root 26067 0.0 0.0 17484 1896 pts/2 S 22:11 0:00 bash user 26087 0.0 0.2 113592 5932 ? S 22:12 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so user 26088 0.0 0.2 113592 5932 ? S 22:12 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so user 26089 0.0 0.2 113592 5940 ? S 22:12 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so root 26093 0.0 0.0 776 220 ? S 22:13 0:00 sleep 10 root 26094 0.0 0.0 14616 952 pts/2 R+ 22:13 0:00 ps aux
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Poste le Monday 14 July 2008 22:14:59
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
panthere noire
Déja je précise que je ne connait pas geento.
A première vue tu plusieurs foit les même truc lancer:
par exemple:
pareil pour firefox
Le simple faite de lancer plusieurs foit les applications va manger plus de ressources. As-tu essayer de faire tes test en simple user ?
car un linux charger aux minimum sa tape dans les 5-8 M , de no jour environ 32-40M sans x mai bon.
Apparemment tu lit tes video sur un support annexe, sa aussi sa manges des ressources si tu veux une lecture sans problème tu peux la copier en ram si tu en as suffisamment. ensuite si tu as compiler tes logiciel a la main, es-tu sure d'avoir passer les bon paramètre a gcc.
ensuite il faut comprendre une chose, linux c'est du vrai multitache.
pour schématiser en gros. windows va executer un bloc d'instruction qui peux contenir plusieurs instruction, sous linux sa sera chaqu'un son tour.
ce qui revient a dire que si dans le bloc d'instruction sa plante, sa te gèle le pc ou sa te le redémarre ect. Sous linux c'est donc peux probable que sa arrive.
Ensuite un kernel 2.6.25 a pas mal d'option que tu ne doit pas utiliser genre la gestion des ressourcer par utilisateur/groupe
je doute aussi que sos windows tu est garder un par feux. donc sous linux il te faudrait supprimer netfilter,iptables du noyaux a tes risque et perile hein. donc de ce coter la il te faux encore creuser
tu peux aussi avoir un module charger en dure qui gène la bonne exécution des reste des application genre l'usb qui a une priorité élevée.
Enfin linux offre aussi plus de possibilité que windows donc c'est aussi logique que si tu garde tout ben que sa soie un peux lourd, car la je peux te dire que c'est pas optimiser du tout et malgré ce que tu dit kde/gnome son a proscrire car très lourd. par exemple kde pré-charge les lib et permet meme de prechager une instance (ou plus) de konqueror ect. bref tu pas commit forcement les même fautes sur chaque machine mai sa peux suffire a ce que sa coince.
enfin linux exécute une application sur 1 core et pas forcement sur les 2. Moi je permet, pour la compilation du noyaux de faire sa sure les 2
Mai bon comme je connait pas gento je ne peux pas le garentire.
net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3
A première vue tu plusieurs foit les même truc lancer:
par exemple:
user 19237 0.0 0.0 1664 244 ? Ss 12:26 0:00 ssh-agent user 19258 0.0 0.0 1664 244 ? Ss 12:28 0:00 ssh-agent user 19265 0.0 0.0 1664 244 ? Ss 12:28 0:00 ssh-agent user 19271 0.0 0.0 1664 244 ? Ss 12:28 0:00 ssh-agent user 19277 0.0 0.0 1664 244 ? Ss 12:29 0:00 ssh-agent user 19307 0.0 0.0 1664 244 ? Ss 12:31 0:00 ssh-agent user 19312 0.0 0.0 1664 244 ? Ss 12:31 0:00 ssh-agent user 19318 0.0 0.0 1664 248 ? Ss 12:32 0:00 ssh-agent user 19380 0.0 0.0 1664 244 ? Ss 12:39 0:00 ssh-agent user 19385 0.0 0.0 1664 244 ? Ss 12:39 0:00 ssh-agent
user 26087 0.0 0.2 113592 5932 ? S 22:12 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so user 26088 0.0 0.2 113592 5932 ? S 22:12 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so user 26089 0.0 0.2 113592 5940 ? S 22:12 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so user 25919 0.0 0.2 113592 5940 ? S 22:04 0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
pareil pour firefox
Le simple faite de lancer plusieurs foit les applications va manger plus de ressources. As-tu essayer de faire tes test en simple user ?
car un linux charger aux minimum sa tape dans les 5-8 M , de no jour environ 32-40M sans x mai bon.
Apparemment tu lit tes video sur un support annexe, sa aussi sa manges des ressources si tu veux une lecture sans problème tu peux la copier en ram si tu en as suffisamment. ensuite si tu as compiler tes logiciel a la main, es-tu sure d'avoir passer les bon paramètre a gcc.
ensuite il faut comprendre une chose, linux c'est du vrai multitache.
pour schématiser en gros. windows va executer un bloc d'instruction qui peux contenir plusieurs instruction, sous linux sa sera chaqu'un son tour.
ce qui revient a dire que si dans le bloc d'instruction sa plante, sa te gèle le pc ou sa te le redémarre ect. Sous linux c'est donc peux probable que sa arrive.
Ensuite un kernel 2.6.25 a pas mal d'option que tu ne doit pas utiliser genre la gestion des ressourcer par utilisateur/groupe
je doute aussi que sos windows tu est garder un par feux. donc sous linux il te faudrait supprimer netfilter,iptables du noyaux a tes risque et perile hein. donc de ce coter la il te faux encore creuser
tu peux aussi avoir un module charger en dure qui gène la bonne exécution des reste des application genre l'usb qui a une priorité élevée.
Enfin linux offre aussi plus de possibilité que windows donc c'est aussi logique que si tu garde tout ben que sa soie un peux lourd, car la je peux te dire que c'est pas optimiser du tout et malgré ce que tu dit kde/gnome son a proscrire car très lourd. par exemple kde pré-charge les lib et permet meme de prechager une instance (ou plus) de konqueror ect. bref tu pas commit forcement les même fautes sur chaque machine mai sa peux suffire a ce que sa coince.
enfin linux exécute une application sur 1 core et pas forcement sur les 2. Moi je permet, pour la compilation du noyaux de faire sa sure les 2
Mai bon comme je connait pas gento je ne peux pas le garentire.
net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3
Poste le Tuesday 15 July 2008 00:46:36
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
Comme préciser plus haut j'ai fait les testes sur des config très différente avec le même résulta, avec une fluxbox et 46 processus de lancer (et aucun en double, j'avais regarder par ps aux) même probléme.
Sous windows on peu lancer plusieurs applications sans aucune différence tant qu'on assez de ram, idem sous linux apparemment.
Je croi que kaffeine met en cache un peu à l'avance les fichier video.
Pour gcc:
CFLAGS="-O2 -pipe -march=k8 -msse3"
Que du safe car il me faut un pc très stable.
Group CPU Shuduler activé mais je fait rien pour le gérer je laisse linux faire si il le fait.
Sous windows j'avais garder un par feu, j'ai plus windows chez moi sauf en pc virtuel (depuis 2 jours).
J'ai désativé le parefeu sous presque tout mes distro, (netfilter dans le noyau et iptables).
J'ai mit en dur que ce qui me sert et j'ai pas toucher au priorité (cf windows marche trés bien en desktop si on gére pas le priorité)
Je répéte, j'ai tester avec kde3.5, kde4, gnome, fluxbox et en console pur.
J'utilise qu'un seul coeur en général sauf pour les compilations.
J'ai pris que windows xp mais par contre j'ai tester différente distribution de linux, avec des gammes de logiciels divers (j'ai fait des testes sur des serveurs, que le IO car pas d'interface, sur des desktop léger, twm + xterm, flux, sur des desktop lourd kde3.5, kde4, gnome).
Cette linux gérer plus de truc mais les gères mieux, ça ce vois car sur les application n'utilisant que cpu et ram j'ai un gain comparer à windows.
Et ce n'est pas un probléme de lenteur car si non ce serai d'un ralentissement général que je me plaindrai, ici le probléme c'est que les IO prenne du temps cpu (réellement) et pas sous windows (me dite pas que c'est parce qu'on voit rien, teste à l'appui en début de topic, hardware, et pas de ralentissement de bench cpu en priorité faible contrairement à linux).
Et faire rammer un lecteur video en fessant défiler la scrollbar de sont navigateur c'est limite, et idem pour l'affichage de longue liste de texte comme dans mon application, c'est temps réel sous windows et sous linux ça rame...
Je suis pas la pour blamer linux, je suis la pour faire en sorte de trouver une solution
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Sous windows on peu lancer plusieurs applications sans aucune différence tant qu'on assez de ram, idem sous linux apparemment.
Je croi que kaffeine met en cache un peu à l'avance les fichier video.
Pour gcc:
CFLAGS="-O2 -pipe -march=k8 -msse3"
Que du safe car il me faut un pc très stable.
Group CPU Shuduler activé mais je fait rien pour le gérer je laisse linux faire si il le fait.
Sous windows j'avais garder un par feu, j'ai plus windows chez moi sauf en pc virtuel (depuis 2 jours).
J'ai désativé le parefeu sous presque tout mes distro, (netfilter dans le noyau et iptables).
J'ai mit en dur que ce qui me sert et j'ai pas toucher au priorité (cf windows marche trés bien en desktop si on gére pas le priorité)
Je répéte, j'ai tester avec kde3.5, kde4, gnome, fluxbox et en console pur.
J'utilise qu'un seul coeur en général sauf pour les compilations.
J'ai pris que windows xp mais par contre j'ai tester différente distribution de linux, avec des gammes de logiciels divers (j'ai fait des testes sur des serveurs, que le IO car pas d'interface, sur des desktop léger, twm + xterm, flux, sur des desktop lourd kde3.5, kde4, gnome).
Cette linux gérer plus de truc mais les gères mieux, ça ce vois car sur les application n'utilisant que cpu et ram j'ai un gain comparer à windows.
Et ce n'est pas un probléme de lenteur car si non ce serai d'un ralentissement général que je me plaindrai, ici le probléme c'est que les IO prenne du temps cpu (réellement) et pas sous windows (me dite pas que c'est parce qu'on voit rien, teste à l'appui en début de topic, hardware, et pas de ralentissement de bench cpu en priorité faible contrairement à linux).
Et faire rammer un lecteur video en fessant défiler la scrollbar de sont navigateur c'est limite, et idem pour l'affichage de longue liste de texte comme dans mon application, c'est temps réel sous windows et sous linux ça rame...
Je suis pas la pour blamer linux, je suis la pour faire en sorte de trouver une solution
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Poste le Tuesday 15 July 2008 10:05:41
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
panthere noire
Citation
alpha_one_x86
Pour gcc:
CFLAGS="-O2 -pipe -march=k8 -msse3"
Que du safe car il me faut un pc très stable.
j'ai pas installer le man de gcc donc je peux pas te dire si c est sufisant.
Citation
Group CPU Shuduler activé mais je fait rien pour
le gérer je laisse linux faire si il le fait.
Sous windows j'avais garder un par feu, j'ai plus
windows chez moi sauf en pc virtuel (depuis 2
jours).
J'ai désativé le parefeu sous presque tout mes
distro, (netfilter dans le noyau et iptables).
J'ai mit en dur que ce qui me sert et j'ai pas
toucher au priorité (cf windows marche trés bien
en desktop si on gére pas le priorité)
Je répéte, j'ai tester avec kde3.5, kde4, gnome,
fluxbox et en console pur.
J'utilise qu'un seul coeur en général sauf pour
les compilations.
tu veux dire les 2 coeur en 1 seul ou 1 séparement ??
certe.Citation
Et ce n'est pas un probléme de lenteur car si non
ce serai d'un ralentissement général que je me
plaindrai, ici le probléme c'est que les IO prenne
du temps cpu (réellement) et pas sous windows (me
dite pas que c'est parce qu'on voit rien, teste à
l'appui en début de topic, hardware, et pas de
ralentissement de bench cpu en priorité faible
contrairement à linux).
Citation
Et faire rammer un lecteur video en fessant
défiler la scrollbar de sont navigateur c'est
limite, et idem pour l'affichage de longue liste
de texte comme dans mon application, c'est temps
réel sous windows et sous linux ça rame...
ce que tu dit la c'est typique d'une carte video qui n'a pas les driver proprio ou encore que c est mal configurer. enfin si ta video c est du flash ben sa pue et sa marche pas toujours très bien. donc rien a voir avec les i/o
si c est un video :
Pour cree un lecteur virtuel de 200 mg adapte sa a ta video et place y le fichier.
mount -t tmpfs -o size=200m,nr_inodes=10k,mode=0700 tmpfs /dd_virtuel
pas de problème ou presque :-DCitation
Je suis pas la pour blamer linux, je suis la pour
faire en sorte de trouver une solution
Besoin d'aide:
comme on ne c'est pas exactement ce que tu as tester et ou sa te gène on peux difficilement t'aider, hormis le fait que sa mange du cpu. ceci dit la charge est de combien sans comparer avec windows et qu'elle son les valeurs et ou prend tu les mesure. ?
net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3
Poste le Tuesday 15 July 2008 11:26:18
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
panthere noire
erf laisse tomber la denière phrase je suis planter avec le copier coller.
comme on ne c'est pas exactement ce que tu as tester et ou sa te gène on peux difficilement t'aider, hormis le fait que sa mange du cpu. ceci dit la charge est de combien sans comparer avec windows et qu'elle son les valeurs et ou prend tu les mesure. ?
on peux pas éditer les poste ici c'est pénible :-(
net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3
comme on ne c'est pas exactement ce que tu as tester et ou sa te gène on peux difficilement t'aider, hormis le fait que sa mange du cpu. ceci dit la charge est de combien sans comparer avec windows et qu'elle son les valeurs et ou prend tu les mesure. ?
on peux pas éditer les poste ici c'est pénible :-(
net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3
Poste le Tuesday 15 July 2008 11:39:26
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
diancech
Pour les CFLAGS a priori pas de soucis (à moins que k8 ne soit pas la bonne arch mais je pense que c'est bon ;-) ).
Pour le problème de vidéo qui saute effectivement, cela peux venir d'un soucis de configuration de X (à vérifier qu'il n'y a rien de louche dans /var/log/Xorg.0.log), moi j'ai effectivement un soucis vidéo, pas quand je joue avec l'ascenseur d'une fenêtre mais quand je déplace un xterm par exemple (cela fait sauter la vidéo), par contre cela ne fait ça qu'avec mplayer, je ne me suis pas pencher sur ce soucis étant donné que j'utilise VLC la plupart du temps et je n'ai pas ce soucis avec ce dernier.
--------------------------------------------------------------------------------------------------------------------------------------------------
Exige beaucoup de toi-même et attends peu des autres. Ainsi beaucoup d'ennuis te seront épargnés. Confucius
Pour le problème de vidéo qui saute effectivement, cela peux venir d'un soucis de configuration de X (à vérifier qu'il n'y a rien de louche dans /var/log/Xorg.0.log), moi j'ai effectivement un soucis vidéo, pas quand je joue avec l'ascenseur d'une fenêtre mais quand je déplace un xterm par exemple (cela fait sauter la vidéo), par contre cela ne fait ça qu'avec mplayer, je ne me suis pas pencher sur ce soucis étant donné que j'utilise VLC la plupart du temps et je n'ai pas ce soucis avec ce dernier.
--------------------------------------------------------------------------------------------------------------------------------------------------
Exige beaucoup de toi-même et attends peu des autres. Ainsi beaucoup d'ennuis te seront épargnés. Confucius
Poste le Tuesday 15 July 2008 13:11:09
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
AlSim
Pas l'endroit idéal pour ce genre de problème... [www.kernel.org]Citation
alpha_one_x86
Je suis pas la pour blamer linux, je suis la pour faire en sorte de trouver une solution
[catwell.info]
Poste le Tuesday 15 July 2008 14:41:58
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
Je commence à me répété, cf début de post, mesure physique de l'utilisation du cpu et logiciel, et les mesures s'accorde.
Non, X est bien config, j'ai tester différente option, mais j'ai bien les drivers proprio, et il marche bien:
Lecture de video sous ram disk: ok, juste les temps cpu de décompression mais c'est pas gênant et c'est normal.
J'ai tester avec le défilement d'une page web sous firefox, et avec mplayer et kaffeine. Si vlc à trouvé le moyen de désyncroniser sont affichage pour pas que les éléments graphique font ramer ces élément graphique telque ça video, il faut l'appliquer en masse en l'intégrant dans X11 pour qu'aucun éléments puisse en faire ramer un autre.
Aprés je sais pas ce que vous en penser, mais techniquement les problèmes exposer içi sont les seul défaut qui me gène sous linux. Et c'est les seul truc qui fait que windows n'est pas complément écraser par linux.
Donc pour résumer avec X11 (sous Qt, gtk, ou autre) les items ne sont pas indépendant et peuvent ce faire ramer mutuellement, l'affichage n'est pas temps réel et ce resent surtout lors de nombreux éléments.
Les IO (réseau ou hdd) sous linux prenne du temps cpu qui ne peu pas être utilisé par des applications. Sous windows ce n'est pas le cas teste à l'appui.
Ca ne sert à rien de regarder coté matos et drivers car j'ai tester cela sur plein de config/distrib différente avec le même résultat, je parle de l'interface que quand le pc à une prise en charge complète de la carte graphique.
Je m'assure toujours pour toute ce que j'ai dit que les testes ce fond dans les bonne condition, drivers et matos 100% reconnu et pris en charge.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Non, X est bien config, j'ai tester différente option, mais j'ai bien les drivers proprio, et il marche bien:
name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 ... OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8600 GT/PCI/SSE2 OpenGL version string: 2.1.2 NVIDIA 169.09 ...Et si no je pourrai pas jouer à Quake4, doom3, ut2004, et d'autre jeux sous wine ou en natif à fond (3360x1500 en AA4).
Lecture de video sous ram disk: ok, juste les temps cpu de décompression mais c'est pas gênant et c'est normal.
J'ai tester avec le défilement d'une page web sous firefox, et avec mplayer et kaffeine. Si vlc à trouvé le moyen de désyncroniser sont affichage pour pas que les éléments graphique font ramer ces élément graphique telque ça video, il faut l'appliquer en masse en l'intégrant dans X11 pour qu'aucun éléments puisse en faire ramer un autre.
Aprés je sais pas ce que vous en penser, mais techniquement les problèmes exposer içi sont les seul défaut qui me gène sous linux. Et c'est les seul truc qui fait que windows n'est pas complément écraser par linux.
Donc pour résumer avec X11 (sous Qt, gtk, ou autre) les items ne sont pas indépendant et peuvent ce faire ramer mutuellement, l'affichage n'est pas temps réel et ce resent surtout lors de nombreux éléments.
Les IO (réseau ou hdd) sous linux prenne du temps cpu qui ne peu pas être utilisé par des applications. Sous windows ce n'est pas le cas teste à l'appui.
Ca ne sert à rien de regarder coté matos et drivers car j'ai tester cela sur plein de config/distrib différente avec le même résultat, je parle de l'interface que quand le pc à une prise en charge complète de la carte graphique.
Je m'assure toujours pour toute ce que j'ai dit que les testes ce fond dans les bonne condition, drivers et matos 100% reconnu et pris en charge.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Poste le Tuesday 15 July 2008 15:01:58
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
C'est pas vraiment un bug proprement dit, et pour l'affichage c'est peu être X11 qui est en cause, en je me sens pas super à l'aise en anglais.Citation
AlSim
alpha_one_x86 a écrit :Je suis pas la pour blamer
linux, je suis la pour faire en sorte de trouver
une solution
Pas l'endroit idéal pour ce genre de problème...
Déjà rien que je post en francais n'as bien fait parler, je me sens pas de refaire la même discutions en anglais.
Poste le Tuesday 15 July 2008 15:12:36
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
Basile STARYNKEVITCH
Une remarque générale: il n'est pas certain que la mesure du temps CPU (sous Linux comme sous Windows) soit extrêmement précise. Il pourrait même être probable que sous Windows ça soit moins précis, car dans tous les cas il faut instrumenter le noyau, et Microsoft n'aurait aucun intérêt à distribuer son système avec le code d'instrumentation (on devine bien que Microsoft a intérêt au contraire à ne pas distribuer une version instrumentée de son noyau).
Je n'y crois pas vraiment. Windows (comme n'importe quel système d'exploitation) doit faire des traitements comparables à ceux de Linux pour le réseau comme pour le disque. Le traitement d'un paquet IP sur ethernet, ou d'une interruption disque SATA, n'est gratuit pour aucun OS! Et les systèmes de fichiers windowsien n'ont pas une réputation d'efficacité. De plus, les serveurs windowsiens sont plus lourds et nécessitent plus de ressources que l'équivalent linuxien (autrement, tout le monde utiliserait Windows sur ses serveurs, où le coût des licences logicielles est toujours négligeable sur les autres coûts, l'essentiel du TCO étant la main d'oeuvre pour le support.).
Par contre, l'affichage X11 est évidemment bien plus onéreux qu'un affichage Windowsien, parce que X11 est un serveur (capable de fonctionner en réseau), ce que n'est pas la solution windowsienne.
L'équivalent linuxien de l'affichage windowsien (uniquement local) serait plutôt les solutions locales (sans protocole réseau) comme DirectFB mais il y a de bonnes raisons pour les éviter.
Mais je n'ai pas tout compris des problèmes que alpha_one_x86 cherchent à résoudre
[v](car ses fautes nombreuses de français me sont trop pénibles à lire, et détournent mon attention)[/v].
----
Basile STARYNKEVITCH
Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!
Projet logiciel libre: RefPerSys
Citation
alpha_one_x86
Les IO (réseau ou hdd) sous linux prennent du temps cpu qui ne peut pas être utilisé par des applications. Sous windows ce n'est pas le cas, tests à l'appui.
Je n'y crois pas vraiment. Windows (comme n'importe quel système d'exploitation) doit faire des traitements comparables à ceux de Linux pour le réseau comme pour le disque. Le traitement d'un paquet IP sur ethernet, ou d'une interruption disque SATA, n'est gratuit pour aucun OS! Et les systèmes de fichiers windowsien n'ont pas une réputation d'efficacité. De plus, les serveurs windowsiens sont plus lourds et nécessitent plus de ressources que l'équivalent linuxien (autrement, tout le monde utiliserait Windows sur ses serveurs, où le coût des licences logicielles est toujours négligeable sur les autres coûts, l'essentiel du TCO étant la main d'oeuvre pour le support.).
Par contre, l'affichage X11 est évidemment bien plus onéreux qu'un affichage Windowsien, parce que X11 est un serveur (capable de fonctionner en réseau), ce que n'est pas la solution windowsienne.
L'équivalent linuxien de l'affichage windowsien (uniquement local) serait plutôt les solutions locales (sans protocole réseau) comme DirectFB mais il y a de bonnes raisons pour les éviter.
Mais je n'ai pas tout compris des problèmes que alpha_one_x86 cherchent à résoudre
[v](car ses fautes nombreuses de français me sont trop pénibles à lire, et détournent mon attention)[/v].
----
Basile STARYNKEVITCH
Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!
Projet logiciel libre: RefPerSys
Poste le Tuesday 15 July 2008 15:22:29
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
L'utilisation du cpu est + ou - proportionnel à ça consommation, et mon ampéremétre est précis, ... ;-)
Un peu teste intéressant sous ram disque:
Kaffeine: 60% d'utilisation du cpu
Vlc: 10% pas de lag lors du défilement d'une page web
Sous windows:
Vlc: 2% pas de lag lors du défilement d'une page web mais c'est commun à tout les lecteurs video et toute les applications.
Mon ampérémettre fait un bon sous kaffeine, sous vlc et linux il augmente de 0.6A sous windows avec vlc j'ai une augmentation de 0.08A.
Pour Basile STARYNKEVITCH:
- Dans l'interface X11 un élément peu en faire ramer un autre, et l'affichage de nombreux est lourd mais temps réel sous windows
- Les IO prennes des temps cpu sous linux est pas sous windows, (teste cpu priorité basse avec dd ou autre IO pour s'en rendre compte)
Il n'aurai pas été plus simple de faire un affichage local et une solution distante car la majorité des utilisateurs utilise leur X11 en local.
Un peu teste intéressant sous ram disque:
Kaffeine: 60% d'utilisation du cpu
Vlc: 10% pas de lag lors du défilement d'une page web
Sous windows:
Vlc: 2% pas de lag lors du défilement d'une page web mais c'est commun à tout les lecteurs video et toute les applications.
Mon ampérémettre fait un bon sous kaffeine, sous vlc et linux il augmente de 0.6A sous windows avec vlc j'ai une augmentation de 0.08A.
Pour Basile STARYNKEVITCH:
- Dans l'interface X11 un élément peu en faire ramer un autre, et l'affichage de nombreux est lourd mais temps réel sous windows
- Les IO prennes des temps cpu sous linux est pas sous windows, (teste cpu priorité basse avec dd ou autre IO pour s'en rendre compte)
Il n'aurai pas été plus simple de faire un affichage local et une solution distante car la majorité des utilisateurs utilise leur X11 en local.
Poste le Tuesday 15 July 2008 15:57:06
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
PS: meme teste pour la lecture brute d'un hdd et d'un fichier sur le réseau:
linux: 3.6A avec utilisation d'un cœur à 100%.
window: 1.2A avec le cpu à 3%.
linux: 3.6A avec utilisation d'un cœur à 100%.
window: 1.2A avec le cpu à 3%.
Poste le Tuesday 15 July 2008 16:01:19
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
Basile STARYNKEVITCH
Est-ce que le disque dur est bien configuré (hdparm) notamment pour faire du DMA?
Mais comme d'autres, je suis sceptique sur la méthodologie, et j'ai beaucoup de mal à comprendre la motivation... (pourquoi perdre ton temps à çà?).
As tu essayé un autre OS libre (FreeBSD, Syllable)?
----
Basile STARYNKEVITCH
Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!
Projet logiciel libre: RefPerSys
Mais comme d'autres, je suis sceptique sur la méthodologie, et j'ai beaucoup de mal à comprendre la motivation... (pourquoi perdre ton temps à çà?).
As tu essayé un autre OS libre (FreeBSD, Syllable)?
----
Basile STARYNKEVITCH
Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!
Projet logiciel libre: RefPerSys
Poste le Tuesday 15 July 2008 17:40:09
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
ofkain
Bonjour,
Je rejoinds basile sur le dma, et re insiste sur ce point, X11 et co n'ont rien a voir la dedans, ce probleme est somme toute plutot simple, ce qu'il se passe est que en l'absence de l'activation du dma, ton OS donne tous les traitements de fichiers a faire par le CPU, au lieu du DMAC...
Donc pour commencer, hdparm -i /dev/sd??, hdparm -t /dev/sd??, make menuconfig du noyau pour verifier que tout est bien configurer ( et je peux presque t'assurer que ca ne l'est pas vu les chiffres )
Et pour finir sur le sujet de windows qui cache certaines choses, c'est vrai et faux en meme temps. Je m'explique, pour un transfert de disque a disque, comme je l'ai dis plus haut, tout passe par le dmac, donc 0% ( ou presque ) d'utilisation du CPU, c'est comme ca sur toutes mes machines.
Par contre, lors d'un transfert sur usb par exemple, la je note une relativement faible, mais bien existante utilisation du CPU ( de l'ordre de 5 a 15% ) et la raison en est tres simple, l'usb n'utilise pas de dma ( ceci n'est cependant pas une règle générale... voir doc du kernel ) et la, effectivement, dans ce cas windows masque l'utilisation CPU faite par les IO.
Je me permets donc de reinsister sur le fait que ton problème est seulement un problème de configuration du noyau... il existe plusieures options a activer, n'ayant pas de noyau sous la main je ne peux pas te les lister, mais en tout cas, il est sur que hdparm te diras que ton disque n'est pas en dma ( a ne pas confondre avec les mode UDMA[0-6]... )
Je rejoinds basile sur le dma, et re insiste sur ce point, X11 et co n'ont rien a voir la dedans, ce probleme est somme toute plutot simple, ce qu'il se passe est que en l'absence de l'activation du dma, ton OS donne tous les traitements de fichiers a faire par le CPU, au lieu du DMAC...
Donc pour commencer, hdparm -i /dev/sd??, hdparm -t /dev/sd??, make menuconfig du noyau pour verifier que tout est bien configurer ( et je peux presque t'assurer que ca ne l'est pas vu les chiffres )
Et pour finir sur le sujet de windows qui cache certaines choses, c'est vrai et faux en meme temps. Je m'explique, pour un transfert de disque a disque, comme je l'ai dis plus haut, tout passe par le dmac, donc 0% ( ou presque ) d'utilisation du CPU, c'est comme ca sur toutes mes machines.
Par contre, lors d'un transfert sur usb par exemple, la je note une relativement faible, mais bien existante utilisation du CPU ( de l'ordre de 5 a 15% ) et la raison en est tres simple, l'usb n'utilise pas de dma ( ceci n'est cependant pas une règle générale... voir doc du kernel ) et la, effectivement, dans ce cas windows masque l'utilisation CPU faite par les IO.
Je me permets donc de reinsister sur le fait que ton problème est seulement un problème de configuration du noyau... il existe plusieures options a activer, n'ayant pas de noyau sous la main je ne peux pas te les lister, mais en tout cas, il est sur que hdparm te diras que ton disque n'est pas en dma ( a ne pas confondre avec les mode UDMA[0-6]... )
Poste le Tuesday 15 July 2008 18:49:01
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
diancech
Bon aprés quelques petits tests que je viens de faire, je reviens sur ce que j'ai dit pas de problème avec gmplayer.
La config :
Matériel:
AMD Athlon XP 3000+
Carte nvidia GeForce 6600
1Go de RAM
je vous passe le reste ;-)
Logiciel:
Windows XP
Debian Lenny (installée il y a un mois, pas tripotée :-)) ).
Les pourcentages CPU je les ai lu (en temps qu'utilisateur basique ^^D-* ) dans le moniteur Système sous windows et sous top sous linux.
Copie de fichier basique de disque à disque sous windows avec l'explorateur de fichier et sous linux avec rox-filer:
Lecture de vidéos avec VLC sous windows et Linux avec des déplacements de fenêtre (Explorateur de fichier sous windows et rox-filer sous linux):
C'est sûr que c'est un benchmark un peu à la louche (et sans doute un peu bidon, il aurait fallu que j'utilise des logiciels spécifique mesurant les IO et le %CPU par processus sur les deux OS mais j'ai un peu la flême :-))), en tout cas je ne rencontre pas le genre de problème que tu as alors que la debian lenny vient d'être installé sans prendre le temps de faire le ménage dans les services inutiles et autres chose que je pourrai customiser (système de fichier, ...)
Donc je rejoins ofkain, à mon avis il y a des choses de mal configuré sur ta (tes) machine(s).
Je referai les tests avec mon autre configuration Gentoo AMD64 sur de l'intel core2duo avec une nvidia 8800 GTX et 2 Go de ram pour voir les résultats. ;-)
--------------------------------------------------------------------------------------------------------------------------------------------------
Exige beaucoup de toi-même et attends peu des autres. Ainsi beaucoup d'ennuis te seront épargnés. Confucius
La config :
Matériel:
AMD Athlon XP 3000+
Carte nvidia GeForce 6600
1Go de RAM
je vous passe le reste ;-)
Logiciel:
Windows XP
Debian Lenny (installée il y a un mois, pas tripotée :-)) ).
Les pourcentages CPU je les ai lu (en temps qu'utilisateur basique ^^D-* ) dans le moniteur Système sous windows et sous top sous linux.
Copie de fichier basique de disque à disque sous windows avec l'explorateur de fichier et sous linux avec rox-filer:
Sous windows : 30% de CPU utilisée pendant la copie. Sous linux: 10% de CPU.Ce qui doit correspondre à la consommation des effets graphiques imageant la copie des fichiers je pense.
Lecture de vidéos avec VLC sous windows et Linux avec des déplacements de fenêtre (Explorateur de fichier sous windows et rox-filer sous linux):
Sous windows: VLC en fonctionnement 2% de CPU -> Quand je déplace la fenêtre le CPU monte à 99% et la vidéo se fige il ne reste plus que le son. Sous linux : VLC en fonctionnemment 10% de CPU -> Quand je déplace la fenêtre le CPU monte à 48% et la vidéo reste fluide sans saccade.Donc la gestion des fenêtres des applications sous windows n'est pas bien faite puisque la vidéos se fige en déplaçant une fenêtre, tandis que sous linux les fenêtres sont bien gérés indépendamment puisque la vidéo est fluide lors du déplacement de fenêtre.
C'est sûr que c'est un benchmark un peu à la louche (et sans doute un peu bidon, il aurait fallu que j'utilise des logiciels spécifique mesurant les IO et le %CPU par processus sur les deux OS mais j'ai un peu la flême :-))), en tout cas je ne rencontre pas le genre de problème que tu as alors que la debian lenny vient d'être installé sans prendre le temps de faire le ménage dans les services inutiles et autres chose que je pourrai customiser (système de fichier, ...)
Donc je rejoins ofkain, à mon avis il y a des choses de mal configuré sur ta (tes) machine(s).
Je referai les tests avec mon autre configuration Gentoo AMD64 sur de l'intel core2duo avec une nvidia 8800 GTX et 2 Go de ram pour voir les résultats. ;-)
--------------------------------------------------------------------------------------------------------------------------------------------------
Exige beaucoup de toi-même et attends peu des autres. Ainsi beaucoup d'ennuis te seront épargnés. Confucius
Poste le Tuesday 15 July 2008 20:06:42
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
Ca viens peu étre de la:
Je perd mon temps car ça rame, surtout dans certaine condition, et car j'aimerai une réactivité optimal comme sous windows, surtout avec les pc qui ont une grosse carte graphique.
Les autre unix j'ai pas encore essayer. Je vais m'y mettre un jour.
J'ai les meme résultat sous linux mais sous windows tout est différent chez moi. L'utilisation du cpu reste à vide pour le déplacement des fénétres video comme vlc, et idem pour la copie de fichier (gros ou petit)
En un coup de config:
Je croise les doigt pour que ce soit moi qui est mal config, mais ca serai bizard que ça me le fasse pour toute les distro même celle que j'ai pas faite.
Je rejoins diancech dans les résultats linux, pas dans ceux windows.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
hdparm -d /dev/sda
/dev/sda:
HDIO_GET_DMA failed: Inappropriate ioctl for device
amber ~ # hdparm -d /dev/sdb
/dev/sdb:
HDIO_GET_DMA failed: Inappropriate ioctl for device
hdparm -i /dev/sda /dev/sdb
/dev/sda:
Model=ST31000340AS , FwRev=SD04 , SerialNo= 3QJ00GJJ
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953523055
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-4,5,6,7
* signifies the current active mode
/dev/sdb:
Model=ST31000340AS , FwRev=SD15 , SerialNo= 9QJ034DY
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-4,5,6,7
* signifies the current active mode
hdparm -t /dev/sda /dev/sdb
/dev/sda:
Timing buffered disk reads: 180 MB in 3.02 seconds = 59.62 MB/sec
/dev/sdb:
Timing buffered disk reads: 176 MB in 3.01 seconds = 58.55 MB/sec
A moins que la sata fausse les mesures.
Je perd mon temps car ça rame, surtout dans certaine condition, et car j'aimerai une réactivité optimal comme sous windows, surtout avec les pc qui ont une grosse carte graphique.
Les autre unix j'ai pas encore essayer. Je vais m'y mettre un jour.
J'ai les meme résultat sous linux mais sous windows tout est différent chez moi. L'utilisation du cpu reste à vide pour le déplacement des fénétres video comme vlc, et idem pour la copie de fichier (gros ou petit)
En un coup de config:
cat config | grep DMA CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_ZONE_DMA32=y CONFIG_ZONE_DMA_FLAG=1 # CONFIG_DMAR is not set CONFIG_ISA_DMA_API=y CONFIG_SCSI_DMA=y # CONFIG_PDC_ADMA is not set # CONFIG_PATA_OPTIDMA is not set CONFIG_I2O_EXT_ADAPTEC_DMA64=y CONFIG_DMADEVICES=y # DMA Devices CONFIG_INTEL_IOATDMA=m CONFIG_DMA_ENGINE=y # DMA Clients CONFIG_NET_DMA=y # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set CONFIG_HAS_DMA=y
Je croise les doigt pour que ce soit moi qui est mal config, mais ca serai bizard que ça me le fasse pour toute les distro même celle que j'ai pas faite.
Je rejoins diancech dans les résultats linux, pas dans ceux windows.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Poste le Tuesday 15 July 2008 22:11:00
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
Avec un autre pc, j'ai ces résultat sur le déplacement de vlc, mais toujours pas sur le copier coller.
Moi je trouve qu'il y as une grosse différence en 2% et 10% d'utilisation du cpu, surtout que le décodage/encodage des video est aussi rapide sous linux que sous windows. Surtout que je suis surtout à 0% sous windows avec un meilleur pc.
Je continu à chercher.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Moi je trouve qu'il y as une grosse différence en 2% et 10% d'utilisation du cpu, surtout que le décodage/encodage des video est aussi rapide sous linux que sous windows. Surtout que je suis surtout à 0% sous windows avec un meilleur pc.
Je continu à chercher.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Poste le Tuesday 15 July 2008 22:17:43
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
Basile STARYNKEVITCH
Citation
alpha
Ca vient peut-étre de là:
hdparm -d /dev/sda /dev/sda: HDIO_GET_DMA failed: Inappropriate ioctl for device amber ~ # hdparm -d /dev/sdb /dev/sdb: HDIO_GET_DMA failed: Inappropriate ioctl for device
Oui, très probablement.
----
Basile STARYNKEVITCH
Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!
Projet logiciel libre: RefPerSys
Poste le Wednesday 16 July 2008 18:10:48
Re: Temps noyau intempestifs lors d'IO
Envoyé par:
alpha_one_x86
Sachant aussi que tout mes disque dur sata font la même réaction.
La lib sata est peu être en cause.
Même résultat avec un disque ide gérer par la lib sata.
Je continu à chercher.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
La lib sata est peu être en cause.
Même résultat avec un disque ide gérer par la lib sata.
Je continu à chercher.
Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]
Poste le Wednesday 16 July 2008 22:25:00
Page: 2 sur 4
Ce forum !
Temps noyau intempestifs lors d'IO
Posez dans ce forum les questions qui ne trouvent pas place dans les autres...
Nouveau sujet sur ce forum
Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons