je viens de me faire une installation sur disque dur de la dernière knoppix
(3.3) pour raison de config simplifiée par rapport à Woody sur mon shuttle
xpc.
J'ai testé la gravure (copie) de cd avec k3b dans l'environnement de KDE3.
Je suis très étonné de voir que la machine est complètement à genoux pendant
l'opération, la réactivité du système est très réduite, la souris saccadée.
A tel point que ça fait tomber pppd...
C'est une copie par image lue/écrite par le graveur IDE LiteOn 48x, la
machine tourne à 1,7 GHz, avec 512 Mo de RAM et un disque IBM ultra-dma.
Ca m'étonne pour du multi-tâches préemptif...
Qu'est-ce que je devrais corriger ?
Surtout, je ne veux pas lancer un nouveau débat sur le meilleur window
manager, de toutes façons, je pense le changer...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Arnaud ARZUFFI
seki wrote:
Bonjour à tous,
je viens de me faire une installation sur disque dur de la dernière knoppix (3.3) pour raison de config simplifiée par rapport à Woody sur mon shuttle xpc.
J'ai testé la gravure (copie) de cd avec k3b dans l'environnement de KDE3.
Je suis très étonné de voir que la machine est complètement à genoux pendant l'opération, la réactivité du système est très réduite, la souris saccadée. A tel point que ça fait tomber pppd...
C'est une copie par image lue/écrite par le graveur IDE LiteOn 48x, la machine tourne à 1,7 GHz, avec 512 Mo de RAM et un disque IBM ultra-dma.
Ca m'étonne pour du multi-tâches préemptif... Qu'est-ce que je devrais corriger ?
Surtout, je ne veux pas lancer un nouveau débat sur le meilleur window manager, de toutes façons, je pense le changer...
Au secours ! Merci pour votre attention.
Sébastien Kirche.
C'est étrange, jamais constaté ces problèmes : j'avais testé une gravure en 48X (à la volée en plus) avec K3B sous KDE 3 aussi ; pendant ce temps je visionnais Matrix avec mplayer, et le processeur était même pas utilisé à 10% ! et la mémoire à 20% environ... la seule différence c'est la distribution : Mandrake 9.2 ; mais franchement ça m'étonnerait que le problème vienne de la distribution...
Ma machine est assez semblable (la différence de mémoire intervient pas puisqu'elle était pas utilisée à plus de 256Mo) : AMD Athlon XP 2600, 1024Mo DDRAM 333, graveur IDE TEAC 48X
-- Arnaud ARZUFFI
seki wrote:
Bonjour à tous,
je viens de me faire une installation sur disque dur de la dernière
knoppix (3.3) pour raison de config simplifiée par rapport à Woody sur mon
shuttle xpc.
J'ai testé la gravure (copie) de cd avec k3b dans l'environnement de KDE3.
Je suis très étonné de voir que la machine est complètement à genoux
pendant l'opération, la réactivité du système est très réduite, la souris
saccadée. A tel point que ça fait tomber pppd...
C'est une copie par image lue/écrite par le graveur IDE LiteOn 48x, la
machine tourne à 1,7 GHz, avec 512 Mo de RAM et un disque IBM ultra-dma.
Ca m'étonne pour du multi-tâches préemptif...
Qu'est-ce que je devrais corriger ?
Surtout, je ne veux pas lancer un nouveau débat sur le meilleur window
manager, de toutes façons, je pense le changer...
Au secours !
Merci pour votre attention.
Sébastien Kirche.
C'est étrange, jamais constaté ces problèmes : j'avais testé une gravure en
48X (à la volée en plus) avec K3B sous KDE 3 aussi ; pendant ce temps je
visionnais Matrix avec mplayer, et le processeur était même pas utilisé à
10% ! et la mémoire à 20% environ... la seule différence c'est la
distribution : Mandrake 9.2 ; mais franchement ça m'étonnerait que le
problème vienne de la distribution...
Ma machine est assez semblable (la différence de mémoire intervient pas
puisqu'elle était pas utilisée à plus de 256Mo) : AMD Athlon XP 2600,
1024Mo DDRAM 333, graveur IDE TEAC 48X
je viens de me faire une installation sur disque dur de la dernière knoppix (3.3) pour raison de config simplifiée par rapport à Woody sur mon shuttle xpc.
J'ai testé la gravure (copie) de cd avec k3b dans l'environnement de KDE3.
Je suis très étonné de voir que la machine est complètement à genoux pendant l'opération, la réactivité du système est très réduite, la souris saccadée. A tel point que ça fait tomber pppd...
C'est une copie par image lue/écrite par le graveur IDE LiteOn 48x, la machine tourne à 1,7 GHz, avec 512 Mo de RAM et un disque IBM ultra-dma.
Ca m'étonne pour du multi-tâches préemptif... Qu'est-ce que je devrais corriger ?
Surtout, je ne veux pas lancer un nouveau débat sur le meilleur window manager, de toutes façons, je pense le changer...
Au secours ! Merci pour votre attention.
Sébastien Kirche.
C'est étrange, jamais constaté ces problèmes : j'avais testé une gravure en 48X (à la volée en plus) avec K3B sous KDE 3 aussi ; pendant ce temps je visionnais Matrix avec mplayer, et le processeur était même pas utilisé à 10% ! et la mémoire à 20% environ... la seule différence c'est la distribution : Mandrake 9.2 ; mais franchement ça m'étonnerait que le problème vienne de la distribution...
Ma machine est assez semblable (la différence de mémoire intervient pas puisqu'elle était pas utilisée à plus de 256Mo) : AMD Athlon XP 2600, 1024Mo DDRAM 333, graveur IDE TEAC 48X
-- Arnaud ARZUFFI
Seki
Arnaud ARZUFFI wrote:
C'est étrange, jamais constaté ces problèmes : j'avais testé une gravure en 48X (à la volée en plus) avec K3B sous KDE 3 aussi ; pendant ce temps je visionnais Matrix avec mplayer, et le processeur était même pas utilisé à 10% ! et la mémoire à 20% environ... la seule différence c'est la distribution : Mandrake 9.2 ; mais franchement ça m'étonnerait que le problème vienne de la distribution...
Ma machine est assez semblable (la différence de mémoire intervient pas puisqu'elle était pas utilisée à plus de 256Mo) : AMD Athlon XP 2600, 1024Mo DDRAM 333, graveur IDE TEAC 48X
Ce que j'ai peut-être oublié de préciser c'est que la gravure s'est passé sans problèmes, avec tampon d'écriture plein tout le temps. Par contre je ne peux faire QUE cela pendant ce temps. L'utilisateur était le root.
Et je viens de contrôler que l'accès DMA au disque dur est activé avec hdparm Bien qu'au démarrage j'ai un message bizarre indiquant que dma n'est pas actif; ce qui est par défaut sur knoppix il me semble, je l'ai activé moi même avec un "hdparm -d1 /dev/hda"
Je vois vraiment pas...
Arnaud ARZUFFI wrote:
C'est étrange, jamais constaté ces problèmes : j'avais testé une gravure
en 48X (à la volée en plus) avec K3B sous KDE 3 aussi ; pendant ce temps
je visionnais Matrix avec mplayer, et le processeur était même pas utilisé
à 10% ! et la mémoire à 20% environ... la seule différence c'est la
distribution : Mandrake 9.2 ; mais franchement ça m'étonnerait que le
problème vienne de la distribution...
Ma machine est assez semblable (la différence de mémoire intervient pas
puisqu'elle était pas utilisée à plus de 256Mo) : AMD Athlon XP 2600,
1024Mo DDRAM 333, graveur IDE TEAC 48X
Ce que j'ai peut-être oublié de préciser c'est que la gravure s'est passé
sans problèmes, avec tampon d'écriture plein tout le temps.
Par contre je ne peux faire QUE cela pendant ce temps.
L'utilisateur était le root.
Et je viens de contrôler que l'accès DMA au disque dur est activé avec
hdparm
Bien qu'au démarrage j'ai un message bizarre indiquant que dma n'est pas
actif; ce qui est par défaut sur knoppix il me semble, je l'ai activé moi
même avec un "hdparm -d1 /dev/hda"
C'est étrange, jamais constaté ces problèmes : j'avais testé une gravure en 48X (à la volée en plus) avec K3B sous KDE 3 aussi ; pendant ce temps je visionnais Matrix avec mplayer, et le processeur était même pas utilisé à 10% ! et la mémoire à 20% environ... la seule différence c'est la distribution : Mandrake 9.2 ; mais franchement ça m'étonnerait que le problème vienne de la distribution...
Ma machine est assez semblable (la différence de mémoire intervient pas puisqu'elle était pas utilisée à plus de 256Mo) : AMD Athlon XP 2600, 1024Mo DDRAM 333, graveur IDE TEAC 48X
Ce que j'ai peut-être oublié de préciser c'est que la gravure s'est passé sans problèmes, avec tampon d'écriture plein tout le temps. Par contre je ne peux faire QUE cela pendant ce temps. L'utilisateur était le root.
Et je viens de contrôler que l'accès DMA au disque dur est activé avec hdparm Bien qu'au démarrage j'ai un message bizarre indiquant que dma n'est pas actif; ce qui est par défaut sur knoppix il me semble, je l'ai activé moi même avec un "hdparm -d1 /dev/hda"
Je vois vraiment pas...
Seki
Seki wrote:
Bien qu'au démarrage j'ai un message bizarre indiquant que dma n'est pas actif; ce qui est par défaut sur knoppix il me semble, je l'ai activé moi même avec un "hdparm -d1 /dev/hda"
message bizarre que je retrouve pas dans dmesg en plus ... ?
Seki wrote:
Bien qu'au démarrage j'ai un message bizarre indiquant que dma n'est pas
actif; ce qui est par défaut sur knoppix il me semble, je l'ai activé moi
même avec un "hdparm -d1 /dev/hda"
message bizarre que je retrouve pas dans dmesg en plus ... ?
Bien qu'au démarrage j'ai un message bizarre indiquant que dma n'est pas actif; ce qui est par défaut sur knoppix il me semble, je l'ai activé moi même avec un "hdparm -d1 /dev/hda"
message bizarre que je retrouve pas dans dmesg en plus ... ?
Seki
Seki wrote:
j'ai refait des tests, en fait ca cafouille dès l'image avec cdrdao bien que cdrdao ne prenne pas tellement de cpu dans top, à peine 8 à 10 %
j'ai peut-être une piste : à quoi sert l'émulation scsi pour l'ide ? Paske j'ai ça dans dmesg : Kernel command line: BOOT_IMAGE=Linux ro root0b hda=scsi hdb=scsi hdc=scsi hdd=scsi hde=scsi hdf=scsi hdg=scsi hdh=scsi apm=power-off nomce
Je pourrais supprimer les paramètres scsi de la ligne de boot dans lilo ?
Sébastien Kirche
Seki wrote:
j'ai refait des tests, en fait ca cafouille dès l'image avec cdrdao
bien que cdrdao ne prenne pas tellement de cpu dans top, à peine 8 à 10 %
j'ai peut-être une piste :
à quoi sert l'émulation scsi pour l'ide ?
Paske j'ai ça dans dmesg :
Kernel command line: BOOT_IMAGE=Linux ro root0b hda=scsi hdb=scsi hdc=scsi
hdd=scsi hde=scsi hdf=scsi hdg=scsi hdh=scsi apm=power-off nomce
Je pourrais supprimer les paramètres scsi de la ligne de boot dans lilo ?
j'ai refait des tests, en fait ca cafouille dès l'image avec cdrdao bien que cdrdao ne prenne pas tellement de cpu dans top, à peine 8 à 10 %
j'ai peut-être une piste : à quoi sert l'émulation scsi pour l'ide ? Paske j'ai ça dans dmesg : Kernel command line: BOOT_IMAGE=Linux ro root0b hda=scsi hdb=scsi hdc=scsi hdd=scsi hde=scsi hdf=scsi hdg=scsi hdh=scsi apm=power-off nomce
Je pourrais supprimer les paramètres scsi de la ligne de boot dans lilo ?
Sébastien Kirche
gael
Seki wrote:
Seki wrote:
j'ai refait des tests, en fait ca cafouille dès l'image avec cdrdao bien que cdrdao ne prenne pas tellement de cpu dans top, à peine 8 à 10 %
j'ai peut-être une piste : à quoi sert l'émulation scsi pour l'ide ? Paske j'ai ça dans dmesg : Kernel command line: BOOT_IMAGE=Linux ro root0b hda=scsi hdb=scsi hdc=scsi hdd=scsi hde=scsi hdf=scsi hdg=scsi hdh=scsi apm=power-off nomce
Je pourrais supprimer les paramètres scsi de la ligne de boot dans lilo ?
Sébastien Kirche L'émulation SCSI est le seul moyen pour l'instant de faire une gravure
avec un graveur IDE. Par contre c'est quand même bizarre que tous tes lecteurs soient en émulation scsi et qu'en regardant mon lilo.conf, j'ai plutôt hdd=ide-scsi (sur Mandrake 9.0).
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Seki wrote:
Seki wrote:
j'ai refait des tests, en fait ca cafouille dès l'image avec cdrdao
bien que cdrdao ne prenne pas tellement de cpu dans top, à peine 8 à 10 %
j'ai peut-être une piste :
à quoi sert l'émulation scsi pour l'ide ?
Paske j'ai ça dans dmesg :
Kernel command line: BOOT_IMAGE=Linux ro root0b hda=scsi hdb=scsi hdc=scsi
hdd=scsi hde=scsi hdf=scsi hdg=scsi hdh=scsi apm=power-off nomce
Je pourrais supprimer les paramètres scsi de la ligne de boot dans lilo ?
Sébastien Kirche
L'émulation SCSI est le seul moyen pour l'instant de faire une gravure
avec un graveur IDE.
Par contre c'est quand même bizarre que tous tes lecteurs soient en
émulation scsi et qu'en regardant mon lilo.conf, j'ai plutôt
hdd=ide-scsi (sur Mandrake 9.0).
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à
trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
j'ai refait des tests, en fait ca cafouille dès l'image avec cdrdao bien que cdrdao ne prenne pas tellement de cpu dans top, à peine 8 à 10 %
j'ai peut-être une piste : à quoi sert l'émulation scsi pour l'ide ? Paske j'ai ça dans dmesg : Kernel command line: BOOT_IMAGE=Linux ro root0b hda=scsi hdb=scsi hdc=scsi hdd=scsi hde=scsi hdf=scsi hdg=scsi hdh=scsi apm=power-off nomce
Je pourrais supprimer les paramètres scsi de la ligne de boot dans lilo ?
Sébastien Kirche L'émulation SCSI est le seul moyen pour l'instant de faire une gravure
avec un graveur IDE. Par contre c'est quand même bizarre que tous tes lecteurs soient en émulation scsi et qu'en regardant mon lilo.conf, j'ai plutôt hdd=ide-scsi (sur Mandrake 9.0).
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
seki
gael wrote:
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ? moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours fonctionner si je vire hda=scsi non ?
pour ce qui est est de la gravure, je comprends que sans scsi, pas d'adressage type "dev=0,6,0" mais il me semblait que cdrecord supportait maintenant la gravure sur atapi ? (c'est le cas sous windows, si on compile une version cygwin de cdrecord)
Avant j'avait du matos scsi, j'avais jamais remarqué que l'ide était pas dispo pour graver...
gael wrote:
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à
trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ?
moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours
fonctionner si je vire hda=scsi non ?
pour ce qui est est de la gravure, je comprends que sans scsi, pas
d'adressage type "dev=0,6,0" mais il me semblait que cdrecord supportait
maintenant la gravure sur atapi ?
(c'est le cas sous windows, si on compile une version cygwin de cdrecord)
Avant j'avait du matos scsi, j'avais jamais remarqué que l'ide était pas
dispo pour graver...
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ? moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours fonctionner si je vire hda=scsi non ?
pour ce qui est est de la gravure, je comprends que sans scsi, pas d'adressage type "dev=0,6,0" mais il me semblait que cdrecord supportait maintenant la gravure sur atapi ? (c'est le cas sous windows, si on compile une version cygwin de cdrecord)
Avant j'avait du matos scsi, j'avais jamais remarqué que l'ide était pas dispo pour graver...
seki
seki wrote:
gael wrote:
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ? moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours fonctionner si je vire hda=scsi non ?
Ben en effet ça marche toujours, en enlevant le hda=scsi (mais pas pour hdd qui est mon graveur ide), mais ça ne change rien au problème.
En résumé, une image cd par k3b via cdrdao me bouffe un max de ressources (?) au point que ca bloque la communication ppp qui finit par tomber si la copie se prolonge...
Je nage...
seki wrote:
gael wrote:
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à
trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ?
moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours
fonctionner si je vire hda=scsi non ?
Ben en effet ça marche toujours, en enlevant le hda=scsi (mais pas pour
hdd qui est mon graveur ide),
mais ça ne change rien au problème.
En résumé, une image cd par k3b via cdrdao me bouffe un max de
ressources (?)
au point que ca bloque la communication ppp qui finit par tomber si la
copie se prolonge...
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ? moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours fonctionner si je vire hda=scsi non ?
Ben en effet ça marche toujours, en enlevant le hda=scsi (mais pas pour hdd qui est mon graveur ide), mais ça ne change rien au problème.
En résumé, une image cd par k3b via cdrdao me bouffe un max de ressources (?) au point que ca bloque la communication ppp qui finit par tomber si la copie se prolonge...
Je nage...
Seki
seki wrote:
seki wrote:
gael wrote:
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ? moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours fonctionner si je vire hda=scsi non ?
Ben en effet ça marche toujours, en enlevant le hda=scsi (mais pas pour hdd qui est mon graveur ide), mais ça ne change rien au problème.
En résumé, une image cd par k3b via cdrdao me bouffe un max de ressources (?) au point que ca bloque la communication ppp qui finit par tomber si la copie se prolonge...
Je nage...
J'ai trouvé (enfin je crois)
hdparm -u1 /dev/hdd (active les autres interruptions pendant les interruption disque)
cela semble avoir réglé le problème puisque je peux maintenant faire une image ET être connecter sans planter.
Seb, pour info
seki wrote:
seki wrote:
gael wrote:
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à
trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ?
moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours
fonctionner si je vire hda=scsi non ?
Ben en effet ça marche toujours, en enlevant le hda=scsi (mais pas pour
hdd qui est mon graveur ide),
mais ça ne change rien au problème.
En résumé, une image cd par k3b via cdrdao me bouffe un max de
ressources (?)
au point que ca bloque la communication ppp qui finit par tomber si la
copie se prolonge...
Je nage...
J'ai trouvé (enfin je crois)
hdparm -u1 /dev/hdd (active les autres interruptions pendant les
interruption disque)
cela semble avoir réglé le problème puisque je peux maintenant faire une
image ET être connecter sans planter.
Dans tout les cas ne supprimes pas le scsi sinon Linux n'arrivera pas à trouver le disque (sdx alors que si tu supprimes scsi -> hdx)
Hein ? Quoi ? moi je monte /dev/hdax dans fstab, pas /dev/sdax. Ca doit toujours fonctionner si je vire hda=scsi non ?
Ben en effet ça marche toujours, en enlevant le hda=scsi (mais pas pour hdd qui est mon graveur ide), mais ça ne change rien au problème.
En résumé, une image cd par k3b via cdrdao me bouffe un max de ressources (?) au point que ca bloque la communication ppp qui finit par tomber si la copie se prolonge...
Je nage...
J'ai trouvé (enfin je crois)
hdparm -u1 /dev/hdd (active les autres interruptions pendant les interruption disque)
cela semble avoir réglé le problème puisque je peux maintenant faire une image ET être connecter sans planter.
