Полигон-2

Fe-Restorator написал:

[q]

перепиши файл на 2 гига с винча IDE master на винч IDEslave (оба на одном канале) и сравни результат с перезаписью того-ж файла с IDEmaster на IDEsecondarymaster (разные каналы).

[/q]

И так понятно, что два винта разделят полосу пропускания канала на 2 Это значит, что нужно вешать винты на разные каналы, а сидюки, которые даже в лучшие свои времена использовались для массированной перекачки данных лишь эпизодически, наоборот цеплять слейвами к винтам. Хотя если IDE-устройства всего 2: винт и сидюк, то конечно лучше на разные каналы.

Fe-Restorator написал:

[q]

сидюки-слейвы одинаково сильно глючили на всех PIIX, вплоть до 5-го

[/q]

PIIX закончились на 4E - 5-й был только в планах, отменённых в пользу ICH. И глючили только первые сидюки - этак до 6 скоростей - скорее из-за детских болячек ATAPI или быть может маленького буфера, т.е. по вине сидюков, а не IDE-контролеров. Более новые, даже работая в PIO - хотя умели и DMA, уже не глючили. Т.е. бэдов на винте из-за не читаемого сидюка например не возникало.

DrPass написал:

[q]

Ну чего ж миф-то?

[/q]

Потому, что необходимости как таковой нет, ибо глючить не будет. Тем паче, что во времена актуальности сидюков, самой распространённой системой была винда 9х, которая вставала колом по любому поводу. Например, если сидюк не читался, всё замирало совершенно независимо от способа его подключения.

Anderson1 написал:

[q]

Потому, что необходимости как таковой нет, ибо глючить не будет. Тем паче, что во времена актуальности сидюков, самой распространённой системой была винда 9х, которая вставала колом по любому поводу. Например, если сидюк не читался, всё замирало совершенно независимо от способа его подключения.

[/q]

Про глюки никто и не говорил, это вопрос исключительно производительности системы. Тем более что типичный сценарий работы с сидюком - не ветер им разгонять в приводе, а что-то копировать с него на винт. Естественно, это лучше делать, когда винт и сидюк на разных каналах.
Кстати, Win98 SE достаточно толерантно относилась к ошибкам чтения CD. По крайней мере, в гадкий синий экран, как 95-я, не вылетала.

Fe-Restorator0 написал:

[q]

пропадали из системы, как девайс, аккурат посередине чтения диска (Plextor-ы)

[/q]

Дохлый БП или порченые молексы, т.е. проблемы с питанием. Про гнилой IDE-шлейф можно вообще промолчать...

Fe-Restorator написал:

[q]

не желали читать совершенно нормальный диск (Pioneer-ы, Yamaha-и)

[/q]

Может диск был не очень нормальный?

Fe-Restorator написал:

[q]

отказывались играть аудио-цд через IDE-интерфейс

[/q]

Это вовсе чушь: аудиосиди проигрываются через аналоговые выходы - на морде и сзади. Через IDE они ничего не проигрывают. Так что можно подцепить привод с кнопкой play прямо к бп и спокойно слушать музыку в наушниках.

Fe-Restorator написал:

[q]

Самсунги - вообще непредсказуемые, волшебные ребята

[/q]

А ещё они очень хорошо ломались - т.с. "дятлы" тогдашнего сидюкостроения

DrPass написал:

[q]

типичный сценарий работы с сидюком - не ветер им разгонять в приводе, а что-то копировать с него на винт.

[/q]

Да нет. Типичный это слушать аудиосиди, что происходит вовсе автономно от системы, в крайнем случае MP3, или играть в игрушку - когда что-то подгружается в память, без участия винта. Если не считать свопинг конечно. Ну или смотреть кино - хоть VCD, хоть DivX/XviD/MPEG4, что снова винт выводит за скобки.

Fe-Restorator написал:

[q]

EAC читает диски по аудиошнурку от наушников на заднице.

[/q]

Это не проигрывание аудиосиди, а грабление:

Exact Audio Copy is a so called audio grabber for CDs using standard CD and DVD-ROM drives.

DrPass написал:

[q]

На самом деле у сидюка есть и аналоговое воспроизведение, и цифровое. Через IDE.

[/q]

Это не воспроизведение у сидюка, а т.с. програмная эмуляция - плейер просто считывает данные, обрабатывает налету и т.о. проигрывает силами ЦПУ системы. Сидюк при этом ничего не проигрывает.

Anderson1 написал:

[q]

Это не воспроизведение у сидюка, а т.с. програмная эмуляция - плейер просто считывает данные, обрабатывает налету и т.о. проигрывает силами ЦПУ системы. Сидюк при этом ничего не проигрывает.

