LINUX.ORG.RU

История изменений

Исправление ifajoev_giasid, (текущая версия) :

Ребятушки, я ведь не просто так решил, что должно быть лучше. Я слышу разница, когда меняешь RT-приоритеты у AHCI. Это значит, что все таки жесткий диск влияет, несмотря на заверения теоретиков, что сначала данные попадают в память. К тому же, память - это не только планка памяти, но и своп-файл, который тоже на жестком диске. То есть, получается частично данные с диска копируются и с него на него и читаются потом (просто с системного раздела), с задержками на чтение. А так как системный раздел расположен физически в другом месте, нежели музыка, то возникают задержки из-за механической конструкции жесткого диска. К слову, у меня всего 2гб оперативы, и встроенная видеокарта, поэтому оно так и происходит.

Представьте, мы считываем из «памяти» постоянно фрагментами, а на самом деле считываем с диска из своп файла, а в это время приходит время считывать кусок на разделе с музыкой. Головка будет скакать туда-сюда, в итоге, задержки там (на разделе с музыкой из-за NTFS) будут мешать нам на системной разделе читать из своп файла!

А насчет внешнего жесткого диска - тут другая проблема usb, а юсб и так будет занят звуковухами, еще и данные с жесткого гонять.

Исправление ifajoev_giasid, :

Ребятушки, я ведь не просто так решил, что должно быть лучше. Я слышу разница, когда меняешь RT-приоритеты у AHCI. Это значит, что все таки жесткий диск влияет, несмотря на заверения теоретиков, что сначала данные попадают в память. К тому же, память - это не только планка памяти, но и своп-файл, который тоже на жестком диске. То есть, получается частично данные с диска копируются и с него на него и читаются потом (просто с системного раздела), с задержками на чтение. А так как системный раздел расположен физически в другом месте, нежели музыка, то возникают задержки из-за механической конструкции жесткого диска. К слову, у меня всего 2гб оперативы, и встроенная видеокарта, поэтому оно так и происходит.

Если использовать fat32, то мы убираем задержку во время чтения. Пока играет музыка, эти данные считываются кусками. То есть, за одну песню если все задержки сложить, то получатся сотни миллисекунд или даже секунды. Это все не играет на пользу!!! Но это только по моей теории! Представьте, мы считываем из «памяти» постоянно фрагментами, а на самом деле считываем с диска из своп файла, а в это время приходит время считывать кусок на разделе с музыкой. Головка будет скакать туда-сюда, в итоге, задержки там (на разделе с музыкой из-за NTFS) будут мешать нам на системной разделе читать из своп файла!

А насчет внешнего жесткого диска - тут другая проблема usb, а юсб и так будет занят звуковухами, еще и данные с жесткого гонять.

Исходная версия ifajoev_giasid, :

Ребятушки, я ведь не просто так решил, что должно быть лучше. Я слышу разница, когда меняешь RT-приоритеты у AHCI. Это значит, что все таки жесткий диск влияет, несмотря на заверения теоретиков, что сначала данные попадают в память. К тому же, память - это не только планка памяти, но и своп-файл, который тоже на жестком диске. То есть, получается частично данные с диска копируются и с него на него и читаются потом (просто с системного раздела), с задержками на чтение. А так как системный раздел расположен физически в другом месте, нежели музыка, то возникают задержки из-за механической конструкции жесткого диска. К слову, у меня всего 2гб оперативы, и встроенная видеокарта, поэтому оно так и происходит.

Если использовать fat32, то мы убираем задержку во время чтения. Пока играет музыка, эти данные считываются кусками. То есть, за одну песню если все задержки сложить, то получатся сотни миллисекунд или даже секунды. Это все не играет на пользу!!! Но это только по моей теории!

А насчет внешнего жесткого диска - тут другая проблема usb, а юсб и так будет занят звуковухами, еще и данные с жесткого гонять.