А еще бывают такие заказчики, над которыми тяготеет злой рок. Я когда работал в интеграторе, у нас такой был. Причем и люди — хорошие, и заказчик интересный, с деньгами, и обижать его ну совершенно никаких нет желаний. Однако, если какие-то факапы и пролеты возможны, то они при работе с ним случаются. Если раз в полгода застревает груз на таможне и срываются сроки — будьте уверены — это груз для [имяневезучегоклиента], если накосячил стажер — это снова с ним.
Я не знаю отчего так происходит, но вот есть такие шлимазлы среди клиентов, которым постоянно не везет и все возможные шишки — на них.
Они, разумеется, считают, что виноваты интеграторы.
Цифровой сигнал на частотах, близких к частоте дискретизации, как правильно заметили ниже, имеет форму, далекую от синусоиды, а значит дает кучу гармоник и субгармоник, так делать нельзя, вы слышите не тон, а гармоники.
Мерять надо либо аналоговым генератором, либо генератором с заведомо более высокой, в разы, частотой дискретизации.
Сама система устроена следующим образом: на домах, столбах и прочих высоких сооружениях устанавливаются направленные микрофоны, которые улавливают все звуки. Акустическая точка, если так можно выразиться, оснащается соответствующим ПО, проводящим предварительную идентификацию резких звуков, а также GPS, что позволяет точно указать место, где производился выстрел
Как раз НЕнаправленные. А точка выстрела вычисляется путем сравнения задержек и уровня сигнала, приходящих с нескольких регистрирующих точек, путем хорошо известных методов триангуляции, применяемой, например, в GSM-геолокации.
Главная причина такой ситуации с освоением космоса в мире — дороговизна. Даже, если бы освоение велось совместными силами, денег тратить бы пришлось уйма.
Нынешние ракеты и вывод их на орбиту слишком затратны.
Читаешь эти утверждения в соседнем окне со статьей про Сочи, допустим, и испытываешь, м-м… странные ощущения.
Про Гугл, кстати, точно ничего не известно, вот не надо. Гугл компания большая и засекреченная, и никто точно не знает, как именно и где у них данные хранятся, а сведения трех-четырех летней давности могут безнадежно устаревать.
Кластеры Hadoop это все еще экзотика, а не массовое применение, и это вообще специальная область. Я так понимаю, что для них вообще нет смысла делать общее сетевое хранилище резервных копий, а нужен (если нужен) локальный драйв, а не SAN-библиотека.
Плюс не забываем про распараллеливание, соответственно и восстановление будет быстрее чем с одной ленты.
Это сразу увеличивает стоимость решения минимум на стоимость еще одного драйва и еще более усложняет картину. На самом деле проблема лент совсем не в скорости записи или считывания с одной ленты, скорее даже, парадоксальным образом, наоборот, эта скорость бывает слишком велика. Именно для этого используют мультиплексирование, запись на одну ленту бэкапов сразу от нескольких клиентов, так как ленты (в отличие от дисков, кстати) требуют постоянный поток данных максимальной скорости, иначе начинается крайне невыгодный старт-стопный режим работы, тратяший время и изнашивающий ленту.
Говоря про медленность процесса я имел ввиду не скорость чтения копии, а процесс загрузки-выгрузки кассет с лентой.
Представьте, что у вас есть кассета (кассеты) с еженедельным full backup, сделанная в субботу. А потом вы делаете incremental каждый день. И у вас случилась авария, допустим, в пятницу утром. Значит вам надо сперва загрузить ленты full, прочитать их и восстановить на диски целевой системы. Пожужжать роботом, выгрузить эти ленты (или поморгать лампочкой, и дождаться, пока ленту вынет оператор в нероботизированной системе), загрузить ленту для понедельника, промотать ее до нужного места, где хранятся измененные данные за понедельник для этой системы. Считать, вынуть ленту. Вставить ленту для вторника, помотать…
При этом для дисков вы можете сразу читать нужные фвйлы.
Я ни разу не встречал хотелки бизнеса, отличные от «чем скорее — тем лучше» и «чем меньше потери — тем лучше». Потом их обычно удается умять, но начинают всегда с 0/0.
Просто потому, что они перестали быть интересны малому-среднему бизнесу. Диски объективно удобнее. И это послужило поводом полного вытеснения их в «энтерпрайз», с соответствующим ценником (и ценообразованием).
Бэкап — это задача, для которой скорость восстановления — критически важна. Можно считать даже, что это вообще самый важный параметр такого процесса как «резервная копия» — скорость, с которой из этой копии можно восстановить исходное состояние данных на оригинальном носителе.
И тут устройство с линейным, последовательным характером доступа к данным уже изначально проигрывает. Оно просто, как вы заметили, принципиально хуже.
Вам никогда не доводилось восстанавливать большой бэкап с лент из Full + цепочки Incremental, особенно если они с интерливингом и на разных лентах? Очень веселый и неторопливый процесс.
И еще «веселее» он становится, когда выясняется, что одна из лент сета не читается, или читается с проблемами (или вовсе повредилась при загрузке, такое бывает не так редко, увы). RAID-то нет, в отличие от дискового массива. «Умерла — значит умерла».
Все это не столь важно для архивов, которые, обычно, «данные write-only», но для бэкапов это все критически важно. И если у вас не оборудование времен прошлого века, на сегодня нет ни одной реальной причины использовать ленты именно для бэкапа.
Я вот суперстар, и помню, как все ржали на WinCIH: «Что? Вирус, приводящий к аппаратной неработоспособности? Буагага! Помним-помним, как же, байку про „вирус“, который вводил в резонанс коромысла HDD, и тем самым царапал блины (действительно ходила такая байка незадолго до Чиха, оказавшаяся фэйком), такая же чушь.» И вот, настал день Ч., и в сервисы понесли косяком мамки со стертыми БИОСом…
Все было уже не так весело, особенно с впаянными чипами. Это уж потом появились DualROM и аппаратная перемычка отключения записи.
ленточные библиотеки остаются важнейшим средством резервного копирования и долгосрочного архивирования.
Вы совершенно напрасно сливаете в одном предложении через запятую два разных процесса и два разных понятия. Важнейшим средством резервного копирования ленты НЕ являются, (наконец, и слава Труду), а архивного хранения — да, являются, и там им и место.
Но это две разные области применения, принципиально отличающиеся по своим требованиям к медиа и методам.
В данном случае, как я понимаю, это будет возникать из-за деформаций мембраны динамика, то что там упоминается как «Subharmonics can be produced by signal amplification through loudspeakers», то есть эти частоты могут порождаться уже непосредственно конструкцией динамика, и не присутствовать в самом сигнале.
Я так понимаю, что это именно то, что ответственно за «а я слышу разницу в звуке тарелочек через усилитель с границей 20 kHz и границей 45 kHz», то есть человек слышит не звук выше 20, а какие-то вот эти самые субгармоники, порождаемые звуком в неслышимом диапазоне, и оказывающиеся «внизу».
Порог есть, но, во-первых не забывайте, что вы приводите данные для студийных микрофонов, первый — конденсаторный с большой (и массивной) мембраной, второй — электродинамический «вокальник», которому высокие частоты не нужны вовсе. К тому же у обоих наверняка есть обрезной фильтр для отрезки помех.
В компьютере же стоит электретный (тот же конденсаторный по принципу, а значит очень чувствительный на ВЧ), но с очень маленькой, а потому малоинерционной мембраной.
Но на самом деле это даже не столь важно, тут ниже мы уже еще один вариант обнаружили — первая субгармоника, образующая для несущей 35 kHz при воспроизведении на динамике, окажется в диапазоне 17,5 kHz, которую уже не услышит ясно подавляющее большинство людей, но при этом она еще вполне уверенно ловится микрофоном.
Я не знаю отчего так происходит, но вот есть такие шлимазлы среди клиентов, которым постоянно не везет и все возможные шишки — на них.
Они, разумеется, считают, что виноваты интеграторы.
Мерять надо либо аналоговым генератором, либо генератором с заведомо более высокой, в разы, частотой дискретизации.
Как раз НЕнаправленные. А точка выстрела вычисляется путем сравнения задержек и уровня сигнала, приходящих с нескольких регистрирующих точек, путем хорошо известных методов триангуляции, применяемой, например, в GSM-геолокации.
Читаешь эти утверждения в соседнем окне со статьей про Сочи, допустим, и испытываешь, м-м… странные ощущения.
Кластеры Hadoop это все еще экзотика, а не массовое применение, и это вообще специальная область. Я так понимаю, что для них вообще нет смысла делать общее сетевое хранилище резервных копий, а нужен (если нужен) локальный драйв, а не SAN-библиотека.
Это сразу увеличивает стоимость решения минимум на стоимость еще одного драйва и еще более усложняет картину. На самом деле проблема лент совсем не в скорости записи или считывания с одной ленты, скорее даже, парадоксальным образом, наоборот, эта скорость бывает слишком велика. Именно для этого используют мультиплексирование, запись на одну ленту бэкапов сразу от нескольких клиентов, так как ленты (в отличие от дисков, кстати) требуют постоянный поток данных максимальной скорости, иначе начинается крайне невыгодный старт-стопный режим работы, тратяший время и изнашивающий ленту.
Говоря про медленность процесса я имел ввиду не скорость чтения копии, а процесс загрузки-выгрузки кассет с лентой.
Представьте, что у вас есть кассета (кассеты) с еженедельным full backup, сделанная в субботу. А потом вы делаете incremental каждый день. И у вас случилась авария, допустим, в пятницу утром. Значит вам надо сперва загрузить ленты full, прочитать их и восстановить на диски целевой системы. Пожужжать роботом, выгрузить эти ленты (или поморгать лампочкой, и дождаться, пока ленту вынет оператор в нероботизированной системе), загрузить ленту для понедельника, промотать ее до нужного места, где хранятся измененные данные за понедельник для этой системы. Считать, вынуть ленту. Вставить ленту для вторника, помотать…
При этом для дисков вы можете сразу читать нужные фвйлы.
И тут устройство с линейным, последовательным характером доступа к данным уже изначально проигрывает. Оно просто, как вы заметили, принципиально хуже.
Вам никогда не доводилось восстанавливать большой бэкап с лент из Full + цепочки Incremental, особенно если они с интерливингом и на разных лентах? Очень веселый и неторопливый процесс.
И еще «веселее» он становится, когда выясняется, что одна из лент сета не читается, или читается с проблемами (или вовсе повредилась при загрузке, такое бывает не так редко, увы). RAID-то нет, в отличие от дискового массива. «Умерла — значит умерла».
Все это не столь важно для архивов, которые, обычно, «данные write-only», но для бэкапов это все критически важно. И если у вас не оборудование времен прошлого века, на сегодня нет ни одной реальной причины использовать ленты именно для бэкапа.
Все было уже не так весело, особенно с впаянными чипами. Это уж потом появились DualROM и аппаратная перемычка отключения записи.
Так что погодите ржать, жизнь — сложная штука.
Вы совершенно напрасно сливаете в одном предложении через запятую два разных процесса и два разных понятия. Важнейшим средством резервного копирования ленты НЕ являются, (наконец, и слава Труду), а архивного хранения — да, являются, и там им и место.
Но это две разные области применения, принципиально отличающиеся по своим требованиям к медиа и методам.
Я так понимаю, что это именно то, что ответственно за «а я слышу разницу в звуке тарелочек через усилитель с границей 20 kHz и границей 45 kHz», то есть человек слышит не звук выше 20, а какие-то вот эти самые субгармоники, порождаемые звуком в неслышимом диапазоне, и оказывающиеся «внизу».
В компьютере же стоит электретный (тот же конденсаторный по принципу, а значит очень чувствительный на ВЧ), но с очень маленькой, а потому малоинерционной мембраной.
Но на самом деле это даже не столь важно, тут ниже мы уже еще один вариант обнаружили — первая субгармоника, образующая для несущей 35 kHz при воспроизведении на динамике, окажется в диапазоне 17,5 kHz, которую уже не услышит ясно подавляющее большинство людей, но при этом она еще вполне уверенно ловится микрофоном.
Субгармоники