[/q]

Что значит "программная эмуляция"? Плейер ничего не считывает, этим занимается драйвер CD-ROM, который использует аппаратную поддержку такого режима воспроизведения со стороны привода. На плейер идет уже готовый звуковой поток 44кГц. Да и вообще, как это понимать, воспроизведение-не воспроизведение. Музыка играет - значит, воспроизведение. Разве прослушивание mp3-файлов не является воспроизведением?

Anderson1, фактически, CD-ROM отправляет плееру уже готовый 44 кГц PCM, так что последнему остаётся просто передать его на звуковую карту. Думаю, этот процесс вполне можно назвать воспроизведением, многие плееры такой режим поддерживают и т.п.
Тем более, что на CD-ROM'ах под это дело даже бывает дополнительный цифровой выход S/PDIF, который и правда, наверное, можно подключить напрямую к звуковухе.

До сих пор держу старенький 4-х скоростной креативовский ЦД-привод (лейбл "Quad Speed" на морде), у которого есть одновременно и аудио-выход под шнурок, и SPDIF выход (коакс) и IDE для связи с мамкой. Привод играет аудиоцд одновременно по всем трём интерфейсам! Более того, SPDIF выход у этого привода ещё не оболванен всякой копилефтией, и передаёт чистый, ничем не обработанный сигнал напрямую в TBS Pinnacle. У более современных приводов этот выход программно загрублён, ограничен по частотной полосе аудиосигнала, в угоду той самой копилефтии.

Попробуйте только назвать сие полным невоспролизведением цд!


uav1606 написал:

[q]

фактически, CD-ROM отправляет плееру уже готовый 44 кГц PCM

[/q]

Именно так. Цифровой цд-сектор очищается от шелухи цд-формата самим приводом, им-же примешивается некоторая "цифровая помеха" (на поздних приводах, с копилефтией inside), выравнивается по границе слова (обычно - за счёт кеша) и передаётся в мамку. Та переправляет данные в прогу пляйера/её кеш и затем на звуковую карту. Программный плйер не занимается конвертацией секторов цд в сектора "а-ля hdd", и не занимается очисткой потока от сервисной инфы. У него иная задача. Программный пляер обязан кешировать часть полученного потока на случай "перемотки", и поддерживать своевременный обмен с аудиокартой.

Именно на сей случай и создан EAC: обойти цифровую копилефтию, встроенную в привод. Попытаться считать диск тупо-посекторно, и уже внутри EAC-а программно провести очистку сигнала от шелухи форматов, и прочего, уже перечисленного!


DrPass написал:

[q]

этим занимается драйвер CD-ROM, который использует аппаратную поддержку такого режима воспроизведения со стороны привода

[/q]

Драйвер сидюка не занимается конвертацией RaW audio потока в WAV PCM! Его задача - забрать цифру из кеша привода, закешировать её в RAM и выдать процу по первому его требованию. Именно процу, он перегонит инфу в пляер/кеш пляера, и затем в карточку.
Драйверу сидюка вообще по-шарабану, какой диск вставлен в привод! Он может лишь принять от привода сигнал "вставлен диск типа ХХХYYY" и передать эту инфу в ОС. Не более. Никакого собственного интеллекта.
C другой стороны, сам драйвер цд является веской причиной поместить привод мастером на отдельный канал IDE. Иначе - он мешает биосу/ОС общаться с винтом, влезая поперёк процесса обмена данных. Поначалу из-за этого портилась инфа на винче, позже - осталось лишь торможение обмена инфой на канале.

Anderson1 написал:

[q]

Это не воспроизведение у сидюка, а т.с. програмная эмуляция - плейер просто считывает данные, обрабатывает налету и т.о. проигрывает силами ЦПУ системы. Сидюк при этом ничего не проигрывает.

[/q]

Бред. Перечитай этот пост с начала, особенно внимательно - часть в ответ камраду DrPass.

uav1606 написал:

[q]

Что-то не понял эту сентенцию.

[/q]

Про генерацию прерываний не забудь. Драйвер сидюка их перехватывает (всегда), распознаёт а-ля "ах, это не моё" и возвращает винчу+ОС. Но времени(и ресурсов) на разруливание коллизии уходит немало, независимо от и в плюс ко торможению из-за шаринга линий данных.
А если в привод вставить заведомо глючный блин, то передача данных с винчом встанет на долгие минуты, покуда вклинившийся драйвер не опросит привод, не получит от него отбой, а тот не выдаст сигнала, покуда не завершит 100500 попыток чтения дефектного блина.
С другой стороны, разным каналам назначены разные прерывания, драйвер сидюка не перехватывает у винча ничего (как вариант, не видит винча вообще, ибо перехватывает совсем другое прерывание), коллизий не происходит. Заодно нет и шаринга линий данных.
Совсем современные ОС научились справляться с такими вещами и избегать коллизий, например, блокируя драйвер цд на время операций с винчом, благо драйвера - есмь часть самой ОС. Но это программный "костыль" и принципов не меняет. Стоит юзеру вставить/запустить аудио-цд одновременно с долгой архивацией длинного файла - хрип и заикания обеспечены, ибо костыль стал неэффективен.

