Limite d'un disque dur en lecture multipiste
Limite d'un disque dur en lecture multipiste
Bonjour, je voudrais savoir s'il y a une limite au nombre de fichier audio que l'on peut lire simultanément à partir d'un même disque dur ?
Y a t-il un risque de détérioration à cause des mouvement des têtes de lecture ?
Est-il préférable de partager les fichier audio sur plusieurs disque dur en lecture multipiste. ?
J'ai cherché un peu sur le net et j'ai rien trouvé.
Si jamais quelqu'un a une idée sur la question, c'est juste pour info.
Je ne tiens pas compte de la ram, du proc en considérant qu'il sont suffisant.
Y a t-il un risque de détérioration à cause des mouvement des têtes de lecture ?
Est-il préférable de partager les fichier audio sur plusieurs disque dur en lecture multipiste. ?
J'ai cherché un peu sur le net et j'ai rien trouvé.
Si jamais quelqu'un a une idée sur la question, c'est juste pour info.
Je ne tiens pas compte de la ram, du proc en considérant qu'il sont suffisant.
Re: Limite d
Ca dépend de la vitesse du disque (débit en enregistrement), de la fréquence d'échantillonage, du nombre de bit et si c'est le même disque pour l'application et l'audio ou pas ...
Re: Limite d
Par essence, un disque dur est mono-tache. Il n'est pas capable de lire 2 sons en même temps. La lecture des données est séquentielle, un son après l'autre qui va remplir un cache en Ram, c'est l'application qui va ensuite se charger de diffuser les sons en même temps.
Le disque dur lit donc les données très en avance sur l'audition réelle des sons.
Il y a beaucoup de paramètres qui rentrent en ligne de compte sur les performances d'un DD.
La fragmentation est celle qui dégrade le plus les performances.
Une augmentation du cache peut, dans une certaine limite, palier à ce problème.
Le disque dur lit donc les données très en avance sur l'audition réelle des sons.
Il y a beaucoup de paramètres qui rentrent en ligne de compte sur les performances d'un DD.
La fragmentation est celle qui dégrade le plus les performances.
Une augmentation du cache peut, dans une certaine limite, palier à ce problème.
Re: Limite d
Salut, c'est mon premier message ici !
Si tu penses à des limitations de vitesse des disques durs, lance toi sur du SSD SATA 3 au besoin en RAID 0, tu auras des débits jusqu'à 600 MO/Sec (ce qui est mon cas) voire plus, et là, tu n'auras pas de limite. Privilégie les derniers processeurs hexa core de chez AMD par exemple qui montent très bien en fréquence (4GHz facile) et une grande quantité de mémoire, 16 Go par exemple de DDR3 rapide (moi j'en ai 8 Go ce qui est largement suffisant pour mon usage). Même en 24 bits en CAN (ADC) et 192 KHz, je ne fatigue pas ma machine. Mais je ne fais que de petits trucs perso aussi !
Après il faut aussi voir ta carte son, sa connectique vers le PC (F/W, USB, PCI, PCI-e, etc.)
@MarcV -> ce n'est pas exact du tout ce que tu dis, un disque dur ne fonctionne pas du tout comme cela Pas d'agressivité de ma part pour ce premier message, c'est juste que j'ai la chance d'être ingé informatique et d'être consultant Info et Audio-Visuel, ainsi que d'être dans l'info et l'électronique depuis 1979 Si tu veux, si tu as des questions, je pourrais te renseigner dans la mesure de mes compétences.
Bien cordialement
Si tu penses à des limitations de vitesse des disques durs, lance toi sur du SSD SATA 3 au besoin en RAID 0, tu auras des débits jusqu'à 600 MO/Sec (ce qui est mon cas) voire plus, et là, tu n'auras pas de limite. Privilégie les derniers processeurs hexa core de chez AMD par exemple qui montent très bien en fréquence (4GHz facile) et une grande quantité de mémoire, 16 Go par exemple de DDR3 rapide (moi j'en ai 8 Go ce qui est largement suffisant pour mon usage). Même en 24 bits en CAN (ADC) et 192 KHz, je ne fatigue pas ma machine. Mais je ne fais que de petits trucs perso aussi !
Après il faut aussi voir ta carte son, sa connectique vers le PC (F/W, USB, PCI, PCI-e, etc.)
@MarcV -> ce n'est pas exact du tout ce que tu dis, un disque dur ne fonctionne pas du tout comme cela Pas d'agressivité de ma part pour ce premier message, c'est juste que j'ai la chance d'être ingé informatique et d'être consultant Info et Audio-Visuel, ainsi que d'être dans l'info et l'électronique depuis 1979 Si tu veux, si tu as des questions, je pourrais te renseigner dans la mesure de mes compétences.
Bien cordialement
Ca m'interesse, j'avais une vision assez similaire à celle de MarcV quant à l'accès aux données sur un disque. Pourrais-tu nous donner une version plus proche de la réalité telle que tu la côtoie? Merci d'avance@MarcV -> ce n'est pas exact du tout ce que tu dis, un disque dur ne fonctionne pas du tout comme cela Wink Pas d'agressivité de ma part pour ce premier message, c'est juste que j'ai la chance d'être ingé informatique et d'être consultant Info et Audio-Visuel, ainsi que d'être dans l'info et l'électronique depuis 1979 Wink Si tu veux, si tu as des questions, je pourrais te renseigner dans la mesure de mes compétences.
- Alexis
- L'équipe SDO
- Messages : 3118
- Inscription : 08 janv. 2006, 02:49
- Localisation : Corcoué sur logne
Re: Limite d
J'avais la même vision sur la lecture d'un disque... alors, la vérité est ailleurs ? Comment fait le disque pour lire plusieurs fichiers en même temps ?Tharkie a écrit :Salut, c'est mon premier message ici !
Si tu penses à des limitations de vitesse des disques durs, lance toi sur du SSD SATA 3 au besoin en RAID 0, tu auras des débits jusqu'à 600 MO/Sec (ce qui est mon cas) voire plus, et là, tu n'auras pas de limite. Privilégie les derniers processeurs hexa core de chez AMD par exemple qui montent très bien en fréquence (4GHz facile) et une grande quantité de mémoire, 16 Go par exemple de DDR3 rapide (moi j'en ai 8 Go ce qui est largement suffisant pour mon usage). Même en 24 bits en CAN (ADC) et 192 KHz, je ne fatigue pas ma machine. Mais je ne fais que de petits trucs perso aussi !
Après il faut aussi voir ta carte son, sa connectique vers le PC (F/W, USB, PCI, PCI-e, etc.)
@MarcV -> ce n'est pas exact du tout ce que tu dis, un disque dur ne fonctionne pas du tout comme cela Pas d'agressivité de ma part pour ce premier message, c'est juste que j'ai la chance d'être ingé informatique et d'être consultant Info et Audio-Visuel, ainsi que d'être dans l'info et l'électronique depuis 1979 Si tu veux, si tu as des questions, je pourrais te renseigner dans la mesure de mes compétences.
Bien cordialement
Nous sommes toute-ouïe !!! ce sera ma question
Concernant la quantité de ram et le cpu, ils n'ont que très peu d'incidence sur le nombre de piste en lecture temps réel ... surtout si ce sont des dsp qui effectuent la sommation (qui cela dit n'est pas la tâche la plus compliqué), et s'il n'y pas ou très peu d'fx. Idem pour la ram ... à quoi cela sert si on lit en temps réel ! a charger toute la session d'un coup .. mouai ... enfin là on parles de lecture multipiste et non de sampling ou d'instrument virtuel.
Concernant AMD, c'est vraiment à déconseiller pour de l'audio, Protools ne les supporte officiellement pas, et ça donne quelques misères sur d'autres softs, même si ce sont des bêtes de course, si ça fait bugger la machine ou s'ils ne sont pas reconnus par le soft, c'est dommage.. ! Fichu monopole.
sinon, bienvenue sur SDO !
__________TO9, GBF, Platine Teppaz, HR624, HD25, Live 8, SoundForge9, micros, oreilles, bouche, bouchons d'oreille, femme, fille, extincteur...
Tiens, c'est marrant, vous arrivez à lire aussi petit que ça ? Ouai... tricheur, c'est le zoom, la loupe, le copier-coller, ou le grand écran je sais pas...
Tiens, c'est marrant, vous arrivez à lire aussi petit que ça ? Ouai... tricheur, c'est le zoom, la loupe, le copier-coller, ou le grand écran je sais pas...
Bonsoir,
Afin de préserver la durée de vie des disques durs destinés à délivrer de l'audio multipiste, n'oubliez pas de limiter fortement les débits : 40 à 60 MO par seconde me parait être une limite à ne pas franchir par unité de disque. Personnellement je préfère 20 à 30 MO par seconde. Ces valeurs sont données pour des disques tournant à 7200tr/mn ou 10.000 tr/mn.
Cette limite, bien qu'inférieures aux publicités du marché suffit largement pour gérer 48 pistes audio enregistrer à 48kHz en 24 bits.
Cela ne s'applique pas aux SSD, évidemment.
On peut repousser le risque de problème en prenant des disques "Entreprise class".
---
En video, la limite peut etre repoussée largement au dessus de 100 MO par seconde pour le même type de disque.. Les données ne sont pas rangées de la même manière. Cela ressemble plus à une lecture séquentielle, du moins dans une hypothése de probabilité de territoire non-fragmenté.
Bien amicalement.
Afin de préserver la durée de vie des disques durs destinés à délivrer de l'audio multipiste, n'oubliez pas de limiter fortement les débits : 40 à 60 MO par seconde me parait être une limite à ne pas franchir par unité de disque. Personnellement je préfère 20 à 30 MO par seconde. Ces valeurs sont données pour des disques tournant à 7200tr/mn ou 10.000 tr/mn.
Cette limite, bien qu'inférieures aux publicités du marché suffit largement pour gérer 48 pistes audio enregistrer à 48kHz en 24 bits.
Cela ne s'applique pas aux SSD, évidemment.
On peut repousser le risque de problème en prenant des disques "Entreprise class".
---
En video, la limite peut etre repoussée largement au dessus de 100 MO par seconde pour le même type de disque.. Les données ne sont pas rangées de la même manière. Cela ressemble plus à une lecture séquentielle, du moins dans une hypothése de probabilité de territoire non-fragmenté.
Bien amicalement.
Re, effectivement, plus ce sera le/les DSP qui prendra en charge le travail, moins le PC (CPU/RAM - voire GPU maintenant) sera sollicité, c'est évident Si le PC ne limite pas, pas besoin de le booster Par contre, moi sur ma carte son, le DSP ne fonctionne qu'en 44.1/48 KHz, et moi je travaille en 88.2 KHz, tous les effets sont donc gérés par le processeur.
Quant au manque de compatibilité des processeurs AMD, je m'élève avec véhémence contre cet argument. Je ne travaille qu'avec AMD depuis 1991, et je veux dire de manière exclusive, et je n'ai jamais, jamais eu le moindre problème de compatibilité. De plus ayant fait de la maintenance pendant longtemps, pour des particuliers et entreprises, je peux vous assurer que je n'ai jamais trouvé d'autres causes concernant une mal-fonction qu'une panne matérielle ou un problème d’incompétence de configuration. Je peux t'assurer que j'ai déjà vu de nombreux protools fonctionner comme une bête sur AMD et je travaille pour ma part sur Cubase avec Un X6 4.2 GHz et un X4 4GHz sur Vista et W7 64 bits : Aucun problème de quelque ordre que ce soit :
En ce qui concerne la lecture sur un disque dur,, ça fait bien longtemps qu'un disque n'est plus contrôlé par le système et a son propre contrôleur. Le système fait des requêtes, au disque, ces requêtes viennent de plusieurs programmes en même temps et sont optimisées par le contrôleur. Dernières groooosses avancées, la perpendicularité qui augmente la densité, et le mode NCQ qui permet de gagner jusqu'à 20% sur les performances. Les contrôleurs de disque sont très évolués et gèrent plusieurs demandes de fichiers en parallèle sans problème, ils ont même un cache qui tend à s'étendre jusqu'à 64 Mo avec, avec, comme sur les processeurs des algorithmes de prédiction. Un fichier stocké sur le disque n'est pas contenu dans une seule case du disque, il est réparti sur plusieurs cases. Ces cases, appelées "Cluster" entre autres sont lues de manière optimisées en fonction des requêtes du système, de façon à ce que le bras ait le moins de déplacement à faire sur le disque et à ce que les transferts soient les plus rapides possibles. Les têtes lisent donc des clusters, mais ces clusters appartiennent à des fichiers distincts et non séquentiels. On n'est pas sur bande C'est le disque qui va déterminer quel cluster il va lire en fonction de l'arrivée des ordres de lecture/écriture (I/O) qu'il va optimiser, ayant la carte du disque en mémoire, et éviter les déplacements de tête inutiles.
Démonstration de la parallélisation de la lecture ou de l'écriture de plusieurs fichiers en même temps sur un disque ou vers un disque :
Par exemple, on copie un fichier de 2 GB de C: vers D: Puis pendant cette copie, on en lance une autre sur un fichier de 1.5 GB de C: sur E:. la vitesse de copie de C vers D va chuter, mais la copie de C vers E va démarrer pour finir à peu près en même temps suivant les capacités des disques. La seconde copie commence au moment où elle est demandée et pas après que le premier fichier ait été copié.
Cette démonstration est enfantine, je vous l'accorde, mais elle prouve bien, que deux fichiers (et même beaucoup plus) peuvent être lus/écrits en même temps sur un même disque dur. Ce qui n'est par contre pas possible, c'est la lecture simultanée de deux clusters.
PS : Alexis, j'ai lu beaucoup de choses de toi, et j'apprécie fortement tes analyses et tes connaissances, c'est un peu à cause de toi que je suis ici d'ailleurs Je vais avoir beaucoup de choses à apprendre, mais je crois que je pourrais vous apporter un peu de mon savoir aussi Je suis bien au courant que la sommation même en virgule flottante est peanut pour un processeur, et ne prends rien comme % de calcul puisque c'est une simple addition binaire.
Et secundo, pour l'augmentation de performances, il y a la possibilité d'adopter des solution RAID en SATA, SCSI ou SAS avec des débits considérables. On peut aussi mettre beaucoup de mémoire et avoir un disque en RAM.
Je reste à votre entière disposition pour toute question que vous pourriez avoir quant à mes propos
Bien amicalement à tous
Christian
Quant au manque de compatibilité des processeurs AMD, je m'élève avec véhémence contre cet argument. Je ne travaille qu'avec AMD depuis 1991, et je veux dire de manière exclusive, et je n'ai jamais, jamais eu le moindre problème de compatibilité. De plus ayant fait de la maintenance pendant longtemps, pour des particuliers et entreprises, je peux vous assurer que je n'ai jamais trouvé d'autres causes concernant une mal-fonction qu'une panne matérielle ou un problème d’incompétence de configuration. Je peux t'assurer que j'ai déjà vu de nombreux protools fonctionner comme une bête sur AMD et je travaille pour ma part sur Cubase avec Un X6 4.2 GHz et un X4 4GHz sur Vista et W7 64 bits : Aucun problème de quelque ordre que ce soit :
En ce qui concerne la lecture sur un disque dur,, ça fait bien longtemps qu'un disque n'est plus contrôlé par le système et a son propre contrôleur. Le système fait des requêtes, au disque, ces requêtes viennent de plusieurs programmes en même temps et sont optimisées par le contrôleur. Dernières groooosses avancées, la perpendicularité qui augmente la densité, et le mode NCQ qui permet de gagner jusqu'à 20% sur les performances. Les contrôleurs de disque sont très évolués et gèrent plusieurs demandes de fichiers en parallèle sans problème, ils ont même un cache qui tend à s'étendre jusqu'à 64 Mo avec, avec, comme sur les processeurs des algorithmes de prédiction. Un fichier stocké sur le disque n'est pas contenu dans une seule case du disque, il est réparti sur plusieurs cases. Ces cases, appelées "Cluster" entre autres sont lues de manière optimisées en fonction des requêtes du système, de façon à ce que le bras ait le moins de déplacement à faire sur le disque et à ce que les transferts soient les plus rapides possibles. Les têtes lisent donc des clusters, mais ces clusters appartiennent à des fichiers distincts et non séquentiels. On n'est pas sur bande C'est le disque qui va déterminer quel cluster il va lire en fonction de l'arrivée des ordres de lecture/écriture (I/O) qu'il va optimiser, ayant la carte du disque en mémoire, et éviter les déplacements de tête inutiles.
Démonstration de la parallélisation de la lecture ou de l'écriture de plusieurs fichiers en même temps sur un disque ou vers un disque :
Par exemple, on copie un fichier de 2 GB de C: vers D: Puis pendant cette copie, on en lance une autre sur un fichier de 1.5 GB de C: sur E:. la vitesse de copie de C vers D va chuter, mais la copie de C vers E va démarrer pour finir à peu près en même temps suivant les capacités des disques. La seconde copie commence au moment où elle est demandée et pas après que le premier fichier ait été copié.
Cette démonstration est enfantine, je vous l'accorde, mais elle prouve bien, que deux fichiers (et même beaucoup plus) peuvent être lus/écrits en même temps sur un même disque dur. Ce qui n'est par contre pas possible, c'est la lecture simultanée de deux clusters.
PS : Alexis, j'ai lu beaucoup de choses de toi, et j'apprécie fortement tes analyses et tes connaissances, c'est un peu à cause de toi que je suis ici d'ailleurs Je vais avoir beaucoup de choses à apprendre, mais je crois que je pourrais vous apporter un peu de mon savoir aussi Je suis bien au courant que la sommation même en virgule flottante est peanut pour un processeur, et ne prends rien comme % de calcul puisque c'est une simple addition binaire.
Et secundo, pour l'augmentation de performances, il y a la possibilité d'adopter des solution RAID en SATA, SCSI ou SAS avec des débits considérables. On peut aussi mettre beaucoup de mémoire et avoir un disque en RAM.
Je reste à votre entière disposition pour toute question que vous pourriez avoir quant à mes propos
Bien amicalement à tous
Christian
Merci de ces précision Tharkie.
Mais je trouve que ta démonstration "enfantine" (mais toutes les grandes théorie se base sur des démonstrations enfantines... la pomme de Newton à tout de même permis à l'homme de marcher sur la Lune) ne fait que conforter en moi l'aspect séquentiel de l'accès au disque (il me semble d'ailleurs qu'il y a des notions de sémaphores dans les opérations sur disque dur).
Tu précises bien que lorsque l'on déclenche la seconde copie, le taux de transfert de la première copie chute. C'est donc que les opérations ne se font pas en parallèles, mais successivement.
Entendons nous bien : par opération je veux dire "micro copies de bout de fichier" et non copie de l'intégralité du fichier.
Si les accès pouvaient se faire réellement en parallèle, la durée des opérations ne devraient pas être interdépendantes.
Après, n'étant pas informaticien, peut-être est-ce un problème de lexique ou de définition des termes utilisés.
Mais je trouve que ta démonstration "enfantine" (mais toutes les grandes théorie se base sur des démonstrations enfantines... la pomme de Newton à tout de même permis à l'homme de marcher sur la Lune) ne fait que conforter en moi l'aspect séquentiel de l'accès au disque (il me semble d'ailleurs qu'il y a des notions de sémaphores dans les opérations sur disque dur).
Tu précises bien que lorsque l'on déclenche la seconde copie, le taux de transfert de la première copie chute. C'est donc que les opérations ne se font pas en parallèles, mais successivement.
Entendons nous bien : par opération je veux dire "micro copies de bout de fichier" et non copie de l'intégralité du fichier.
Si les accès pouvaient se faire réellement en parallèle, la durée des opérations ne devraient pas être interdépendantes.
Après, n'étant pas informaticien, peut-être est-ce un problème de lexique ou de définition des termes utilisés.