Форум » Общие вопросы по SyMon » Первый цилиндр » Ответить
Первый цилиндр
Lenchik: Хочу поставить Symon 3.22 на первую дорожку, но на всякий случай иметь свободным весь первый цилиндр или нулевой, если у него нумерация с нуля. Диск собираюсь бить partition magic 8 с дискетки. Как мне определить размер этого цилиндра? (8 мб из документации - как-то расплывчато - плотность записи-то постоянно увеличивается) Samsung SP2504C SATA, LBA 488397168 написано на диске. Если приведете цифру конкретную, спасибо, но еще хотелось бы видеть формулу для расчета (чтобы на других винтах применять - друзья на Симон тоже хотят перейти) да и про первую дорожку тоже не помешало бы знать подобную инфу P.S. Как-то странно форум работает - логинится через страницу - постить не хочет через раз...
Ответов - 11
Cергей: Саймон работает с логическими дорожкам/головками. Современный винт имеет мало голов и тучу дорожек, а логически видны как 255 голов, 63 сектора. Кстати, Саймон (проф 3.22) на одну дорожку не входит :-(
Vladimir Dashevsky: Кстати, я тут в процессе возни с новым стандартом сжатия видео H.264, обнаружил, что в нем есть весьма хороший арифметический компрессор, который обладает весьма простым алгоритмом декомпрессии. Декомпрессор имеет все шансы уместиться в одном секторе (MBR), а по степени сжатия по предварительным данным он не уступает RAR'у. Вполне вероятно, что им можно дожать последний SyMon, чтобы он влезал в нулевую дорожку.
omgFiRE: Vladimir Dashevsky а по степени сжатия по предварительным данным он не уступает RAR'у Сравнение некорректное. Можно рассмотреть 3 типа сжатия: 1) Энтропийное. Пусть сообщение над алфовитом S={a1,a2,...,aM}. Сообщение длиной N симвоолов. i-й симовол встречается qi раз. Тогда вероятностью символа ai в сообщении назовём величину qi/N (частоту). Рассмотрим величину R=сумма по i [-pi * log (pi)]. Это количество бит на символ в среднем. Пример: сжатие Хаффмана пусть есть алфавит S={a,b,c} с вероятностями 0.5 0.25 0.25 Делим на две кучи с равными вероятностями: {a},{b,c} Первой куче даём ведущий бит 0, другой 1. Делим вторую кучу дальше (первую дальше делит ненадо - там 1 симовол): {b},{c} Первой подкуче даём второй бит 0, другой 1. Итого: a=0 b=10 c=11 Величина R=log(2)/2+log(4)/4+log(4)/4=3/2. Т.е. в среднем при таких вероятностях на храниение одного символа уйдёт полтора бита. Сообщение "abac" будет закодировано как "010011" т.е. 4 симола закодируются 6 битами (так и есть - полтора бита на символ). Идея сжатия: часто появляющимся символам даём короткие кодовые последовательности и на этом экономим. А если бы мы от балды начали кодировать как a=00,b=01,c=10. Тогда ушлобы не 6 бит, а 8. Сжатие Хаффмана очень простое (надо лишь рекурретно делить на 2 группы с равными вероятностями), даёт неплохое сжатие, но когда неудаётся разложить в дерево Хаффмана симолы, чтобы всегда вероятность делилась поровну - не получается в точности достичь степени сжатия по формуле для R (количество бит на символ). В арифметическом сжатии возможно в точности достичь величины R, для любого сообщения (например если алфавит из 2-х символов {a,b} с вероятностями в сообщении 0.8 и 0.2), то Хаффман не сможет сжать в отличии от арифметического. Для определения на сколько сожмёт арифметичкое сжатие, можно сказать заранее: достаточно подсчитать частоту встеречи каждого символа, рассчитать R и умножить на длину сообщения. Размер алфавита (количество симолов) зависит от того, по сколько бит будем брать за раз: если брать по 1 биту, то 2-х буквенный алфавит Если по байту - то 256 различных символов А можно брать и по 2 байта за раз, тогла алфовит будет состоять из 65536 символов. В алгоритме JPEG после Дискретного Косинусного Преобразование (DCT) и после квантизации, коэффициенты запаковываются Хаффманом. В алгоритме JPEG2000 после Вейвлет Преобразование (Wavelet) и после квантизации, коэффициенты запаковываются алгоритмическим сжатием. Ну про MPEG AVC сам знаешь. Подробнее про арифметичекое можно найти тута: http://www.sdteam.com/texts/23/717.zip вроде расписано понятно вплоть до кода 2) Словарное Ищем повторяющиеся участки, заносим их в словарь и при следующей встрече не пишем этот участок, а ссылаемся на словарь. Идея проста, но в отличии от Энтропийного сжатия нет математически доказанных алгоритмов выбора словаря и гарантий на сжатие. При Энтропийном можно заранее сказать на сколько сожмётся сообщение. В словарном в зависимости от удачности выбора сжатия словаря в конкретном случае. Очевидно можно придумать тест (напрмер взять алфавит и повторять его без конца: abcabcabc...) Энтропийное сжатие его не сможет сжать (вероятности встечи всех символов равны, так как их одинаковое количество) А вот словарное сжатие такой тест сожмёт очень сильно. На другом тесте соотношение сжатий словарного/энтропийного может быть в точности наоборот. Потому сравнивать их неразумно. (WinRAR VS арифметическое) 3) Антисловарное Предположим мы просмотрели всё сообщение и заметили, что оно не содержит подстроки (например aaabba). Но если уменьшить это антислово на 1 символ, то то оно уже будет сожержаться в сообщениии (т.е. aaabb в сообщении есть). А ну ещё предположим, что алфовит состоит из 2-х символов (рассматриваем биты). Если встретили "aaabb", то следующий символ точно будет "b" т.к. всего два символа, но "a" быть не может, т.к. вначале было замечено, что сообщение не сожержит "aaabba". А раз точно знаем, что будет "b", то можно его и не писать. Таким образом вместо "aaabbb" везде в сообщении пишем "aaabb". Таким образом 1 антислово экономит 1 бит для каждого подслова полученного из антислова без последней буквы. Если количество таким образом сыкономленых бит больше, чем требуется на включение антислова в антисловарь (антисловарь ведь тоже надо хранить и передавать с урезанным сообщением), тогда использование данного антислова сжимает сообщение и его надо использовать. На данный момент алгоритмы антисловарного сжатия не дотягивают до словарного сжатия (по степени сжатия) в среднем (хотя конечно можно придумать пример (последовательность Туе-Морса) при котором антисловарное лучше сожмёт, чем словарное)
Lenchik: А самому математически посчитать исходя из данных биоса или еще какой-нибудь утилиты (пусть даже в симоне открыв и просмотрев, не переразмечая в редакторе) нельзя? Чтобы потом это количество килобайт или мегабайт не занимать партишн мэджиком.
omgFiRE: Lenchik А самому математически посчитать исходя из данных биоса или еще какой-нибудь утилиты (пусть даже в симоне открыв и просмотрев, не переразмечая в редакторе) нельзя? Чтобы потом это количество килобайт или мегабайт не занимать партишн мэджиком Описание LBA трансляции
Lenchik: Так из этой формулы нужно получить выражение для количества цилинров? CYL (конечно, возможно туплю, но...)?
omgFiRE: Lenchik В той формуле при LBA трансляции (Смотри установки BIOS): CYL=1 (тебя интересует адрес первого цилиндра, я так понял) HDS=вычисляешь по указанному алгоритму (от размера жёсткого диска) или спрашиваешь у BIOS. HD=0 (нулевая головка) SPT=63 (всегда при LBA) SEC=1 (видимо нужен первый сектор). Итого: LBA=(1*HDS+0)*63+1-1=HDS*63 Таким образом чтобы узнать адрес первого цилиндра в байтах при LBA трансляции: смотрим количество головок в BIOS, умножаем на 63 (количество секторов), умножаем на 512 (байт в секторе). А вообще я бы разметил через SyMon, т.к. Partition Magic сам дополнительно выравнивает границу раздела по какому-то значению (т.е. если скажешь начинать раздел с первого цилиндра он возможно начнёт его со второго цилиндра). PS Дискетный PM умеет переразмечать разделы?
Lenchik: Спасибо. Попробую - расскажу что получится. Мне давным давно дали дискетку (1) от PM 8 (я так понял часть rescue disc). Она не загрузочная. Соответственно сначала загрузочную - потом эту. Запускаем pqmagic и можем метить как хотим и что хотим. А стандартным ПМ не пользовался никогда.
Vladimir Dashevsky: omgFiRE Мне казалось, что Rar имеет по умолчанию именно алгоритм арифметического сжатия. Но вообще, как бы там ни было, нужен не просто передовой алгоритм с точки зрения теории сжатия, а именно такой, у которого реализация компактна. У меня был пример арифметического сжатия еще тогда, когда мы разрабатывали упаковку кода SyMon. Жал он заметно лучше LZSS, но при этом было совешенно нереально реализовать это на ассемблере в одном секторе. CABAC из H.264 поразил мена именно тем, что реализация декодера оказалась весьма простой. По крайней мере, на AVR она у меня получилась очень компактной, правда небыстрой для 8 МГц. Вот и возникла мысль попробовать сжать SyMon этим способом. Бюджет правда для кода маловат. Из 512 байт 80 идет на таблицу разделов с сигнатурами. 256+64 - на таблицы CABAC, итого 400 байт. В отавшиеся 112 байт надо уместить всё считывалку с диска и алгоритм арифметического декомпрессора. :) Не влезет, скорее всего...
Vladimir Dashevsky: Lenchik Так формула же есть в документации PDF.
cousin: А зачем пытаться уместить декодер в MBR? Можно же в любом другом месте дорожки.
полная версия страницы