Хорошо, что IDE ушёл в тору, бесконечно выбирать меж быстрой перезаписью меж винчами и отсутствием помех от цд-приводов - надоело. SATA уравнял в правах все типы приводов. Да, цыдюки всё-ещё тормозят дисковую подсистему собственной медлительностью, но уже не мешают одновременной скоростной перезаписи меж винчами. Здесь начинает играть роль тот факт, на котором контроллере подвешен винч-приёмник инфы. Чисто чтобы не был забит канал передачи данных внутри самого чипа контроллера.
Если три винча подвешены к одному сата-контроллеру, а ещё винч(или сидюк) - к другому сата-контроллеру, и скоростная перезапись ведётся меж первыми двумя винчами первого контроллера, то скорость этой передачи упадёт, если на третий винч начать переливать инфу со второго контроллера, неважно, с какого источника.

uav1606 написал:

[q]

С аудио-CD могут быть тормоза только если воспроизведение идёт через IDE

[/q]

Так, речь как раз об IDE.
Со шнурками всё скучно до обыденности: воткнул - есть звук, вынул - нет звука, вывернул разъём - спалил привод.
uav1606 написал:

[q]

Прерывания, вообще говоря, разруливает драйвер контроллера, а не конкретно драйвер CD или винта. А он уже решает, чьё это прерывание и что с ним делать.

[/q]

Как драйвер сидюка вклинивается в управление контроллером? Как надстройка над драйвером контроллера! Так-что прерывания он перехватывает, всегда. И UDMA-запросы он тоже всегда перехватывает. Другое дело, ОС может временно запретить ему своеволие, в некоторых пределах.

uav1606 написал:

[q]

И надстройка эта получает управление только при необходимости, когда идёт обмен данными с CD.

[/q]

Увы, вертикальную (луковую) модель прохождения данных сквозь надстройки над контроллерами - никто не отменял (кроме SATA).

Драйвер сидюка обволакивает собой драйвер IDE и добраться к последнему, не затронув драйвер сидюка - невозможно. Иными словами, драйвер IDE внедряется в драйвер сидюка и становится его неотъемлемой частью.
uav1606 написал:

[q]

достаточно глянуть на ресурсы в Диспетчере устройств - у контроллера они перечислены (порты, IRQ и т.п.), а в ветке с приводами у CD\DVD никаких ресурсов нет.

[/q]

Если присмотришься внимательнее - драйвер есть у каждого из каналов IDE. Если привод с винчом висят на одном шлейфе, драйвер сидюка обернёт драйвер этого канала и постоянно будет мешать. Если привод висит отдельно на втором канале, драйвер сидюка "пожрёт" драйвер только второго канала, и мешать будет только ему. Винчи на первом канале будут свободны от влияния драйвера цд.
CD/DVD ресурсы не нужны, оные полностью пожирают ресурсы канала IDE.

Fe-Restorator написал:

[q]

Драйвер сидюка обволакивает собой драйвер IDE и добраться к последнему, не затронув драйвер сидюка - невозможно. Иными словами, драйвер IDE внедряется в драйвер сидюка и становится его неотъемлемой частью.

[/q]

Только что на ходу сочинил, верно?

Fe-Restorator написал:

[q]

Увы, вертикальную (луковую) модель прохождения данных сквозь надстройки над контроллерами - никто не отменял (кроме SATA).
...
Драйвер сидюка обволакивает собой драйвер IDE и добраться к последнему, не затронув драйвер сидюка - невозможно. Иными словами, драйвер IDE внедряется в драйвер сидюка и становится его неотъемлемой частью.

[/q]

Пруфлинк, пожалуйста. :-) Я не вижу причин, почему драйвер CD должен обрабатывать прерывания, а тем более кого-то "обволакивать". Тем более, что в Win 9x драйвера CD-ROM как такового вообще нет. У меня, например, в Диспетчере устройств она для всех оптических приводов пишет, что для это устройства не установлены драйверы, при этом всё работает отлично. Там есть только драйвер контроллера и отдельных каналов.
Даже если драйвер CD кого-то "обволакивает", обрабатывать прерывания всё равно будет "ядро" - драйвер контроллера.