Что такое vdd в hive os

Hive Os: разгон видеокарт

Помимо приобретения новых видеокарт (что сейчас довольно проблематично, учитывая отсутствие в магазинах любых видеокарт чуть лучше бюджетных и завышенных до 2 раз цен), отличным способом для увеличения дохода с майнинга является разгон видеокарт. В данном материале мы поговорим о том, как разгонять видеокарты Nvidia и AMD при использовании самой популярной операционной системы для майнеров основанной на Linux — Hive OS. Для разгона GPU в Hive OS существуют так называемые «профили разгона» и благодаря правильно подобранным параметрам разгона и андервольтинга GPU, можно существенно поднять хешрейт ваших ригов, а так же уменьшить их энергопотребление, что в свою очередь позволит вам увеличить КПД добычи и установить еще больше видеокарт если вы вдруг ограничены проводкой, а так же снизить температуры оборудования.

Сразу стоит предупредить, что любые настройки, которые отличаются от заводских значений, могут приводить к нестабильной работе системы. Используйте разгон и андервольтинг оборудования на свой страх и риск. Итак, как мы уже сказали, разгон — это установка настроек вашего оборудование за пределами заводских, который, вероятно, сможет улучшить производительность в майнинге, а так же уменьшить потребление электричества (благодаря андервольтингу — уменьшения напряжения, подаваемого на GPU и видеопамять). Часто разгон и андервольтинг используются одновременно, благодаря чему можно добиться повышения хешрейта при понижении потребления, звучит неплохо, не правда ли? Для разгона и андервольтинга в Hive OS можно использовать «профили разгона«.

Если вы являетесь новичком, или до текущего момента не имели дела с Hive OS, рекомендуем вам прочитать статью «Установка и настройка HiveOS — Linux операционной системы для GPU майнинг ригов и асиков», где подробно и по шагам описан процесс установки и изначальной настройки этой операционной системы для майнинга.

Идеальный разгон всегда подбирается путем «проб и ошибок», поэтому если вы хотите добиться оптимального соотношения хешрейта на ватт, Вам придется немало поэкспериментировать. Однако, Hive OS сможет Вам сильно помочь в этом, так как в него встроена база данных профилей разгона других пользователей, с удобным фильтром по типу видеокарт. Если вы не уверенны какие настройка вам установить изначально, вы можете выбрать один из популярных пресетов для своей видеокарты, а затем уже начинать менять настройки. После каждого изменения настроек разгона и андервольтинга мы рекомендуем запустить майнинг на какое-то более менее продолжительное время, чтобы убедиться что ваше оборудование продолжает работать стабильно и не появились «отклоненные шары» (это могут быть как не верные решения, которые отправляет ваша видеокарта в связи с чрезмерным разгоном, так и не вовремя отправленные шары). Большое количество отклоненных шар, часто является одним из признаков нестабильной работы, в этом случае рекомендуем немного снизить разгон и выполнить повторную проверку.

Создание профиля разгона

Для каждой фермы создаются свои индивидуальные профили разгона и они не могут быть использованы в другой ферме. У вас есть возможность создать профиль разгона для всей фермы или же для конкретного воркера. Профиль конкретного воркера всегда будет иметь более высокий приоритет, и перекрывать общие настройки для фермы. Таким образом, рекомендуется сначала задать оптимальные значения параметров для всей фермы, а затем (если это необходимо) уже настраивать каждый риг (он же воркер) по отдельности.

Итак, для создания нового профиля разгона просто перейдите на вкладку «Шаблоны разгона» («Overclocking Profiles») для вашей фермы, а затем нажмите кнопку «Добавить OC Профиль» («Add OC Profile»). Теперь в появившемся окне «Сохранить Разгон в Качестве Шаблона» («Save Overclocking as Template») назовите ваш новый профиль и нажмите «Сохранить» («Save»).

Вы создали шаблон разгона, который может быть использован конкретными воркерами или же всей вашей фермой. Вы всегда можете его скопировать и изменить для различных алгоритмов и майнеров. Хотя, созданный вами шаблон и будет использоваться для всех ваших GPU, настройки разгона для видеокарт Nvidia и AMD разные. Имейте ввиду, что вы можете иметь различные наборы настроек для разных типов графических процессоров (Nvidia, AMD) в одном и том же профиле и если ваш воркер работает на Nvidia и AMD, то настройки будут применяться к каждому типу GPU индивидуально.

Для того, чтобы отредактировать профиль разгона, просто нажмите на иконку с плюсом, которая находится справа от имени вашего профиля. Кроме того, вы можете использовать популярные шаблоны разгона от других пользователей, зайдя на вкладку «Популярные пресеты» и выбрав из списка вашу модель видеокарты.

Разгон видеокарт Nvidia.

Перед тем как менять настройки разгона вы можете запустить команду «nvidia-smi» через встроенный в Hive Os терминал, для того, чтобы определить текущие настройки ваших GPU. Для того, чтобы сделать это удаленно с панели управления HiveOS, перейдите к вашему воркеру, а затем нажмите на кнопку «Выполнить команду» («Run command») на основной панели инструментов, находящейся в верхней части экрана. В появившемся окне, к тому же, будет справочная информация по другим полезным командам, которые могут пригодится при разгоне и настройке ваших ригов. В появившемся окне в поле слева от кнопки пуск введите команду, после чего нажмите на «Пуск«. После закрытия окна подождите некоторое время (от нескольких секунд до нескольких минут) пока сгенерируется отчет. Для просмотра отчета просто кликните на него.

Теперь поговорим непосредственно про настройки разгона и андервольтинга для Nvidia GPU. У вас есть возможность задать одно общее значение каждого параметра для всех GPU в риге или же указать раздельные значения для каждой видеокарты через пробел. Например:

• 100 — общее значение для всех видеокарт в риге.
• 0 100 0 150 0 — значение 0 для GPU0, 100 для GPU1, 0 для GPU2, 150 для GPU3 и 0 для GPU4.

Чтобы указать настройки для определенного алгоритма, выберите его в списке «Алгоритм» («Algo»). Для каждого алгоритма можно создать индивидуальный набор настроек. При выборе пункта «Настройки по умолчанию» («Default config») ваши настройки будут применимы ко всем алгоритмам, однако они могут быть переписаны настройками в самих алгоритмах.

Подробнее про настройки

• +Частота ядра (Mhz) — Увеличивает тактовую частоту ядра GPU в Мгц. Если ввести значение 0 — это установит значение по умолчанию для ваших видеокарт.
• Частота памяти (Mhz) — увеличивает тактовую частоту видеопамяти. Следует указывать вдвое большее значение, чем вы видите в MSI Afterburner в Windows. Например если в Windows вы устанавливали частоту памяти +500, то вы должны указать значение 1000.
• Вент (%) — служит для настройки скорости вращения вентиляторов на ваших видеокартах в процентах. Если ввести значение 0 — это установит значение по умолчанию для ваших видеокарт. Скорость вращения вентиляторов по-умолчанию прописана в BIOS ваших видеокарт и не зависит от использованного майнера.
• Предел потребления (W) — эта опция предназначена для контроля энергопотребления ваших видеокарт. В отличие от того же Afterburner, где значения указываются в процентах, в случае с HiveOS следует указывать абсолютные значения в Ваттах. Узнать предельные значения для ваших видеокарт можно в списке видеокарт вашего рига. Для примера, значения PL 60 W, 120 W, 140 W означают, что первое значение в 60W — минимальное, второе — 120W — значение по умолчанию и третье — 140W — максимально возможное для установки значение. Если вы установите значения больше максимального или меньше минимального, то этот параметр не будет применен.

После изменения параметров просто нажмите на кнопку «Сохранить«.

Для примера разгон Nvidia GTX 1060.

• Алгоритм: Значение по умолчанию.
• +Частота ядра (Mhz) — 130.
• Частота памяти (Mhz) — 2000.
• Вент (%) — оставляем пустым для настроек по умолчанию.
• Предел потребления (W) — 120.

Разгон видеокарт AMD.

Перед тем как менять настройки разгона вы можете запустить команду «amd-info» через встроенный в Hive Os терминал, для того, чтобы определить текущие настройки ваших GPU. Для того, чтобы сделать это удаленно с панели управления HiveOS, перейдите к вашему воркеру, а затем нажмите на кнопку «Выполнить команду» («Run command») на основной панели инструментов, находящейся в верхней части экрана. В появившемся окне, к тому же, будет справочная информация по другим полезным командам, которые могут пригодится при разгоне и настройке ваших ригов. В появившемся окне в поле слева от кнопки пуск введите команду, после чего нажмите на «Пуск«. После закрытия окна подождите некоторое время (от нескольких секунд до нескольких минут) пока сгенерируется отчет. Для просмотра отчета просто кликните на него.

У вас есть возможность задать одно общее значение каждого параметра для всех GPU в риге или же указать раздельные значения для каждой видеокарты через пробел. Например:

• 100 — общее значение для всех видеокарт в риге.
• 0 100 0 150 0 — значение 0 для GPU0, 100 для GPU1, 0 для GPU2, 150 для GPU3 и 0 для GPU4.

Чтобы указать настройки для определенного алгоритма, выберите его в списке «Алгоритм» («Algo»). Для каждого алгоритма можно создать индивидуальный набор настроек. При выборе пункта «Настройки по умолчанию» («Default config») ваши настройки будут применимы ко всем алгоритмам, однако они могут быть переписаны настройками в самих алгоритмах.

Подробнее про настройки

• Частота ядра (Mhz) — Служит для настройки частоты ядра. Неплохим значением для начала может быть 1100. Если не настроен параметр «Состояние ядра«, то для настройки частоты будет использоваться значение по умолчанию «5«. Все значения должны быть абсолютными.
• Состояние ядра, индекс — опция будет необходима если вы хотите снизить энергопотребление видеокарты. Следует использовать данную опцию совместно с «Частотой ядра» и «Напряжением ядра«. Это называется DPM (Dynamic Power Management, Динамическое Управление Питанием) или же «Power Level» (Уровень мощности) ядра GPU. Для RX GPU, это значение от 1 до 7. Значение по умолчанию — 5. Понизьте это значение для даунвольтинга. Если вы решили использовать одно из значений по умолчанию, тогда вам не нужно настраивать значения в «Частотой ядра» и «Напряжением ядра».
• Напряжение ядра, mV — необходимо, если вы пытаетесь понизить напряжение на вашем GPU. Вам также нужно настроить «Состояние ядра«, или же для настройки напряжения будет использовано значение по умолчанию «5». Вы можете, к примеру, установить значение 900 (мВ), или значение 65284 из таблицы VBIOS.
• Частота памяти (Mhz) — служит для установки частоты памяти. Все значения являются абсолютными.
• Состояние памяти, индекс — очень продвинутый параметр. Измените его, если есть проблемы с понижением напряжением. Если все работает в пределах спецификации — не меняйте это значение. Известно, что карты RX имеют 1 или 2 значения памяти (3, включая 0 — состояние ожидания). По умолчанию будет выбрано самое высокое значение. Но некоторые редкие карты, не способны к андевольтингу при высшем значении, и нуждаются в более низком. Например, наивысшее значение равно 2, и для андервольтинга вы можете установить значение 1. Этот параметр следует использовать с настройкой Частоты памяти.
• Memory Controller Voltage, m — устанавливает напряжение для контроллера памяти (VDDCI). В данный момент применимо только для видеокарт серии NAVI. Значение по умолчанию 850 mV. Допустимый интервал 750-850 mV. Используйте этот параметр только если понимаете что делаете, может повлиять на стабильность системы.
• Вент (%) — служит для настройки скорости вращения вентиляторов на видеокартах. Имейте ввиду, что некоторые майнеры вроде Claymore все равно будут сами контролировать скорость вентилятора. Вы должны отключить управление вентилятором в конфигурации майнера, чтобы эта настройка работала. Мы рекомендуем оставить это поле пустым, если у вас включен AutoFan.
• Предел потребления (W) — Устанавливает максимальное энергопотребление в Ваттах для ядра GPU. В большинстве случаев не требуется настройка этого параметра для карт AMD если ранее были настроены параметры Частота ядра и Напряжением ядра. В данный момент опция неприменима для карт серий VEGA и NAVI.
• SoC частота, Mhz —Этот параметр устанавливает максимальную частоту SoC и доступен для современных ГПУ AMD, начиная с семейства VEGA. Значение по умолчанию для RX 5700 — 1267 МГц. Понижение частоты может привести к снижению энергопотребления и падения температуры. но также может вызвать нестабильность вашего ГПУ. Пожалуйста, используйте этот параметр очень осторожно!

Теперь осталось нажать на кнопку «Сохранить«.

Пример разгона для 6 карт AMD RX 580

Значения показанные ниже приведены для примера, возможно для ваших карт будут оптимальные другие значения. Используйте на свой страх и риск.

Применяем профиль разгона

Теперь, для того, чтобы применить созданный вами профиль, перейдите на вкладку с воркерами и отметьте галочкой слева те воркеры, к которым вы собираетесь применить профиль разгона. Вы должны будете увидеть иконку спидометра в строке меню в правом верхнем углу экрана.

Если нажать на эту иконку спидометра, перед вами появится окно, в котором отобразится количество выбранных вами воркеров и список всех ваших полетных листов. Выберите профиль разгона, который вы хотите использовать и нажмите на кнопку «Применить«. В итоге вы должны увидите сообщение о том, что команда разгона была отправлена на воркер. Через некоторое время ваши воркеры должны будут применить изменения.

Возможно, разгон видеокарт под HiveOS не такая уж и тривиальная задача для новичка, но мы попытались максимально подробно и понятно рассказать о процессе разгона как для видеокарт AMD, так и для графических процессоров Nvidia. Хотя некоторые майнеры используют всегда настройки по умолчанию, и не разгоняют оборудование, как нам кажется, разгон и андервольтинг является неплохим подспорьем для увеличения хешрейта в майнинге или уменьшения потребления ригов. Часто благодаря разгону и андервольтингу удается добиться увеличения хешрейта при одновременном снижении потребления и температур видеокарт.

Разгон видеокарт AMD и Nvidia в Hive OS

31 декабря 2020 года на 2Биткоина вышел подробный материал об основах майнинга и разгона видеокарт. Статья описывает подход для разных алгоритмов майнинга и сопровождается пояснениями вместе со скриншотами. Рекомендуем ознакомиться.

После обзора Hive OS я стал получать много вопросов о настройке разгона под Линукс. Чем больше отвечал, тем больше утверждался в мысли, что нужно оформить всё это в отдельный гайд. Что ж, попробуем.

На фермах под управлением Windows есть целый арсенал «спецсредств» для управления разгоном: MSI Afterburner, Whattool, Polaris BIOS editor, ATI Winflash и другие. Сразу после установки операционной системы нам было необходимо:

• В случае с «зелёными» картами установить MSI AfterBurner, и с помощью него разогнать частоты по памяти и ядру, а также установить параметры Power Limit и температуры.
• В случае с «красными» картами процесс намного занятнее. Тут и BIOS прошей, и драйвера специальные подбери, и Atikmdag патч примени. В общем жизнь Win-фермера совсем нескучная.

Разгон видеокарт Nvidia для майнинга

В случае с Линукс и с Hive OS в частности всё намного проще. Рассмотрим сначала разгон «зелёных» карт от NVidia, так как тут совсем всё легко.

Заходим в панель управления ригом:

Видите большую зеленую кнопку с надписью NVIDIA OC, которая так нас и манит. Жмём её:

Собственно, вот и весь наш инструментарий. В этом окне мы задаем все необходимые параметры. И никакого зоопарка дополнительных утилит нам не надо.

Настройки видеокарт Nvidia в HiveOS

Пройдёмся по пунктам:

+Core Clock (Mhz):

Здесь мы указываем частоту разгона ядра. Просто ставим требуемое нам значение в MHz. Cразу обращаю внимание, что мы можем задать как общее значение для всех карт сразу, так и для каждой карты отдельно. Для этого просто указываем отдельные значения для каждого GPU через пробел. Порядок следования карт мы видим в панели управления.

Далее займёмся разгоном по памяти. Идём к пункту:

+Memory (Mhz):

Тут тоже есть одна особенность. Так уж получилось, что в Линукс у карт Nvidia частота разгона памяти указывается с коэффициентом х2 по сравнению с Windows. То есть для разгона на 500MHz нам надо подставить значение 1000. Связано это с особенностью видеодрайвера, и нам просто надо это учитывать!

Так же, как и при разгоне ядра, мы можем задать либо общее значение для всех карт сразу, либо указать для каждой из карт свои параметры.

Следующий параметр, который предстоит настроить — это скорость вращения вентиляторов:

Fan (%) (0 for auto):

Если здесь поставим 0, то будут применяться настройки, заложенные производителем. Мы можем указать нужную скорость принудительно. К сожалению, на данный момент Hive не позволяет настраивать скорость вращения вентиляторов в зависимости от текущей температуры. В будущих релизах, я думаю, это будет реализовано, а пока, если мы используем майнер Claymore, то можем отдать управление кулерами ему. Он с этим справляется на ура. А если не доверяете и хотите управлять всем самостоятельно, то не забудьте в настройках Клеймора отключить управление кулерами:

-tt 1 to disable fan control

На этом с охлаждением можно закончить, но есть еще один важный параметр, который стоит настроить:

Power Limit (W) (0 for stock value):

Управляя этим параметром, мы можем не только снизить потребление с розетки, но и заметно уменьшить рабочую температуру карт. В Hive, в отличие от Afterburner, мы указываем Power Limit не в процентах от стокового значения, а в абсолютных величинах, в Ваттах.

Как же узнать эти абсолютные значения, спросите вы? Да просто очень.

Во-первых, стоковые значения по потреблению у каждой карты указаны непосредственно в панели:

Здесь мы видим у каждой карты три значения по потреблению: минимальное, среднее и максимальное. Обратите внимание, что даже для карт одного семейства эти значения могут отличаться.

Далее мы можем посмотреть реальное положение дел с энергопотреблением. Для этого в панели управления спускаемся в раздел: Linux Shell Execute

И выбираем там: nvidia-smi

С помощью этой утилиты можно посмотреть, сколько карты потребляют в данный момент, и уже от этих позиций, как от печки, и плясать.

Однозначных рекомендаций по лимиту я давать не буду – у каждой карты он свой. Но есть простое правило – сначала настраиваем разгон. Когда подобрали параметры, при которых карты дают подходящий хешрейт и при этом риг работает стабильно, можно настраивать Power Limit. Снижаем его, пока не начнёт падать хешрейт.

Помним! Разгон карт — это всегда поиск баланса между потреблением и хешрейтом. Нельзя добиться и минимального потребления и максимального хешрейта одновременно.

На этом с разгоном «зелёных» карт можно закончить. Разве что можно еще отключить подсветку на картах. Для этого ставим галку напротив пункта:

Turn Off LEDs (may not work on some cards).

Можно посмотреть, какие параметры разгона чаще всего используют другие пользователи Hive OS. Таблица со значениями других пользователей Hive доступна по ссылке Other users settings:

На этом с «зелёными» точно всё. Мы переходим к картам от AMD, которые в майнерском кругу называют «красными».

Разгон видеокарт AMD для майнинга

Так уж сложилось, что у нас в стране именно «красные» видеокарты пользуются особой любовью прогрессивной части населения. Видимо, сказывается счастливое советское прошлое. Как иначе объяснить любовь к картам, которые хоть и показывают отличные результаты на избранных алгоритмах, отличаются завидным аппетитом и, как следствие, повышенными температурами. А еще с разгоном АМД не всё так просто, как с NVIDIA. Тут уже мало просто задать повышенные частоты и радоваться. Тут надо шить!

Давайте по порядку. Если посмотреть панель управления рига с картами АМД на Hive OS, то на первый взгляд у нас всё тоже самое, что и с Nvidia, только кнопка не зеленая, а красная:

Особенность разгона АМД в том, что прежде чем задать картам рабочие частоты, их надо «прошить». То есть непосредственно в BIOS зашить новые тайминги, позволяющие получить прирост производительности при программном поднятии частот памяти и ядра.

Если в двух словах, то биос видеокарты содержит таблицу с параметрами, среди которых для каждой рабочей частоты производитель задал свои настройки таймингов, или попросту — время задержки между вычислительными циклами. И по умолчанию, чем выше рабочая частота, тем более медленные тайминги используются. Сделано это для того, чтобы обеспечить стабильную работу видеокарты. Но нам же, помимо стабильности, нужна и повышенная производительность, верно? Поэтому модифицируя биос, мы фактически меняем значения в таблице: частота / тайминг. Берем тайминги, соответствующие более низким частотам, и назначаем их для более высоких. Помня при этом о балансе производительность/стабильность. Там же в биос можно подредактировать и вольтаж ядра и памяти, и поведение кулеров.

Так уж сложилось, что под Линукс нет редактора, с помощью которого можно отредактировать биос видеокарты и поменять эти самые тайминги. Однако при этом Hive OS отлично справляется с задачей чтения/записи биос из видеокарты.

Обязательно сохраните оригинальный BIOS вашей видеокарты.

Перед нами два пути: модифицировать тайминги под Windows, используя Polaris bios editor, или же искать уже готовый биос под вашу карту на профильных веб-ресурсах. Отмечу, что процесс модификации BIOS требует определенных навыков и заслуживает отдельного обсуждения. Поэтому я рекомендую второй путь. Просто ищем готовый биос под свои видеокарты и зашиваем его уже под Hive OS.

Где же взять готовый «разогнанный» биос? Можно воспользоваться разными профильными форумами, но есть риск нарваться на «кривой» образ. Поэтому я рекомендую два основных ресурса:

На что надо обращать внимание при выборе биос? С производителем и моделью карты всё понятно. Но ещё при выборе модифицированного биос обязательно учитывайте производителя модулей памяти (информация о производителе есть в Hive OS).

Как правило, это Hynix, Samsung, Micron или Elpida. И очень часто под каждый тип памяти будет свой образ биос, так как под каждую память свои тайминги.

До последнего времени считалось, что залог хорошего разгона, а значит и высокого хешрейта — это карты с памятью Samsung. Но на самом деле, производитель памяти на вашей карте не так уж и важен. Сейчас практически любую видеокарту серии RX480/580 с любыми модулями памяти можно разогнать до примерно одних и тех же показателей. Так, на эфире это плюс минус 28 – 31 MH/s в дуал режиме. Поэтому, если вам попалась карта с памятью Elpida, а не Samsung, то это еще не повод для расстройства.

Также нередко для одной и той же карты доступны несколько вариантов биос: memshift, powersafe, overklock.

• Memshift – биос с измененными таймингами памяти
• Overclock – агрессивные варианты биос, где помимо таймингов памяти также зашит разгон ядра GPU.
• Powersafe – это вариант биос с пониженным потреблением и как результат, с более низкими рабочими температурами.

Выбираем образ, который понравился, и прошиваем его в карту. Но, сначала обязательно делаем бекап родного биос, на всякий пожарный. И будьте внимательны, если у вас в риге установлено несколько карт! Не ошибитесь при прошивке!

Только теперь, когда мы уже прошили карты, настало время их разогнать.

Настройки видеокарт AMD в HiveOS

Идем в панель разгона:

Окно панели разгона во многом схоже с таким же окном для Nvidia, но у AMD параметров, на которые можно влиять, заметно больше.

С частотами памяти и ядра всё более-менее понятно. Как правило, частоты ядра варьируются от 1100 до 1350, а по памяти 1750 – 2200. Тут всё зависит от вашей карты. Подбираем значение, при котором карта работает стабильно, и радуемся хешрейту.

С разгоном закончили. Рассмотрим отдельно параметры, позволяющие снизить потребление карт:

Core State (Index):

Этот параметр позволяет управлять прожорливостью нашей видеокарты с помощью динамического управления питанием. Для карт семейства AMD RX есть возможность регулировать потребление указывая значение индекса DPM 1 до 7. Чем больше эта цифра, тем больше потребляет наша карта, тем больше она греется, и наоборот. По умолчанию используется значение 5. Можно задать индекс 3 или 4 и посмотреть, что будет с потреблением.

Где посмотреть потребление? Идем вниз страницы к пункту Linux Shell Execute и видим несколько полезных утилит для владельцев «красных карт»:

amd-info — show current frequencies for AMD cards
amdcovc — show current frequencies for AMD cards
amdmeminfo — show extended info about AMD card
wolfamdctrl -i 0 —show-voltage — show voltage table for AMD GPU #0

На самом деле нам достаточно только amd-info, которая покажет нам все текущие рабочие значения:

Как видим, вся необходимая информация здесь есть.

Следующий параметр, которым мы можем управлять:

Core Voltage (mV):

Здесь можно принудительно задать вольтаж для ядра. По умолчанию используется значение, зашитое в биос и соответствующее выбранному Core State из предыдущего абзаца. Чем меньше значение, тем меньше карта потребляет и меньше греется. Но при этом, чересчур зажав вольтаж, мы можем потерять в хешрейте. Как правило, используются значения диапазоне от 800 mV до 950 mV.

Последний параметр, который мы можем задать это:

Mem State (Index):

Он используется только для некоторых «старых» карт, которые не даунвольтятся с помощью Core State и Core Voltage. Тогда мы можем принудительно указать «экономичный режим» работы — 1, или режим максимальной производительности — 2.

На этом с особенностями разгона АМД всё. По управлению кулерами, я думаю, вопросов нет.

Поделюсь лишь некоторыми наблюдениями из личного опыта с «красными» картами. Сразу после прошивки биоса не торопитесь задавать все параметры. Перегрузите риг, запустите майнер и посмотрите хешрейт, проверьте потребление. Очень часто модифицированный биос уже содержит «правильные» значения по вольтажу, и достаточно указать только частоту памяти.

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

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

Еще одна особенность, на которую я обратил внимание => При значениях разгона ядро/память = 1175/2070 я получил отличный хешрейт и стабильную работу на эфироподобных монетах, но при запуске майнера с такими же настройками для монет на алгоритме equihash я столкнулся с тем, что из 6 карт стартует только 4 или 5. Решением оказалось снижение частоты памяти до 1900 MHz. Казалось бы, алгоритм equihash задействует в первую очередь ядро, и параметры разгона памяти ему не важны. Однако понизив частоту памяти, получаем стабильную работу Claymore Z. Такая же ситуация с Cryptonight. На настройках для Ethash майнер работает нестабильно. Стоит протестировать разгон на всех алгоритмах, которые планируете использовать! В ближайших релизах Hive OS нам обещают добавить возможность сохранения нескольких профилей разгона, что позволит более гибко настраивать систему под разные алгоритмы майнинга.

Раз уж зашел разговор о параметрах разгона под разные алгоритмы, стоит посмотреть негласные рекомендации по разгону под каждый из алгоритмов:

• Ethash — увеличиваем частоту памяти, ядро в минус
• Equihash — увеличиваем частоту ядра, память 50% от максимума
• Keccak — увеличиваем частоту памяти, ядро в минус
• Skunkhash — увеличиваем частоту ядра, память в минус
• CryptoNight — увеличиваем частоту памяти, ядро в минус
• Tribus — увеличиваем частоту ядра, память в минус
• X11Gost — увеличиваем частоту ядра, память в минус
• LBRY — увеличиваем частоту ядра, память в минус
• Groestl — увеличиваем частоту ядра, память в минус
• Blake (14r) — увеличиваем частоту ядра, память в минус
• Pascal — увеличиваем частоту ядра, память в минус
• Blake (2b) — увеличиваем частоту ядра, память в минус
• Blake (2s) — увеличиваем частоту ядра, память в минус
• Lyra2REv2 — увеличиваем частоту памяти, ядро в минус
• NeoScrypt — увеличиваем частоту памяти и ядра
• Nist5 — увеличиваем частоту ядра, память в минус

Рекомендации довольно примерные, но они помогают понять, какой алгоритм как нагружает видеокарту, и в результате подобрать свои «правильные» настойки.

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

Hive OS 2.0 — Настройка разгона видеокарт

В предыдущей статье были рассмотрены основы создания полетных листов для ваших воркеров, в этой статье мы углубимся в настройку вашего воркера с помощью профилей разгона.

Отказ от ответственности: любые настройки, которые отклоняются от заводских значений, могут привести к неустойчивой работе вашей системы. Вы используете это на свой страх и риск.

Что такое профиль разгона

В общем, разгон повышает характеристики вашего оборудования за пределы его заводских спецификаций, что, возможно, улучшает его производительность. Профиль разгона также может использоваться для других целей, таких как downvolting — снижение энергопотребления вашего оборудования. Существует множество приложений для разгона, и мы попытаемся охватить некоторые из них в этой статье.

Разгон — это процесс проб и ошибок и требует терпения для достижения желаемых результатов. Вы всегда должны дать видеокартам поработать с каждым набором новых профилей разгона в течение некоторого времени, чтобы убедиться, что эти конкретные параметры останутся стабильными. Аппаратное обеспечение может вести себя по-разному и может дать непредсказуемые результаты. Один из способов проверить, были ли ваши изменения в разгоне успешными, — не начать получать отклоненные акции во время майнинга.

Отклоненные акции (шары)

Отклоненные акции — акции, которые делал ваш майнер, но они либо не были представлены вовремя для включения в блок, либо у них была ошибка. Самая распространенная причина для большого количества отклоненных акций связана с чрезмерным разгоном GPU до того момента, когда он производит неисправные акции. Чем меньше ставка отклоненных акций, тем выше эффективность вашего разгонного профиля GPU.

При этом большинство пользователей оставляют свое оборудование по умолчанию, так как результаты разгона могут отличаться для каждого пользователя. Это также сильно зависит от фактических компонентов, которые использует производитель, поскольку некоторые компоненты способны разгоняться за пределы спецификации, а некоторые просто не работают так хорошо (например память видеокарт от Samsung имеет хорошие показатели для разгона по сравнению с hynix).

Создание профиля разгона

Все профили разгона создаются индивидуально для каждой фермы и не могут использоваться совместно с другими фермами. Вы можете создать профиль всей фермы или профиль конкретного воркера. Рабочие настройки всегда будут переопределять любые настройки всей фермы. Например, таким образом вы можете установить оптимальные желаемые настройки для всей фермы, а затем точно настроить каждую установку отдельно.

Чтобы добавить новый профиль, перейдите на вкладку Профили разгона вашей фермы и нажмите кнопку Добавить профиль разгона. В окне «Сохранить разгон в виде шаблона» укажите имя профиля и нажмите «Сохранить».

Создание нового профиля разгона

Вы создали шаблон, который позже будет использоваться конкретными воркерами или всей вашей фермой. Этот шаблон затем может быть скопирован и изменен для разных комбинаций майнеров или алгоритмов.

Шаблон, который мы создали, будет использоваться всеми вашими графическими процессорами, но настройки для Nvidia и AMD отличаются. У вас могут быть отдельные наборы настроек для обоих типов графических процессоров в одном профиле, если ваша установка работает как с графическими процессорами Nvidia, так и с AMD, и они будут применяться к каждому типу GPU индивидуально.

Чтобы изменить профиль разгона, щелкните значок «плюс» рядом с именем вашего профиля и следуйте приведенным ниже инструкциям в зависимости от типа вашего GPU.

Редактирование шаблона OC

Разгон графических процессоров Nvidia GPU

Прежде чем изменять какие-либо настройки, вы можете запустить команду nvidia-smi , чтобы узнать текущие настройки графического процессора. Чтобы сделать это удаленно со своей панели, перейдите к своему работнику и нажмите кнопку «Запустить команду» на панели инструментов в верхней части экрана.

Вы можете указать одно значение для всех карт или список значений для каждой карты, разделенной пробелом. Например:
150 — одно значение для всех графических процессоров.
0 100 0 0 0 140 — означает GPU0 = нет, GPU1 = 100 и т.д.

Окно Nvidia OC

Поле Algo используется для указания настроек разгона для определенного алгоритма. Вы можете создать отдельный набор параметров разгона для каждого алгоритма отдельно или выбрать настройку по умолчанию, которая будет применяться ко всем алгоритмам, но может быть перезаписана самими настройками алгоритма.

• + Core Clock (Mhz) — увеличивает тактовую частоту GPU в Mhz. Минимальные и максимальные значения для вашего графического процессора можно найти в средстве настройки сервера Nvidia X, перейдя на вкладку PowerMizer на вашем оборудовании. = 0 всегда будет значением по умолчанию равно (заводским) GPU.
• Память (Mhz) — увеличивает скорость памяти GPU в Mhz. Обычно это значение вдвое больше того, что вы видите в AfterBurner. Например, если в Windows это + 800 МГц, значение здесь должно быть 1600. Минимальное и максимальное значения для вашего графического процессора можно найти в средстве настройки сервера Nvidia X, перейдя на вкладку PowerMizer.
• Вентилятор (%) — управляет скоростью вашего вентилятора / вентилятора GPU. 0 всегда будет значением по умолчанию (заводским) GPU. BIOS вашего GPU определит скорость вращения вентилятора, а не майнер.
• Предел мощности (W) — регулирует потребление энергии. Эти значения должны быть абсолютными, в отличие от AfterBurner, где значения являются процентильными. Вы можете проверить свои предельные значения мощности в списке графических процессоров. Например, ограничение мощности 60.00 Вт, 120.00 Вт, 140.00 Вт означает, что первое значение, 60.00 Вт — минимальное, 120.00 Вт — значение по умолчанию и 140.00 Вт — максимальное. Этот параметр не будет применяться, если ваши значения меньше или превышают значения min / max вашего конкретного графического процессора.
• Turn Off LEDs — это отключает светодиодные индикаторы на вашем графическом процессоре, если таковые имеются. Этот параметр может не работать на некоторых графических процессорах.
• OhGodAnETHlargementPill — работает только с Nvidia GTX 1080. Предоставлено OhGodACompany. Проверьте их страницу GitHub.

Нажмите «Сохранить», и все готово.

Пример: разгон Nvidia GTX 1060

Вот пример профиля разгона для графического процессора Nvidia GTX 1060.

Обратите внимание, что эти значения являются примерными. Используйте на свой риск.

• Algo — мы устанавливаем его в конфигурацию по умолчанию, как мы хотим, чтобы он был применим ко всем алгоритмам
• + Core Clock (Mhz) — 130
• Память (Mhz) — 2000
• Вентилятор (%) — пустой для значений по умолчанию
• Предел мощности (Вт) — 120
• Leds— наш графический процессор не имеет светодиодов, поэтому мы пропустили эту настройку
• OhGodAnETHlargementPill — это доступно только для графических процессоров серии 1080, поэтому мы пропустили эту настройку

Нажмите «Сохранить», и все готово.

Разгон AMD GPU

Прежде чем изменять какие-либо настройки, вы можете запустить команду amd-info , чтобы узнать текущие настройки графического процессора. Чтобы сделать это удаленно со своей панели, перейдите к своему работнику и нажмите кнопку «Запустить команду» на панели инструментов в верхней части экрана.

Вы можете указать одно значение для всех карт или список значений для каждой карты, разделенный пробелом. Например:
150 — одно значение для всех графических процессоров.
0 100 0 0 0 140 — означает GPU0 = нет, GPU1 = 100 и т.д.

Окно AMD OC

Поле Algo используется для указания настроек разгона для определенного алгоритма. Вы можете создать отдельный набор параметров разгона для каждого алгоритма отдельно или выбрать настройку по умолчанию, которая будет применяться ко всем алгоритмам, но может быть перезаписана самими настройками алгоритма.

• Core Clock (Mhz) — устанавливает частоту ядра. Хорошее значение будет около 1100. Если состояние ядра отключено, то для установки частоты будет использоваться состояние по умолчанию 5. Все значения должны быть абсолютными.
• Core State (Index) — это необходимо, если вы попытаетесь понизить питание видеокарты. Вы должны использовать этот параметр совместно с настройками Core Clock и Core Voltage. Это называется DPM (Dynamic Power Management) или «Уровень мощности» ядра GPU. Для RX-графических процессоров это значение от 1 до 7. Значение по умолчанию — 5. Уменьшите значение до нисходящего потока. Если вы решите установить одно из состояний по умолчанию, вам не нужно устанавливать какие-либо значения в Core Clock и Core Voltage.
• Напряжение ядра (мВ) — необходимо, если вы попытаетесь понизить напряжение ядра видеокарты. И вы должны установить Состояние ядра или по-умолчанию 5 состояние будет использоваться для установки напряжения. Вы можете установить значения, такие как 900, значение mV или значения, такие как 65284 из таблицы VBIOS.
• Memory Clock (Mhz) — устанавливает тактовую частоту памяти. Все значения являются абсолютными.
• Mem State (Index) — очень продвинутый параметр. Измените это, если есть проблемы с undervolting. Если все работает в пределах спецификации — не меняйте это значение. Известно, что RX-карты имеют 1 или 2 состояния памяти (3 в том числе 0 — незанятое состояние). По умолчанию будет выбрано самое высокое состояние. Но некоторые редкие карты, как известно, не поддаются восстановлению в самом высоком состоянии и должны выбрать нижний. Например, самое высокое значение равно 2, и для undervolting вам нужно установить состояние в 1. Вы должны использовать этот параметр с настройкой Memory Clock.
• Вентилятор (%) — для установки скорости вращения вентилятора. Имейте в виду, что майнеры, подобные claymore, все еще будут контролировать скорость вращения вентилятора. Вы должны отключить управление вентилятором в конфигурации майнера, чтобы это работало. Советуем оставить это поле пустым, если вы включили AutoFan. Мы напишем больше о AutoFan в наших будущих статьях.
• Aggressive undervolting — выбирает заданный разогнанный параметр для каждого состояния DPM.

Нажмите «Сохранить», и все готово.

Пример: разгон AMD RX 580

Вот пример профиля разгона для AMD RX 580 GPU.

Обратите внимание, что эти значения являются примерными. Используйте на свой риск.

Примеры настроек AMD OC

Algo — мы устанавливаем его в конфигурацию по умолчанию, как мы хотим, чтобы он был применим ко всем алгоритмам

• Core Clock (Mhz) — 1150
• Core State (Index) — 3
• Core Voltage (mV) — 875
• Частота памяти (Mhz) — 2200
• Mem State (Index) — оставлено пустым, так как наш графический процессор не имел проблемы с undervolting
• Вентилятор (%) — пустой для значений по умолчанию
• Aggressive undervolting — установлено на активное

Нажмите «Сохранить», и все готово.

Применение профиля разгона

Теперь вы можете применить профиль оверклокинга, который вы создали, перейдя на вкладку «Воркеры», а затем щелкнув флажки на левой стороне ригов, к которым вы хотите применить профиль разгона. Вы должны увидеть значок спидометра в строке меню в правом верхнем углу.

Применение профиля OC

Нажмите на нее, и вы увидите окно с количеством выбранных вами работников и список всех ваших полетных листов.

Список профилей OC для применения к воркерам

Выберите профиль разгона, который вы хотите применить, и нажмите кнопку «Применить». Вы должны увидеть сообщение о том, что команда разгона была отправлена работнику. Через несколько секунд ваши работники должны применить изменения.

Hive os la что это

С необходимостью правильно оценить нагрузку на систему сталкивается каждый системный администратор. Если говорить о Linux-системах, то одним из основных терминов, с которым придется столкнуться начинающему администратору окажется Load Average (средняя загрузка). Однако, если говорить о русскоязычном сегменте сети интернет, описание данного параметра сводится к общим малозначащим фразам, в то время как за этими простыми цифрами кроется глубокий пласт информации о работе системы.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Если обратиться к популярным источникам (Википедия), то можно найти примерно следующее:

Средняя загрузка — среднее значение загрузки системы за некоторый период времени, как правило, отображается в виде трёх значений, которые представляют собой усредненные величины за последние 1, 5 и 15 минут, чем ниже, тем лучше. В UNIX это среднее значение вычислительной работы, которую выполняет система.

После прочтения данного абзаца никаких новых знаний, кроме того, что масло таки масляное (средняя загрузка — среднее значение загрузки) не возникает и понимания ситуации не прибавляется. Чем ниже, тем лучше, но насколько ниже и относительно чего.

Посмотреть текущую загрузку системы можно командной

Также ее значения выводят утилиты top и htop, а также множество других инструментов. В ответ мы получим что-то вроде:

Много это или мало? Хорошо или плохо? Давайте разбираться.

Чтобы понять, что такое загрузка системы следует обратиться к логике работы центрального процессора. Вне зависимости от того, мощный у вас процессор или слабый, многоядерный или нет, он выполняет некий программный код для некоторых процессов. Если процесс один, то вопросов нет, а вот когда их несколько? Надо как-то распределять ресурсы между ними и, желательно, равномерно, чтобы один процесс, «дорвавшись» до CPU, не оставил без вычислений другие.

Здесь можно провести аналогию, когда несколько игроков хотят поиграть на одной приставке. Что обычно делают в таких случаях? Договариваются о времени, скажем каждый играет по 15 минут, затем дает поиграть другому.

Процессор поступает аналогичным образом. Каждому нуждающемуся в вычислениях процессу выделяется некий промежуток времени, который зависит от типа процессора и системы, если говорить о современных процессорах Intel, то это значение обычно составляет 10 мс и называется тиком. Каждый тик процессорное время отдается какому-то одному процессу в порядке очереди, но если процесс имеет повышенный или пониженный приоритет, то он, соответственно получит большее или меньшее количество тиков.

Количество использованных тиков, в первом приближении, и представляет загрузку системы. В Linux для оценки загрузки используется интервал в 500 тиков (5 секунд), при этом учитываются как работающие процессы (использованные тики), так и ожидающие (которым не хватило тика, либо они не смогли его использовать, ожидая завершения иной операции).

Если мы используем все тики за указанный промежуток времени и у нас не будет ожидающих сводного тика процессов, то мы получим загрузку процессора на 100% или load average (LA) равное 1.

Давайте рассмотрим следующую схему:

Для простоты мы будем использовать в расчетах более короткий интервал — 9 тиков. На схеме слева мы видим, что процессорные ресурсы сначала понадобились системе, затем браузеру и файловому менеджеру, потом активности в системе не было, затем еще один тик взял файловый менеджер и еще два браузер, последние два тика также не понадобились никому. Несложные расчеты показывают, что мы использовали 67% процессорного времени или load average системы составил 0,67.

Справа показана ситуация, когда каждый тик был занят своим процессом, но некоторые процессы так и не получили своего тика или не смогли получить, например, ждали окончания операции ввода-вывода. В таком случае загрузка процессора составит все те же 100%, но load average вырастет до 1,33, указывая на наличие очереди.

Чтобы лучше понять ситуацию давайте представим себе небольшой супермаркет, касса представляет собой аналог процессора, тик — среднее время обслуживания покупателя (скажем, 1 минута), а процессы — это покупатели. В разгар рабочего дня людей в магазине немного, и вы спокойно прошли на свободную кассу, рассчитались и пошли по своим делам. Это хорошо, но как оценить нагрузку на кассу? Для этого нужно взять некий промежуток времени, допустим 10 минут. Если за 10 минут в магазине кроме вас было еще три человека, то средняя загрузка составит 0,4.

А теперь зайдем в магазин вечером, все кассы заняты, и чтобы оплатить покупки придется ждать. Теперь если за 10 минут касса обслужила 10 человек и еще 10 стоят в очереди, то средняя загрузка будет равна 2, хотя касса загружена всего на 100%.

Вернемся к процессору и еще одному моменту, процессам, ожидающим окончания операций ввода-вывода (диск, сеть и т.п.). Во многих источниках указывается, что такие процессы искажают результат load average и мы можем получить высокие значения LA при отсутствии загрузки процессора. Да, это так. Посмотрим на еще одну схему ниже:

Как видим, из 9 тиков было использовано только 6, т.е. процессор загружен всего на 67%, но так как три процесса ждут данные от диска, то load average по-прежнему равен 1.

Если продолжать аналогию с супермаркетом, то похожая ситуация возникает, когда вы уже подошли к кассе и уже собрались выгружать продукты на ленту, но ваша супруга говорит вам, что она забыла купить хлеб, и вы тут стойте, а она сбегает. Собственно, все что вам остается до того, как она принесет хлеб, это стоять рядом с кассой и ждать, пропуская тех, кто находится в очереди позади вас.

Искажают ли такие процессы значение load average? На наш взгляд нет. Следует понимать, что средняя загрузка — это не показатель производительности процессора, не результат бенчмарка, не текущая нагрузка, а отношение числа процессов, которым требуются вычислительные ресурсы системы к имеющимся в наличии ресурсам.

Т.е. если у нас имеется 1 процессор и 500 тиков, но за это время процессорные ресурсы требуются тысяче процессов, то нагрузка у нас явно вдвое превышает имеющиеся ресурсы. И то, что часть процессов ждут жесткий диск и процессор работает вхолостую, не говорит о том, что система находится в простое, наоборот, она не может обработать нагрузку, правда по другой, не зависящей от процессора причине.

Пользователю ведь все равно по какой причине тормозит сайт или приложение, тем более что недостаток дисковых ресурсов обычно выражается подвисании приложения, в то время как при недостатке процессорных оно просто начинает тормозить.

Подведем промежуточный итог. Load average показывает отношение имеющихся запросов на вычислительные ресурсы к количеству этих самых ресурсов (тиков). Для одного процессора (одного процессорного ядра) использование всех имеющихся ресурсов обозначает load average = 1. Причем это будет справедливо и для Core i7 и для Pentium I, хотя производительность у этих двух процессоров разная.

Теперь перейдем к многопроцессорности и многоядерности. При появлении второго процессора или второго ядра у нас появляются дополнительные вычислительные ресурсы, т.е. же самые 500 тиков. Но за эти 500 тиков система уже может обработать уже 1000 запросов, что покажет нам load average = 2.

Значит ли это, что производительность выросла в два раза? Нет! Производительность зависит от того, сколько вычислений способен произвести процессор в течении одного тика. Понятно, что более мощный процессор выполнит за этот промежуток времени больше вычислений, но оба из них сделают одинаковое число тиков (для каждого процессорного ядра). В многопроцессорных (многоядерных) системах часть процессорного времени вместо вычислений занимают задачи межпроцессорного взаимодействия, переключения контекста и т.д. Поэтому появление второго ядра никогда не даст 100% прироста производительности, но всегда позволяет обработать вдвое большее количество запросов.

Это хорошо видно на примере технологии Hyper-threading, которая позволяет сделать из одного физического ядра процессора два виртуальных. Физическая производительность ядра процессора, т.е. количество производимых им вычислений в единицу времени не меняется, но появляется, хоть и виртуальное, но второе ядро, а это еще 500 тиков. Как показывают тесты, прирост производительности от Hyper-threading составляет 15-30%, что еще раз подтверждает старую поговорку, что лучше плохо ехать, чем хорошо стоять. Второе ядро, хоть и виртуальное, позволяет обрабатывать вычислительные запросы тех процессов, которые в одноядерном варианте стояли бы в очереди.

Непонимание этого момента приводит к тому, что load average ошибочно связывают не с доступностью и достаточностью вычислительных ресурсов, а с производительностью процессора, что приводит к неверным выводам.

Например, переводчик довольно неплохой статьи на Хабре делает ошибочный вывод в отношении Hyper-threading:

Хабраюзер esvaf в комментариях интересуется, как интерпретировать значения load average в случае использования процессора с технологией HyperThreading. Однозначного ответа на данный момент я не нашел. В данной статье утверждается, что процессор, который имеет два виртуальных ядра при одном физическом, будет на 10-30% более производительным, чем простой одноядерный. Если принимать такое допущение за истину, считаю, при интерпретации load average стоит брать в расчет только количество физических ядер.

А Википедия вообще написала полную ерунду (что для технических статей там совсем не редкость):

Средняя нагрузка — это не очень точная характеристика (хотя бы потому, что она определяет усреднённые значения). И если на компьютере есть несколько процессоров, то такой характеристике верить нельзя. Располагая двумя процессорами, можно (теоретически) одновременно выполнять в два раза большее число программ. Это означает, что средняя нагрузка 2.00 (на двухпроцессорном компьютере) будет эквивалентна средней нагрузке 1.00 (на однопроцессорном компьютере). На самом деле это не совсем так. Из-за дополнительной нагрузки, вызванной планированием и некоторыми другими факторами, двухпроцессорный компьютер не обеспечивает удвоения быстродействия по сравнению с однопроцессорным вариантом.

Убедиться, что это не так довольно легко. Если запустить бесконечный цикл командой

то мы обеспечим полную загрузку одного процессорного ядра и load average = 1 (в данный момент смотрим только на первые, минутные показания данного параметра).

Мы не знаем, сколько именно операций в единицу времени выполняет наш процессор, но нам и не нужно знать это, гораздо важнее понимать, что на текущий момент все вычислительные ресурсы системы задействованы, но недостатка в них нет.

Запустим пятый процесс:

Что изменилось? Загрузка процессора осталась на уровне 100%, это и понятно, выше головы не прыгнешь, но load average вырос до 5, что означает нехватку вычислительных ресурсов примерно на 20%. Таким образом понимание сути значения средней загрузки позволяет администратору однозначно сделать выводы о текущей ситуации, чего не скажешь, глядя просто на индикатор загрузки CPU.

Теперь касательно HyperThreading, виртуализации и т.п. случаев, когда процессор, с которым работает система далеко не соответствует физическому процессору, искусственно создадим данную ситуацию. Для этого запустим на хосте параллельно с виртуальной машиной какой-нибудь ресурсоемкий процесс, например, кодирование видео. Виртуальная машина будет рассчитывать на 4 полных процессорных ядра, а по факту получит в лучшем случае половину их производительности. Проверим?

На что следует обратить внимание? В текущих условиях виртуальная машина получает примерно 30-40% загрузки физического процессора. Внутри виртуалки мы видим ожидаемые 100% загрузки процессора, однако если обратить внимание на колонку CPU%, то мы увидим там весьма интересные значения 157-162% загрузки процессора. Почему так происходит? Внутри виртуальной системы тиков CPU хватает всем, но реально гипервизор не выделяет виртуалке процессорного времени. Но это все лирика, что нам показывает load average? Налицо недостаток вычислительных ресурсов — 4,55. Соответствует это реальному положению дел? Да. Нужно ли вносить какие-то коррективы? На наш взгляд — нет.

Теперь уберем стороннюю нагрузку. Гипервизор тут же передаст максимум ресурсов виртуальной машине.

Как видим, вычислительных ресурсов снова стало достаточно и load average опустился до значения 4.

Какие выводы мы можем сделать из этого примера? Что значение load average корректно отражает загрузку системы даже в тех условиях, когда иные показатели не дают корректного представления о происходящих процессах. Так нагрузка на CPU в 157% явно противоречит здравому смыслу, а вот LA = 4,55 вполне реально отражает ситуацию. Поэтому никаких корректив на виртуальные ядра, виртуализацию и т.п. вносить не надо. Load average является относительной величиной и от реальной производительности CPU не зависит в тоже время показывая наличие или дефицит вычислительных ресурсов.

Теперь разберемся с самими цифрами. Мы получаем три значения load average для промежутков в 1, 5 и 15 минут. Как гласит та же Википедия — это средние значения за указанный промежуток времени, что снова неправильно. Для отображения load average используется экспоненциально взвешенная скользящая средняя, подобный тип кривых используется для для сглаживания краткосрочных колебаний и выделения основных тенденций или циклов.

Например, скользящие средние широко применяются в финансовом анализе, для выделения общих тенденций движения курсов валют и акций, позволяя отбросить так называемый «биржевой шум» и понять общие тренды рынка.

То, что подходит финансисту, наверняка подойдет и системному администратору. В чем основное преимущество скользящих средних? В том, что они позволяют выделить основные тенденции, отбросив кратковременные колебания. Это достоинство, а не недостаток, как пытается убедить нас Википедия:

Средняя нагрузка — это не очень точная характеристика (хотя бы потому, что она определяет усреднённые значения).

Именно усредненные по особому алгоритму значения позволяют нам окинуть ситуацию взглядом вширь и вглубь и разглядеть за деревьями лес. В этом отношении временные значения load average представляют собой не время, за которое посчитали среднее значение, а период времени относительно которого проводится усреднение.

Благодаря автору Хабра ZloyHobbit, который не поленился изучить исходный код Linux, можно точно смоделировать различные значения load average при заданной модели нагрузки. Мы смоделировали ситуацию, когда первые 30 минут единственное ядро CPU было нагружено на 100%, без ждущих в очереди процессов, в последующие полчаса нагрузка была полностью снята.

Как видим, разные периоды усреднения дают совершенно различные результаты, так LA 1 (1 min), начинает показывать реальные значения где-то через 4 минуты, LA 5 для отражения текущей нагрузки потребовалось уже 20 минут, а LA 15 за полчаса полной загрузки вышла только на 0,8.

О чем это говорит и как интерпретировать данные значения? Можно сказать, что LA 1 представляет собой недавнее прошлое (несколько минут назад), LA 5 прошлое (полчаса-час) и LA 15 отдаленное прошлое (несколько часов).

Теперь, располагая этим багажом знаний, мы можем правильно интерпретировать простые, на первый взгляд, три числа load average.

Для примера возьмем такое значение:

Это говорит о том, что имеет место достаточно кратковременный (около десятка минут) всплеск нагрузки, при этом вычислительных ресурсов пока достаточно.

Говорит о том, что не так давно система испытывала значительные нагрузки в течении довольно продолжительного времени (полчаса-час).

А вот такая картина:

Для четырехядерного процессора означает, что он работает на пределе своих возможностей в течении длительного времени (несколько часов).

Как видим, load average, несмотря всего на три цифры, способна представить системному администратору огромный пласт информации о фактической загрузке системы на протяжении последних нескольких часов.

Теперь самое время дать ответы на вопросы, поставленные нами в начале статьи: «Много это или мало? Хорошо или плохо? » Для одного ядра мы считаем приемлемыми следующие значения:

• LA 1 — может превышать 1.00, свидетельствуя о кратковременной пиковой нагрузке на систему.
• LA 5 — не должен превышать 1.00, в противном случае налицо явный недостаток вычислительных ресурсов.
• LA 15 — максимальное значение 0.7 — 0.8, но в любом случае не выше 1.0, в противном случае вы можете получить в три часа ночи звонок от руководства с вопросом: » А что это с нашим сервером. «

На многоядерной (многопроцессорной) системе значения load average следует откорректировать пропорционально числу ядер. Узнать их количество можно командой

Так, например, с учетом вышесказанного, для четырехядерной системы LA 15 не должен превышать 3.00, для двухядерной 1.5, а для одноядерной 0.75.

Теперь, понимая, что такое load average и каким образом формируются его значения вы всегда сможете быстро оценить производительность собственной системы и вовремя принять меры если в работе вашего сервера возникнут узкие места.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Hive Os: разгон видеокарт

Помимо приобретения новых видеокарт (что сейчас довольно проблематично, учитывая отсутствие в магазинах любых видеокарт чуть лучше бюджетных и завышенных до 2 раз цен), отличным способом для увеличения дохода с майнинга является разгон видеокарт. В данном материале мы поговорим о том, как разгонять видеокарты Nvidia и AMD при использовании самой популярной операционной системы для майнеров основанной на Linux — Hive OS. Для разгона GPU в Hive OS существуют так называемые «профили разгона» и благодаря правильно подобранным параметрам разгона и андервольтинга GPU, можно существенно поднять хешрейт ваших ригов, а так же уменьшить их энергопотребление, что в свою очередь позволит вам увеличить КПД добычи и установить еще больше видеокарт если вы вдруг ограничены проводкой, а так же снизить температуры оборудования.

Сразу стоит предупредить, что любые настройки, которые отличаются от заводских значений, могут приводить к нестабильной работе системы. Используйте разгон и андервольтинг оборудования на свой страх и риск. Итак, как мы уже сказали, разгон — это установка настроек вашего оборудование за пределами заводских, который, вероятно, сможет улучшить производительность в майнинге, а так же уменьшить потребление электричества (благодаря андервольтингу — уменьшения напряжения, подаваемого на GPU и видеопамять). Часто разгон и андервольтинг используются одновременно, благодаря чему можно добиться повышения хешрейта при понижении потребления, звучит неплохо, не правда ли? Для разгона и андервольтинга в Hive OS можно использовать «профили разгона«.

Если вы являетесь новичком, или до текущего момента не имели дела с Hive OS, рекомендуем вам прочитать статью «Установка и настройка HiveOS — Linux операционной системы для GPU майнинг ригов и асиков», где подробно и по шагам описан процесс установки и изначальной настройки этой операционной системы для майнинга.

Идеальный разгон всегда подбирается путем «проб и ошибок», поэтому если вы хотите добиться оптимального соотношения хешрейта на ватт, Вам придется немало поэкспериментировать. Однако, Hive OS сможет Вам сильно помочь в этом, так как в него встроена база данных профилей разгона других пользователей, с удобным фильтром по типу видеокарт. Если вы не уверенны какие настройка вам установить изначально, вы можете выбрать один из популярных пресетов для своей видеокарты, а затем уже начинать менять настройки. После каждого изменения настроек разгона и андервольтинга мы рекомендуем запустить майнинг на какое-то более менее продолжительное время, чтобы убедиться что ваше оборудование продолжает работать стабильно и не появились «отклоненные шары» (это могут быть как не верные решения, которые отправляет ваша видеокарта в связи с чрезмерным разгоном, так и не вовремя отправленные шары). Большое количество отклоненных шар, часто является одним из признаков нестабильной работы, в этом случае рекомендуем немного снизить разгон и выполнить повторную проверку.

Создание профиля разгона

Для каждой фермы создаются свои индивидуальные профили разгона и они не могут быть использованы в другой ферме. У вас есть возможность создать профиль разгона для всей фермы или же для конкретного воркера. Профиль конкретного воркера всегда будет иметь более высокий приоритет, и перекрывать общие настройки для фермы. Таким образом, рекомендуется сначала задать оптимальные значения параметров для всей фермы, а затем (если это необходимо) уже настраивать каждый риг (он же воркер) по отдельности.

Итак, для создания нового профиля разгона просто перейдите на вкладку «Шаблоны разгона» («Overclocking Profiles») для вашей фермы, а затем нажмите кнопку «Добавить OC Профиль» («Add OC Profile»). Теперь в появившемся окне «Сохранить Разгон в Качестве Шаблона» («Save Overclocking as Template») назовите ваш новый профиль и нажмите «Сохранить» («Save»).

Вы создали шаблон разгона, который может быть использован конкретными воркерами или же всей вашей фермой. Вы всегда можете его скопировать и изменить для различных алгоритмов и майнеров. Хотя, созданный вами шаблон и будет использоваться для всех ваших GPU, настройки разгона для видеокарт Nvidia и AMD разные. Имейте ввиду, что вы можете иметь различные наборы настроек для разных типов графических процессоров (Nvidia, AMD) в одном и том же профиле и если ваш воркер работает на Nvidia и AMD, то настройки будут применяться к каждому типу GPU индивидуально.

Для того, чтобы отредактировать профиль разгона, просто нажмите на иконку с плюсом, которая находится справа от имени вашего профиля. Кроме того, вы можете использовать популярные шаблоны разгона от других пользователей, зайдя на вкладку «Популярные пресеты» и выбрав из списка вашу модель видеокарты.

Разгон видеокарт Nvidia.

Перед тем как менять настройки разгона вы можете запустить команду «nvidia-smi» через встроенный в Hive Os терминал, для того, чтобы определить текущие настройки ваших GPU. Для того, чтобы сделать это удаленно с панели управления HiveOS, перейдите к вашему воркеру, а затем нажмите на кнопку «Выполнить команду» («Run command») на основной панели инструментов, находящейся в верхней части экрана. В появившемся окне, к тому же, будет справочная информация по другим полезным командам, которые могут пригодится при разгоне и настройке ваших ригов. В появившемся окне в поле слева от кнопки пуск введите команду, после чего нажмите на «Пуск«. После закрытия окна подождите некоторое время (от нескольких секунд до нескольких минут) пока сгенерируется отчет. Для просмотра отчета просто кликните на него.

Теперь поговорим непосредственно про настройки разгона и андервольтинга для Nvidia GPU. У вас есть возможность задать одно общее значение каждого параметра для всех GPU в риге или же указать раздельные значения для каждой видеокарты через пробел. Например:

• 100 — общее значение для всех видеокарт в риге.
• 0 100 0 150 0 — значение 0 для GPU0, 100 для GPU1, 0 для GPU2, 150 для GPU3 и 0 для GPU4.

Чтобы указать настройки для определенного алгоритма, выберите его в списке «Алгоритм» («Algo»). Для каждого алгоритма можно создать индивидуальный набор настроек. При выборе пункта «Настройки по умолчанию» («Default config») ваши настройки будут применимы ко всем алгоритмам, однако они могут быть переписаны настройками в самих алгоритмах.

Подробнее про настройки

• +Частота ядра (Mhz) — Увеличивает тактовую частоту ядра GPU в Мгц. Если ввести значение 0 — это установит значение по умолчанию для ваших видеокарт.
• Частота памяти (Mhz) — увеличивает тактовую частоту видеопамяти. Следует указывать вдвое большее значение, чем вы видите в MSI Afterburner в Windows. Например если в Windows вы устанавливали частоту памяти +500, то вы должны указать значение 1000.
• Вент (%) — служит для настройки скорости вращения вентиляторов на ваших видеокартах в процентах. Если ввести значение 0 — это установит значение по умолчанию для ваших видеокарт. Скорость вращения вентиляторов по-умолчанию прописана в BIOS ваших видеокарт и не зависит от использованного майнера.
• Предел потребления (W) — эта опция предназначена для контроля энергопотребления ваших видеокарт. В отличие от того же Afterburner, где значения указываются в процентах, в случае с HiveOS следует указывать абсолютные значения в Ваттах. Узнать предельные значения для ваших видеокарт можно в списке видеокарт вашего рига. Для примера, значения PL 60 W, 120 W, 140 W означают, что первое значение в 60W — минимальное, второе — 120W — значение по умолчанию и третье — 140W — максимально возможное для установки значение. Если вы установите значения больше максимального или меньше минимального, то этот параметр не будет применен.

После изменения параметров просто нажмите на кнопку «Сохранить«.

Для примера разгон Nvidia GTX 1060.

• Алгоритм: Значение по умолчанию.
• +Частота ядра (Mhz) — 130.
• Частота памяти (Mhz) — 2000.
• Вент (%) — оставляем пустым для настроек по умолчанию.
• Предел потребления (W) — 120.

Разгон видеокарт AMD.

Перед тем как менять настройки разгона вы можете запустить команду «amd-info» через встроенный в Hive Os терминал, для того, чтобы определить текущие настройки ваших GPU. Для того, чтобы сделать это удаленно с панели управления HiveOS, перейдите к вашему воркеру, а затем нажмите на кнопку «Выполнить команду» («Run command») на основной панели инструментов, находящейся в верхней части экрана. В появившемся окне, к тому же, будет справочная информация по другим полезным командам, которые могут пригодится при разгоне и настройке ваших ригов. В появившемся окне в поле слева от кнопки пуск введите команду, после чего нажмите на «Пуск«. После закрытия окна подождите некоторое время (от нескольких секунд до нескольких минут) пока сгенерируется отчет. Для просмотра отчета просто кликните на него.

У вас есть возможность задать одно общее значение каждого параметра для всех GPU в риге или же указать раздельные значения для каждой видеокарты через пробел. Например:

• 100 — общее значение для всех видеокарт в риге.
• 0 100 0 150 0 — значение 0 для GPU0, 100 для GPU1, 0 для GPU2, 150 для GPU3 и 0 для GPU4.

Чтобы указать настройки для определенного алгоритма, выберите его в списке «Алгоритм» («Algo»). Для каждого алгоритма можно создать индивидуальный набор настроек. При выборе пункта «Настройки по умолчанию» («Default config») ваши настройки будут применимы ко всем алгоритмам, однако они могут быть переписаны настройками в самих алгоритмах.

Подробнее про настройки

• Частота ядра (Mhz) — Служит для настройки частоты ядра. Неплохим значением для начала может быть 1100. Если не настроен параметр «Состояние ядра«, то для настройки частоты будет использоваться значение по умолчанию «5«. Все значения должны быть абсолютными.
• Состояние ядра, индекс — опция будет необходима если вы хотите снизить энергопотребление видеокарты. Следует использовать данную опцию совместно с «Частотой ядра» и «Напряжением ядра«. Это называется DPM (Dynamic Power Management, Динамическое Управление Питанием) или же «Power Level» (Уровень мощности) ядра GPU. Для RX GPU, это значение от 1 до 7. Значение по умолчанию — 5. Понизьте это значение для даунвольтинга. Если вы решили использовать одно из значений по умолчанию, тогда вам не нужно настраивать значения в «Частотой ядра» и «Напряжением ядра».
• Напряжение ядра, mV — необходимо, если вы пытаетесь понизить напряжение на вашем GPU. Вам также нужно настроить «Состояние ядра«, или же для настройки напряжения будет использовано значение по умолчанию «5». Вы можете, к примеру, установить значение 900 (мВ), или значение 65284 из таблицы VBIOS.
• Частота памяти (Mhz) — служит для установки частоты памяти. Все значения являются абсолютными.
• Состояние памяти, индекс — очень продвинутый параметр. Измените его, если есть проблемы с понижением напряжением. Если все работает в пределах спецификации — не меняйте это значение. Известно, что карты RX имеют 1 или 2 значения памяти (3, включая 0 — состояние ожидания). По умолчанию будет выбрано самое высокое значение. Но некоторые редкие карты, не способны к андевольтингу при высшем значении, и нуждаются в более низком. Например, наивысшее значение равно 2, и для андервольтинга вы можете установить значение 1. Этот параметр следует использовать с настройкой Частоты памяти.
• Memory Controller Voltage, m — устанавливает напряжение для контроллера памяти (VDDCI). В данный момент применимо только для видеокарт серии NAVI. Значение по умолчанию 850 mV. Допустимый интервал 750-850 mV. Используйте этот параметр только если понимаете что делаете, может повлиять на стабильность системы.
• Вент (%) — служит для настройки скорости вращения вентиляторов на видеокартах. Имейте ввиду, что некоторые майнеры вроде Claymore все равно будут сами контролировать скорость вентилятора. Вы должны отключить управление вентилятором в конфигурации майнера, чтобы эта настройка работала. Мы рекомендуем оставить это поле пустым, если у вас включен AutoFan.
• Предел потребления (W) — Устанавливает максимальное энергопотребление в Ваттах для ядра GPU. В большинстве случаев не требуется настройка этого параметра для карт AMD если ранее были настроены параметры Частота ядра и Напряжением ядра. В данный момент опция неприменима для карт серий VEGA и NAVI.
• SoC частота, Mhz —Этот параметр устанавливает максимальную частоту SoC и доступен для современных ГПУ AMD, начиная с семейства VEGA. Значение по умолчанию для RX 5700 — 1267 МГц. Понижение частоты может привести к снижению энергопотребления и падения температуры. но также может вызвать нестабильность вашего ГПУ. Пожалуйста, используйте этот параметр очень осторожно!

Теперь осталось нажать на кнопку «Сохранить«.

Пример разгона для 6 карт AMD RX 580

Значения показанные ниже приведены для примера, возможно для ваших карт будут оптимальные другие значения. Используйте на свой страх и риск.

Применяем профиль разгона

Теперь, для того, чтобы применить созданный вами профиль, перейдите на вкладку с воркерами и отметьте галочкой слева те воркеры, к которым вы собираетесь применить профиль разгона. Вы должны будете увидеть иконку спидометра в строке меню в правом верхнем углу экрана.

Если нажать на эту иконку спидометра, перед вами появится окно, в котором отобразится количество выбранных вами воркеров и список всех ваших полетных листов. Выберите профиль разгона, который вы хотите использовать и нажмите на кнопку «Применить«. В итоге вы должны увидите сообщение о том, что команда разгона была отправлена на воркер. Через некоторое время ваши воркеры должны будут применить изменения.

Возможно, разгон видеокарт под HiveOS не такая уж и тривиальная задача для новичка, но мы попытались максимально подробно и понятно рассказать о процессе разгона как для видеокарт AMD, так и для графических процессоров Nvidia. Хотя некоторые майнеры используют всегда настройки по умолчанию, и не разгоняют оборудование, как нам кажется, разгон и андервольтинг является неплохим подспорьем для увеличения хешрейта в майнинге или уменьшения потребления ригов. Часто благодаря разгону и андервольтингу удается добиться увеличения хешрейта при одновременном снижении потребления и температур видеокарт.

Load average hive os как уменьшить

Что такое LA (load average) и как правильно его рассчитывать?

LA (load average) — среднее значение загрузки системы за некоторый период времени, как правило, отображается в виде трёх значений, которые представляют собой усредненные величины за последние 1, 5 и 15 минут. Более подробное описание того, что такое LA, можно прочитать в данной статье

Узнать нагрузку на сервере можно прописав команду w через SSH консоль.

Что нужно знать о LA?

Значение LA рассчитывается исходя из процессов, которые выполняются и находятся в очереди на выполнение (CPU, RAM, I/O). В большей степени на LA влияет загруженность процессора, которая в свою очередь является одним из основных факторов повышенной нагрузки на сервере.

Например: У VPS есть два ядра. Значения LA видим на скриншоте выше: 1.03, 1.11, 1.20 — это в пределах нормы для VPS с 2 ядрами.

1(единица) LA = 100% нагрузка на 1 ядро CPU. Соответственно, когда на VPS два ядра, то допустимая средняя нагрузка может достигать 2 LA:

• LA показывает значения 3.78, 4.55, 5.34 — нагрузка идёт на спад, но за последние 15 минут в среднем она была 5.34, что соответствует 534% нагрузки = 5 из 2 ядер — превышение.
• LA показывает значения 7.23, 5.45, 1.22 — нагрузка растёт, и за последние 15 минут она была 1.22, в пределах нормы, что соответствует 122% нагрузки = 1 из 2 ядер — норма (пики нагрузки, держащиеся до 30 мин, допустимы).

Если нагрузка растёт и превышает количество ядер и держится продолжительное время, то несмотря на это, Ваш сервер продолжает работать. В данном случае, LA увеличивает очередь запросов на выполнение и в случае с виртуализацией KVM / OpenVZ данная нагрузка начинает негативно влиять на физический сервер, на котором находится Ваш VPS.

Как правило, мы не реагируем на всплески нагрузки (например, когда выполняется бэкап или выгрузка товаров в 1с), но если мы видим, что LA на физическом сервере гораздо выше нормы, то будем вынуждены предпринять меры, т.к. это будет иметь негативный эффект для всех клиентов на данном физическом сервере.

• load average, la, cpu, нагрузка, vds, vps, cputime
• 40 Пользователи нашли это полезным

Похожие статьи

Если у вашего сайта не отображаются латинские буквы, как в данном примере:То вам необходимо.

Для VPS/VDS Сервера мы предлагаем панель управления ISPmanager Lite совершенно бесплатно*.

Мы рады сообщить, что теперь управлением DNS записями для Ваших доменов стало проще и доступнее.

Мануал написан для тех, у кого установлена панель управления ISPmanager Lite и операцинная.

У Вас выскакивает ошибка «Конвертация в UTF-8 не поддерживается на стороне сервера» при.

как понизить Load Average?

здравствуйте как понизить лоад авэредж. вставлял карты по очереди, менял первую вставленую карту на другую, повышал напряжение до 900 на всех и все бес толку. пулл хайв, майнер тимрэд сейчас 1,9 но он постоянно скачет от 1,8 до 2,5 приблизительно,, я так понимаю что какая то из карт вешается? ну так я и разгон уменьшал и напругу повышал ничего

Load Average в Linux: разгадка тайны

Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.

Средние значения нагрузки в Linux — это «средние значения нагрузки системы», показывающие потребность в исполняемых потоках (задачах) в виде усреднённого количества исполняемых и ожидающих потоков. Это мера нагрузки, которая может превышать обрабатываемую системой в данный момент. Большинство инструментов показывает три средних значения: для 1, 5 и 15 минут:

• Если значения равны 0.0, то система в состоянии простоя.
• Если среднее значение для 1 минуты выше, чем для 5 или 15, то нагрузка растёт.
• Если среднее значение для 1 минуты ниже, чем для 5 или 15, то нагрузка снижается.
• Если значения нагрузки выше, чем количество процессоров, то у вас могут быть проблемы с производительностью (в зависимости от ситуации).

По этому набору из трёх значений вы можете оценить динамику нагрузки, что безусловно полезно. Также эти метрики полезны, когда требуется какая-то одна оценка потребности в ресурсах, например, для автоматического масштабирования облачных сервисов. Но чтобы разобраться с ними подробнее, нужно обратиться и к другим метрикам. Само по себе значение в диапазоне 23—25 ничего не значит, но обретает смысл, если известно количество процессоров, и если речь идёт о нагрузке, относящейся к процессору.

Вместо того, чтобы заниматься отладкой средних значений нагрузки, я обычно переключаюсь на другие метрики. Об этом мы поговорим ближе к концу статьи, в главе «Более подходящие метрики».

История

Изначально средние значения нагрузки показывают только потребность в ресурсах процессора: количество выполняемых и ожидающих выполнения процессов. В RFC 546 есть хорошее описание под названием «TENEX Load Averages», август 1973:

Версия на ietf.org ведёт на PDF-скан графика, нарисованного вручную в июле 1973, демонстрирующего, что эта метрика используется десятилетиями:

source: https://tools.ietf.org/html/rfc546

Сегодня можно найти в сети исходный код старых операционных систем. Вот фрагмент из TENEX (начало 1970’s) SCHED.MAC, на макроассемблере DEC:

А вот фрагмент из современной Linux (include/linux/sched/loadavg.h):

В Linux тоже жёстко прописаны константы на 1, 5 и 15 минут.

Аналогичные метрики были и в более старых системах, включая Multics, которая содержала экспоненциальное среднее значение очереди планируемых заданий (exponential scheduling queue average).

Три числа

Три числа — это средние значения нагрузки для 1, 5 и 15 минут. Вот только они на самом деле не средние, и не для 1, 5 и 15 минут. Как видно из вышеприведённого кода, 1, 5 и 15 — это константы, используемые в уравнении, которое вычисляет экспоненциально затухающие скользящие суммы пятисекундного среднего значения (exponentially-damped moving sums of a five second average). Так что средние нагрузки для 1, 5 и 15 минут отражают нагрузку вовсе не для указанных временных промежутков.

Если взять простаивающую систему, а затем подать в неё однопоточную нагрузку, привязанную к процессору (один поток в цикле), то каким будет одноминутное среднее значение нагрузки спустя 60 секунд? Если бы это было просто среднее, то мы получили бы 1,0. Вот график эксперимента:

Визуализация эксперимента по экспоненциальному затуханию среднего значения нагрузки.

Так называемое «одноминутное среднее значение» достигает примерно 0,62 на отметке в одну минуту. Доктор Нил Гюнтер подробнее описал этот и другие эксперименты в статье How It Works, также есть немало связанных с Linux комментариев на loadavg.c.

Непрерываемые задачи Linux

Когда в Linux впервые появились средние значения нагрузки, они отражали только потребность в ресурсах процессора, как и в других ОС. Но позднее они претерпели изменения, в них включили не только выполняемые задачи, но и те, что находятся в непрерываемом состоянии (TASK_UNINTERRUPTIBLE или nr_uninterruptible). Это состояние используется ветвями кода, которые хотят избежать прерывания по сигналам, в том числе задачами, блокированными дисковым вводом/выводом, и некоторыми блокировками. Вы могли уже сталкиваться с этим состоянием: оно отображается как состояние «D» в выходных данных ps и top . На странице ps(1) его называют «uninterruptible sleep (usually IO)».

Внедрение непрерываемого состояния означает, что в Linux средние значения нагрузок могут увеличиваться из-за дисковой (или NFS) нагрузки ввода/вывода, а не только ресурсов процессора. Всех, кто знаком с другими ОС и их средними нагрузками на процессор, включение этого состояния поначалу сильно смущает.

Зачем? Зачем это было сделано в Linux?

Существует несметное количество статей по средним нагрузкам, многие из которых упоминают про nr_uninterruptible в Linux. Но я не видел ни одного объяснения, или хотя бы серьёзного предположения, почему начали учитывать это состояние. Лично я предположил бы, что оно должно отражать более общие потребности в ресурсах, а не только применительно к процессору.

В поисках древнего патча для Linux

Легко понять, почему в Linux что-то меняется: просматриваешь историю git-коммитов для нужного файла и читаешь описания изменений. Я просмотрел историю на loadavg.c, но изменение, добавляющее неизменяемое состояние, датировано более ранним числом, чем файл, содержащий код из более раннего файла. Я проверил другой файл, но это ничего не дало: код «скакал» по разным файлам. Надеясь на удачу, я задампил git log -p по всему Github-репозиторию Linux, содержащему 4 Гб текста, и начал читать с конца, отыскивая место, где впервые появился этот код. Это мне тоже не помогло. Самое старое изменение в репозитории датировано 2005-м, когда Линус импортировал Linux 2.6.12-rc2, а искомое изменение было внесено ещё раньше.

Есть старинные репозитории Linux (1 и 2), но и в них отсутствует описание этого изменения. Стараясь найти хотя бы дату его внедрения, я изучил архив на kernel.org и обнаружил, что оно было в 0.99.15, а в 0.99.13 ещё не было. Однако версия 0.99.14 отсутствовала. Мне удалось её отыскать и подтвердить, что искомое изменение появилось в Linux 0.99.14, в ноябре 1993. Я надеялся, что мне поможет описание этого релиза, но и здесь я не нашёл объяснения:

Он упомянул лишь основные изменения, не связанные со средним значением нагрузки.

По дате мне удалось найти архивы почтовой рассылки kernel и конкретный патч, но более старое письмо было датировано аж июнем 1995:

Я начал ощущать себя проклятым. К счастью мне удалось обнаружить старые архивы почтовой рассылки linux-devel, вытащенные из серверного бэкапа, зачастую хранящиеся как архивы дайджестов. Я просмотрел более 6000 дайджестов, содержащих свыше 98 000 писем, из которых 30 000 относились к 1993 году. Но ничего не нашёл. Казалось, исходное описание патча потеряно навеки, и ответа на вопрос «зачем» мы уже не получим.

Происхождение непрерываемости

Но вдруг на сайте oldlinux.org в архивированном файле почтового ящика за 1993 я нашёл это:

Было просто невероятно прочитать о размышлениях 24-летней давности, ставших причиной этого изменения. Письмо подтвердило, что изменение в метрике должно было учитывать потребности и в других ресурсах системы, а не только процессора. Linux перешла от «средней нагрузки на процессор» к чему-то вроде «средней нагрузки на систему».

Упомянутый пример с диском с более медленной подкачкой не лишён смысла: снижая производительность системы, потребность в ресурсах (исполняемые и ждущие очереди процессы) должна расти. Однако средние значения нагрузки снижались, потому что они учитывали только состояния выполнения процессора (CPU running states), но не состояния подкачки (swapping states). Маттиас вполне справедливо считал это нелогичным, и потому исправил.

Непрерываемость сегодня

Но разве средние значения нагрузки в Linux иногда не поднимаются слишком высоко, что уже нельзя объяснить дисковым вводом/выводом? Да, это так, хотя я предполагаю, что это следствие новой ветви кода, использующей TASK_UNINTERRUPTIBLE, не существовавшего в 1993-м. В Linux 0.99.14 было 13 ветвей кода, которые напрямую использовали TASK_UNINTERRUPTIBLE или TASK_SWAPPING (состояние подкачки позднее убрали из Linux). Сегодня в Linux 4.12 почти 400 ветвей, использующих TASK_UNINTERRUPTIBLE, включая некоторые примитивы блокировки. Вероятно, что одна из этих ветвей не должна учитываться в среднем значении нагрузки. Я проверю, так ли это, когда снова увижу, что значение слишком высокое, и посмотрю, можно ли это исправить.

Я написал Маттиасу и спросил, что он думает 24 года спустя о своём изменении среднего значения нагрузки. Он ответил через час:

Так что Маттиас до сих пор уверен в правильности этого шага, как минимум относительно того, для чего предназначался TASK_UNINTERRUPTIBLE.

Но сегодня TASK_UNINTERRUPTIBLE соответствует большему количеству вещей. Нужно ли нам менять средние значения нагрузки, чтобы они отражали потребности в ресурсах только процессора и диска? Peter Zijstra уже прислал мне хорошую идею: учитывать в средней нагрузке task_struct->in_iowait вместо TASK_UNINTERRUPTIBLE, потому что это точнее соответствует вводу/выводу диска. Однако это поднимает другой вопрос: чего мы хотим на самом деле? Хотим ли мы измерять потребности в системных ресурсах в виде потоков выполнения, или нам нужны физические ресурсы? Если первое, то нужно учитывать непрерываемые блокировки, потому что эти потоки потребляют ресурсы системы. Они не находятся в состоянии простоя. Так что среднее значение нагрузки в Linux, вероятно, уже работает как нужно.

Чтобы лучше разобраться с непрерываемыми ветвями кода, я хотел бы измерить их в действии. Потом можно оценить разные примеры, измерить затраченное время и понять, есть ли в этом смысл.

Измерение непрерываемых задач

Вот внепроцессорный (off-CPU) флейм-график с production-сервера, охватывающий 60 секунд и показывающий только стеки ядра, на котором я оставил только состояние TASK_UNINTERRUPTIBLE (SVG).

График отражает много примеров непрерываемых ветвей кода:

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

Я сгенерировал график с помощью своего инструмента offcputime из bcc (для работы ему нужны eBPF-возможности Linux 4.8+), а также приложения для создания флейм-графиков:

Для изменения выходных данных с микросекунд на миллисекунды я использую awk. Offcputime «—state 2» соответствует TASK_UNINTERRUPTIBLE (см. sched.h), это опция, которую я добавил ради этой статьи. Впервые это сделал Джозеф Бачик с его инструментом kernelscope, который тоже использует bcc и флейм-графики. В своих примерах я показываю лишь стеки ядра, но offcputime.py поддерживает и пользовательские стеки.

Что касается вышеприведённого графика: он отображает только 926 мс из 60 секунд, проведённые в состоянии непрерываемого сна. Это добавляет к нашим средним значениям нагрузки всего 0,015. Это время, потраченное некоторыми cgroup-ветвями, но на этом сервере не выполняется много дисковых операций ввода/вывода.

А вот более интересный график, охватывающий только 10 секунд (SVG):

Более широкая башня справа относится к блокируемому systemd-journal в proc_pid_cmdline_read() (чтение /proc/PID/cmdline), что добавляет к среднему значению нагрузки 0,07. Слева более широкая башня page fault, тоже заканчивающаяся на rwsem_down_read_failed() (добавляет к средней нагрузке 0,23). Я окрасил эти функции пурпурным цветом с помощью поисковой фичи в моём инструменте. Вот фрагмент кода из rwsem_down_read_failed() :

Это код получения блокировки, использующий TASK_UNINTERRUPTIBLE. В Linux есть прерываемые и непрерываемые версии функций получения мьютексов (mutex acquire functions) (например, mutex_lock() и mutex_lock_interruptible() , down() и down_interruptible() для семафоров). Прерываемые версии позволяют прерывать задачи по сигналу, а затем будить для продолжения обработки прежде, чем будет получена блокировка. Время, потраченное на сон в непрерываемой блокировке, обычно мало добавляет к среднему значению нагрузки, и в данном случае прибавка достигает 0,3. Если бы было гораздо больше, то стоило бы выяснить, можно ли уменьшить конфликты при блокировках (например, я начинаю копаться в systemd-journal и proc_pid_cmdline_read() !), чтобы улучшить производительность и снизить среднее значение нагрузки.

Имеет ли смысл учитывать эти ветви кода в средней нагрузке? Я бы сказал, да. Эти потоки остановлены посреди выполнения и заблокированы. Они не простаивают. Им требуются ресурсы, хотя бы и программные, а не аппаратные.

Анализируем средние значения нагрузки в Linux

Можно ли полностью разложить на компоненты среднее значение нагрузки? Вот пример: на простаивающей 8-процессорной системе я запустил tar для архивирования нескольких незакэшированных файлов. Приложение потратило несколько минут, по большей части оно было блокировано операциями чтения с диска. Вот статистика, из трёх разных окон терминала:

Я также построил внепроцессорный флейм-график исключительно для непрерываемого состояния (SVG):

Средняя нагрузка в последнюю минуту составила 1,19. Давайте разложим на составляющие:

• 0,33 — процессорное время tar (pidstat)
• 0,67 — непрерываемые чтения с диска, предположительно (на графике 0,69, полагаю, что для него сбор данных начался чуть позже и охватывает немного другой временной диапазон)
• 0,04 — прочие потребители процессора (пользователь mpstat + система, минус потребление процессора tar’ом из pidstat)
• 0,11 — непрерываемый дисковый ввод/вывод воркеров ядра, сбросы на диск (на графике две башни слева)

В сумме получается 1,15. Не хватает ещё 0,04. Частично сюда могут входить округления и ошибки измерения сдвигов интервала, но в основном это может быть из-за того, что средняя нагрузка представляет собой экспоненциально затухающую скользящую сумму, в то время как другие используемые метрики (pidstat, iostat) являются обычными средними. До 1,19 одноминутная средняя нагрузка равнялась 1,25, значит что-то из перечисленного всё ещё тянет метрику вверх. Насколько? Согласно моим ранним графикам, на одноминутной отметке 62 % метрики приходилось на текущую минуту, а остальное — на предыдущую. Так что 0,62 x 1,15 + 0,38 x 1,25 = 1,18. Достаточно близко к полученному 1,19.

В этой системе работу выполняет один поток (tar), плюс ещё немного времени тратится потоками воркеров ядра, так что отчёт Linux о средней нагрузке на уровне 1,19 выглядит обоснованно. Если бы я измерял «среднюю нагрузку на процессор», то мне показали бы только 0,37 (расчётное значение из mpstat), что корректно только для процессорных ресурсов, но не учитывает тот факт, что нужно обрабатывать более одного потока.

Надеюсь, этот пример показал вам, что эти числа берутся не с потолка (процессор + непререрываемые), и вы можете сами разложить их на составляющие.

Смысл средних значений нагрузки в Linux

Я вырос на операционных системах, в которых средние значения нагрузок относились только к процессору, так что Linux-вариант всегда меня напрягал. Возможно, настоящая проблема заключается в том, что термин «средняя нагрузка» так же неоднозначен, как «ввод-вывод». Какой именно ввод/вывод? Диска? Файловой системы? Сети. Аналогично, средние нагрузки чего? Процессора? Системы? Эти уточнения помогли мне понять:

• В Linux средние нагрузки — это (или пытаются быть) «средние значения нагрузки на систему», систему в целом. Они измеряют количество выполняемых потоков и ожидающих своей очереди (процессор, диск, непрерываемые блокировки). Иными словами, эта метрика отражает количество потоков, которые не простаивают полностью. Преимущество: учитывается потребность в разных ресурсах.
• В других ОС средние нагрузки — это «средние значения нагрузки на процессор». Они измеряют количество потоков, выполняемых и готовых к выполнению в процессоре. Преимущество: проще в понимании и обосновании (только для процессоров).

Есть и другой возможный тип метрики: «средние значения нагрузки на физические ресурсы», куда входит нагрузка только на физические ресурсы (процессор и диск).

Возможно, когда-нибудь мы начнём учитывать в Linux и другие нагрузки, и позволим пользователям выбирать, что они хотят видеть: средние нагрузки на процессор, на диск, на сеть и так далее. Или вообще использовать всё вместе.

Что такое «хорошие» или «плохие» средние нагрузки?

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

Применительно к средней нагрузке на процессор кто-то может делить значения на количество процессоров и затем утверждать, что если соотношение больше 1,0, то могут возникнуть проблемы с производительностью. Это довольно неоднозначно, поскольку долгосрочное среднее значение (как минимум одноминутное) может скрывать в себе разные вариации. Одна система с соотношением 1,5 может прекрасно работать, а другая с тем же соотношением в течение минуты может работать быстро, но в целом производительность у неё низкая.

Однажды я администрировал двухпроцессорный почтовый сервер, который в течение дня работал со средней процессорной нагрузкой в диапазоне от 11 до 16 (соотношение между 5,5 и 8). Задержка была приемлемой, никто не жаловался. Но это экстремальный пример: большинство систем будут проседать при нагрузке/соотношении в районе 2.

Применительно к средним значениям нагрузки в Linux: они ещё более неоднозначны, поскольку учитывают разные типы ресурсов, так что не получится просто поделить на количество процессоров. Они полезны для относительного сравнения: если вы знаете, что система хороша работает при значении в 20, а сейчас 40, то пришло время посмотреть на другие метрики, чтобы понять, что происходит.

Более подходящие метрики

Рост средних нагрузок в Linux означает повышение потребности в ресурсах (процессоры, диски, некоторые блокировки), но вы не уверены, в каких. Чтобы пролить на это свет, можно использовать другие метрики. Например, для процессора:

• использование каждого процессора (per-CPU utilization): например, используя mpstat -P ALL 1 .
• использование процессора для каждого процесса (per-process CPU utilization): например, top, pidstat 1 и так далее.
• задержка очереди выполнения (диспетчера) для каждого потока (per-thread run queue (scheduler) latency): например, в /proc/PID/schedstats, delaystats, perf sched
• задержка очереди выполнения процессора (CPU run queue latency): например, в /proc/schedstat , perf sched , моём инструменте runqlatbcc.
• длина очереди выполнения процессора (CPU run queue length): например, используя vmstat 1 и колонку ‘r’, или мой инструмент runqlen bcc .

Первые две — метрики использования, последние три — метрики насыщения (saturation metrics). Метрики использования полезны для оценки рабочей нагрузки, а метрик насыщения — для идентификации проблем с производительностью. Лучшая метрика насыщения для процессора — измерение задержки очереди выполнения (или диспетчера): это время, проведённое задачей/потоком в состоянии готовности к выполнению, но вынужденным ждать своей очереди. Это позволяет вычислить тяжесть проблем с производительностью. Например, какая часть времени тратится потоком на задержки диспетчера. А измерение длины очереди позволяет предположить лишь наличие проблемы, а её серьёзность оценить сложнее.

В Linux 4.6 функция schedstats ( sysctl kernel.sched_schedstats ) стала настраиваться ядром, и по умолчанию выключена. Подсчёт задержек (delay accounting) отражает ту же метрику задержки диспетчера из cpustat, и я предложил добавить её также в htop, чтобы людям было проще ею пользоваться. Проще, чем, к примеру, собирать метрику длительности ожидания (задержка диспетчера) из недокументированных выходных данных /proc/sched_debug:

Помимо процессорных метрик, можете анализировать метрики использования и насыщения для дисковых устройств. Я анализирую их в методе USE, у меня есть Linux-чеклист.

Хотя существуют более явные метрики, это не означает, что средние значения нагрузки бесполезны. Они успешно используются в политиках масштабирования облачных микросервисов наряду с другими метриками. Это помогает микросервисам реагировать на увеличение разных типов нагрузки, на процессор или диски. Благодаря таким политикам безопаснее ошибиться при масштабировании (теряем деньги), чем вообще не масштабироваться (теряем клиентов), так что желательно учитывать больше сигналов. Если масштабироваться слишком сильно, то на следующий день можно будет найти причину.

Одна из причин, по которой я продолжаю использовать средние нагрузки, — это их историческая информация. Если меня просят проверить низкопроизводительные инстансы в облаке, я логинюсь и выясняю, что одноминутное среднее значение нагрузки гораздо ниже пятнадцатиминутного, то это важное свидетельство того, что я слишком поздно заметил проблему с производительностью. Но на просмотр этих метрик я трачу лишь несколько секунд, а потом перехожу к другим.

Заключение

В 1993 году Linux-инженер обнаружил нелогичную работу средних значений нагрузки, и с помощью трёхстрочного патча навсегда изменил их с «со средних нагрузок на процессор» на «средние нагрузки на систему». С тех пор учитываются задачи в непрерываемом состоянии, так что средние нагрузки отражают потребность не только в процессорных, но и в дисковых ресурсах. Обновлённые метрики подсчитывают количество работающих и ожидающих работы процессов (ожидающих освобождения процессора, дисков и снятия непрерываемых блокировок). Они выводятся в виде трёх экспоненциально затухающих скользящих сумм, в уравнениях которых используются константы в 1, 5 и 15 минут. Эти три значения позволяют видеть динамику нагрузки, а самое большое из них может использоваться для относительного сравнения с ними самими.

С тех пор в ядре Linux всё активнее использовалось непрерываемое состояние, и сегодня оно включает в себя примитивы непрерываемой блокировки. Если считать среднее значение нагрузки мерой потребности в ресурсах в виде выполняемых и ожидающих потоков (а не просто потоков, которым нужны аппаратные ресурсы), то эта метрика уже работает так, как нам нужно.

Я откопал патч, с которым было внесено это изменение в Linux в 1993-м — его было на удивление трудно найти, — содержащий исходное объяснение его автора. Также с помощью bcc/eBPF я замерил на современной Linux-системе трейсы стеков и длительность нахождения в непрерываемом состоянии, и отобразил это на внепроцессорном флем-графике. На нём отражено много примеров состояний непрерываемого сна, такой график можно генерировать, когда нужно объяснить необычно высокие средние значения нагрузки. Также я предложил вместо них использовать другие метрики, позволяющие глубже понять работу системы.

В заключение процитирую комментарий из топа kernel/sched/loadavg.c исходного кода Linux:

Hive OS. Установка, настройка, майнинг, команды, обновление. Полный туториал по системе.

Подробно разберем самую популярную систему для майнинга Hive OS. Hive OS представляет собой linux подобную операционную систему для майнинга на видеокартах и асиках. Выясним как правильно установить Hive OS, настроить систему Хайв ОС для стабильной работы, настроить и разогнать видеокарты, как сделать кошелек и полетные листы для запуска майнинга. Изучим команды и возможности обновления. И самое главное, разберем основные причины проблем и ошибок которые встречаются при майнинге на HiveOS.

Майнинг ETHW на Binance Pool

Комиссия 0.2%. Форк эфира. Ежедневные выплаты. Нет комиссий за перевод. Запуск!

БАЗОВЫЙ УРОВЕНЬ, ДЛЯ НОВИЧКОВ

Видео версия гайда по Hive OS

Регистрация в Hive OS

Hive OS промокод на 10$ при регистрации — InsidePC

В первую очередь нужно зарегистрироваться в HiveOS на официальном сайте. По данной ссылке с промо кодом «InsidePC», вы получите 10$ на счет, с которого сможете оплачивать систему. Регистрация в Hive OS ничем не отличает от регистрации в той же Rave OS, о которой мы писали в прошлой статье.

Когда вы попадете на сайт, нажмите на кнопку Sign In.

Регистрация в Hive OS

Если у вас есть промо код, нажмите Have a promo code?, нажмите и введите промо код InsidePC и получите 10$ на счет.

225$ для беженцев из Украины в ЕС!

Binance дарит 225$ для беженцев из Украины в странах ЕС + карта Binance VISA!

Промо код для получения 10$

После регистрации и входа в Hive OS, вы увидите веб интерфейс панели управления.

Панель управления Hive OS.

• Farms (Фермы) — ваши ферм.
• Wallets (Кошельки) — кошельки.
• Flight Sheets (Полетные листы) — полетные листы.
• Overclocking Templates (Шаблоны разгона) — шаблоны разгона.
• Notification (Уведомления) — уведомления.
• Your Funds (Ваши средства) — финансовые ведомости.
• Referrals (Рефералы) — рефералы.
• Account (Аккаунт) — аккаунт.

Как изменить язык системы

Рекомендуем использовать все профессиональные системы и сервисы на английском языке. Но если с английским совсем плохо, вы можете переключить на русский интерфейс. Для этого перейдите Аккаунты — Язык (язык будет сразу первой строчкой в настройках аккаунта). Хайв ОС на русский переведен качественно и профессионально.

Системные требования для Hive OS

Минимальные системные требования:

• Intel® Core™ 2 или лучше / AMD am2+ или лучше
• 4 ГБ ОЗУ*
• 4 ГБ носитель (HDD / SSD / M2 / USB
• Для добычи ETH (курс эфир) на RX Vega 56, RX Vega 64, Radeon VII, RX 5700 потребуется 6 ГБ оперативной памяти

Рекомендованные системные требования:

• Intel® Core™ i3-3220 3,3 ГГц / AMD FX-6300 3,5 ГГц
• 8 ГБ ОЗУ
• 8 ГБ SSD-накопитель

Настройки биос (bios) для материнской платы под Hive OS

• Настройте PCIe Link Speed на GEN2
• Отключите Internal Graphics (если это не нужно вам для монитора)
• Включите Above 4G Decoding
• Выключите CSM Support
• Убедитесь, что приоритет загрузки настроен правильно — устройство хранения, содержащее Hive, должно быть на первом месте
• (Опционально) Restore AC Power Loss (Power On)

Для ASUS B250 Mining Expert, PCIe Link Speed должна быть настроена в двух разных местах

• Advanced\PCH Configuration\PCI Express Configuration -> PCIe Speed -> Gen 2
• Advanced\System Agent (SA) Configuration\PEG Port Configuration -> PCIEX16_1 Link Speed -> Gen 2

И еще несколько рекомендаций касательно B250:

Майнинг Bitcoin на Binance Pool

Комиссия 0.2%. Нет комиссий внутри биржи. Ежедневные выплаты. Начать майнить!

• Некоторые пользователи сообщают о лучшей совместимости с Gen 1 вместо Gen 2 на более крупных ригах
• Некоторые пользователи сообщают об улучшенной стабильности при пустом слоте x16_1
• Обновленный bios может помочь решить множество проблем с платой

Скачиваем образ Hive OS для записи

Для скачивания образа HiveOS, используйте только официальный сайт. Ссылка на скачивания с официального сайта. Hive os скачать нужно обязательно по ней. Образ скачивается в ZIP архиве. Hive OS скачивайте только с официального сайта. Название образа будет примерно таким — hiveos-0.6-190-stable@210108.img.xz. Образ весит около 1,3 Gb.

Прежде чем записать образ Хайв ОС, разархивируйте его. Разархивированный образ для записи должен быть с расширением .img. Скачать hive os не должно составить для вас труда.

Установка образа Hive OS на SSD, HDD, M.2 или флешку

Структура фермы в системе Hive OS

Для понимания правильной настройки ваших ферм в системе Hive OS, объясним иерархию объектов в ферме.

Ферма (Farms) — представьте это как объект, например гараж или комната в которой размещены ваши воркеры или риги (до ригов или воркеров мы еще дойдем). Благодаря объединению ригов в фермы, вы можете разделять их по геолокации, например если у вас риги в разных гаражах, офисах, квартирах, комнатах. Это больше нужно для тех, у кого много ферм и ригов.

Hive os farm позволяют настривать фермы и локации.

Воркер (Workers) — это непосредственно ваш риг. Т.е. материнская плата с процессором, блоком питания и видеокартами. В обычной жизни, это и называют фермой. Как собрать майнинг ферму, читайте на сайте.

До 100$ при регистрации от Binance!

Забери приветственный бонус при регистрации на Binance прямо сейчас!

Нас интересует вкладка Фермы. Справа вверху нажимаем + и добавляем новую ферму.

Создание новой фермы в Hive OS

• Имя — имя фермы.
• Часовой пояс — часовой пояс. Указывайте тот часовой пояс где находится ферма, это необходимо для отображения правильных временных кодов.
• Автотэги — полезная вещь, если у вас много ферм и много ригов. Автоматически помечает тэгами GPU и ASIC.
• Hiveon Pool Charging — данная опция позволят вам не платить за фермы 3$ в месяц, а оплачивать процент с пула. Мы не рекомендуем использовать Hiveon Pool, он не плохой, просто есть гораздо лучше пулы для майнинга эфира. Например Binance.

После создания фермы, вас перебросит на вкладку воркер. Справа вверху будет иконка «+» через которую вы создаете новый воркер.

Создание воркера в HiveOS

• Платформа — выбираете GPU если у вас видеокарты, или ASIC если асики.
• Имя — имя воркера.
• Пароль — пароль воркера, для предоставления доступа.
• Теги — можете задать теги для удобства.
• Описание — описание воркера для себя.

После нажатие на кнопку «Добавить», вы попадаете в настройки рига или воркера.

FARM_HASH and rig.conf

Тут нам нужен FARM_HASH. Это код который нужно будет вставить в образ Hive OS после записи этого образа. Либо вы можете в этом окне сказать rig.conf с уже прописанным FARM_HASH и скопировать в систему после создания образа. Мы рассмотрим оба варианта в Хайв ОС.

Устанавливаем образ Hive OS

Для записи образа Hive OS, проще всего воспользоваться программой HDD Raw Copy Tool. Мы покажем процесс установки на ней, но вы можете воспользоваться программой Etcher, она более современная.

Запускаем HDD Raw Copy Tool и в поле File выбираем образ Hive OS (Please select SOURCE).

HDD Raw Copy Tool для записи Hive OS

Нажимаем Continue и выбираем диск или флешку на которую будем записывать образ в поле ATA (Please select TARGET).

HDD Raw Copy Tool для записи Hive OS

Нажимаем Сontinue и подтверждаем запись.

После записи у вас появиться еще одни жесткий диск с файлами и именем Hive OS.

Вам нужно будет зайти в него и скопировать туда файл rig.conf, который вы скачали на предыдущем шаге. Либо найти там файл rig-config-example.txt и вставить в него FARM_HASH с воркера в поле FARM_HASH и сохранить этот файл с именем rig.conf.

После этого, нужно будет подключить образ к материнской плате фермы. К этому моменту вы уже должны были настроить материнскую плату фермы, ссылки выше на статьи и собрать и подключить ферму.

Запуск майнинга на Hive OS

Для запуска майнинга нужно помимо уже сделанного, создать кошелек и полетный лист.

Создание кошелька в Hive OS (куда мы будем майнить)

Создаем кошелек в Hive OS. В web интерфейсе переходим во вкладку «Кошельки» и нажимаем кнопку «Добавить кошелек». Лучше всего создавать разные кошельки для разных монет, особенно, если вы планируете майнить различные монеты и переключаться между ними. При выборе монеты в Полетных листах, выбор кошельков будет ограничен этой монетой.

Учитесь и зарабатывайте. +5$ сразу!

Проходите курсы и получите криптовалюту. Binance дает 5$ сразу за верификацию!

Создания полетного листа

Полетный лист позволяет переключаться мгновенно между кошелками, пулами, монетами. Это по сути файлы конфигурации вашего воркера.

Для создания полетного листа в Hive OS переходим во вкладку «Полетные листы (Flight Sheets)».

Создание полетного листа в Hive OS

• Монета — выбираем монету. В зависимости от выбранной монеты, будут доступны только кошелки для этой монеты.
• Кошелек — выбираем кошелек который мы создали ранее.
• Пул — выбираем пул на который будем майнить. А так же сервера пула. Если вы выбрали несколько серверов, то воркер будет присоединятся в порядке очереди к каждому следующему если предыдущий перестал работать. Лучше выбрать 2-3 сервера.
• Майнер — выбираем майнер. Рекомендуем использовать NBMiner. При выборе майнера, будет манятся текст Nvidia, AMD или CPU. В зависимости от того с какими картами работает майнер, или процессорами.
• Имя — вводим имя полетного листа.

Запускаем майнинг на Hive OS

Мы сделали все необходимое для запуска майнинга. Выбираем нашу ферму, выбираем наш воркер. Когда вы будете в воркере и будете видеть кол-во карт, перейдите в «Полетные листы».

Запускаем майнинга на Hive OS

Нажимаем справа на ракете и запускаем майнинг.

Поздравляем, вы запустили майнинг на Hive OS. Подождите пару минут пока майнер запустить процесс майнинга.

Настройка аккаунта, фермы и воркера в Hive OS

Настройка аккаунта в Hive OS (Account Profile Settings)

Что бы попасть на страницу настроек аккаунта, с главной страницы Hive OS перейдите во вкладку Аккаунт (Account).

• Language (Язык) — изменения языка системы.
• Profile (Профиль) — логин, имя в системе и email.
• Notifications (Уведомления) — настройка уведомлений в Telegram или Discort.
• Password (Пароль) — изменение пароля.
• Two-factor Authentication (Двухфакторная аутентификация (2FA)) — подключение двухфакторной аутентификации. Дополнительный уровень безопасности.
• White List (Белый список) — белый список ip адресов. Не используйте это на динамическом IP адресе (если ваш интернет-провайдер меняет его или вы заходите через мобильную сеть)
• Authentication Tokens (Токены аутентификации) — Вы можете управлять своими персональными API токенами. Вы можете создать новый для своего стороннего приложения. Или удалить подозрительную сессию. Тут можете увидеть текущие сессии и закрыть их при необходимости. API документация тут.
• Bio (Биография) — тут можно ввести дополнительную информацию о вас: телефон, telegram, skype, информация о компании, часовой пояс.
• Advanced Settings (Расширенные настройки) — Delete account (Удалить аккаунт) — удаления аккаунта.

Настройка фермы в Hive OS

Что бы попасть на страницу настроек фермы в Хайв ОС, нужно выбрать нужную ферму, под каждую ферму свои настройки, и нажать на ссылку «Settings (Настройки)». Какие настройки фермы доступны в Hive OS?

• Name (Имя) — задаем имя фермы. Не на что не влияет.
• Farm Hash — Farm Hash используется для подключения воркера к ферме без предварительного создания в веб.Просто установите его в rig.conf перед первым запуском. Мы не расматриваем такой способ подключения, т.к. есть более удобные, описанные выше.
• ASIC configuration files (Файлы конфигурации ASIC) — Генератор файлов привязки ASIC. Настройка для асиков.
• Tags (Теги) — добавление своих тегов для маркирования воркеров.
• Timezone (Часовой пояс) — часовой пояс фермы.
• Notifications (Уведомления) — возможность настройки уведомлений для фермы. Т.е. они будут распространятся на все воркеры в ферме.
• Electricity price, $/kWh (Цена электроэнергии, $/кВт*ч) — Цена электроэнергии для точных подсчетов потребления. Вы можете установить валюту, добавив ее после пробела. Например: 5.47 RUB.
• Hardware power consumption, watts (Потребляемая мощность, Вт) — Значение по умолчанию для всех воркеров фермы. Может быть изменен для воркера отдельно.
• Power supply unit efficiency, % (КПД блока питания,%) — КПД блока питания для более точных подсчетов потребления. Значение по умолчанию для всех воркеров фермы. Может быть изменен для конкретного воркера.
• Advanced Settings (Расширенные настройки)
• Packages repository server mirror URL (Адрес зеркала сервера хранилища пакетов) — данная настройка позволяет указать локальные пакеты для обновления. Это позволит сохранить трафик и увеличить скорость обновления. Рекомендуется только для тех пользователей, которые понимают что это и точно знают зачем им это.
• Transfer farm (Передача фермы) — Передача фермы другому пользователю. Введите логин существующего пользователя, который будет новым владельцем фермы. Тут все должно быть понятно, передача фермы другому владельцу.
• Remove Farm (Удалить ферму) — Удаление фермы.

Настройка воркера в Hive OS

Для настройки воркера, нужно войти в нужный воркер и перейти во вкладку «Settings (Настройки)». Какие настройки воркера доступны в Hive OS?

• ID — уникальный идентификатор воркера. Так же в строчке с ID есть ссылка на готовый файл rig.conf.
• Farm hash — Farm hash вашего воркера который прописывается в файле rig.conf.
• Name (Имя) — имя воркера.
• Description (Описание) — описание воркера.
• Tags (Теги) — тэги для удобства сортировки видеокарт в воркере по типам памяти, моделям и т.д.
• Password (Пароль) — пароль воркера.
• Resend all configs (Переслать все настройки) — выгрузка настроек воркета для импорта в другую ферму.
• Cards/Boards Quantity (Количество карт/плат) — данный параметр увеличивается автоматически. Но можно его менять и вручную.
• GUI on boot (Отключить GUI при загрузке) — не запускать Х-сервер, только консоль, для Nvidia не будет разгона.
• Maintenance mode (Режим технического обслуживания) — включить режим обслуживания (не запускать майнер и сторожевой таймер при загрузке)
• Push interval (Интервал сброса данных) — Интервал в секундах между отправкой статистики на сервер. По умолчанию 10 секунд. Обратите внимание, что конфиги и команды будут обрабатываться воркеров с одинаковым интервалом.
• Power cycle — когда эта опция включена, все перезагрузки будут выполняться как выключить и включить через 30 секунд.
• DoH — DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Использование DoH повышает конфиденциальность и безопасность пользователей путём предотвращения перехвата и манипулирования данными DNS.
• Miner delay (Задержка старта майнера) — задержка в секундах до запуска майнера при включении воркера.
• Hardware power consumption, watts (Потребляемая мощность, Вт) — вы можете установить энергопотребление «тушки» для более точного расчета энергопотребления.
• Power supply unit efficiency, % (КПД блока питания,%) — вы можете установить КПД блока питания для более точного расчета потребляемой мощности.
• Mirror Select (Выбор зеркала) — если у вас возникли проблемы с подключением к Hive сервера от вашего воркера и часто возникают ложные события не в сети / в сети, вы можете попробовать выбрать другой URL-адрес для подключения к серверу. Иногда возникает проблема с брандмауэром (ваш собственный или ISP) и смена порта может помочь.
• VPN — подключение VPN.
• Advanced Settings (Расширенные настройки)
• Transfer Worker (Перенос воркера) — перенести воркера на другую ферму. Кошелек не переносится с воркером. Пожалуйста, примените кошелек с другой фермы после того как перемещение будет завершено.
• Worker Activation/Deactivation (Активация воркера) — активация и деактивация воркера.
• Remove Worker (Удалить воркера) — удаление воркера.

Подключение и настройка Binance Pool через Hive OS

Подключение и настройка Binance Pool через Hive OS подробно описана в статье по Binance Pool. Переходите и изучайте.

Разгон видеокарт в Hive OS

Разгон видеокарт от NVIDIA

Шаг 1 — Заходим в ферму. Во вкладке Farms(Фермы), выбираем нужную ферму.

Шаг 2 — Заходим на нужный риг. Выбираем риг в котором стоят карты которые мы будем разгонять.

Workers в Hive OS

Шаг 3 — выбираем нужную карту, все карты, определенные карты. Выбираем нужную карту и нажимаем на значок спидометра. Можно выбрать этот значок напротив конкретной карты, либо выбрать значок спидометра с надписью ALL. Тут задаются настройки разгона для всех карт Nvidia или AMD. Если у вас несколько одинаковых карт в риге, можно применить разгон сразу ко всем картам. Так же можно разогнать только определенные карты, об этом ниже.

alt=»Разгон RTX 3070 в HiveOS» width=»1024″ height=»80″ />Разгон RTX 3070 в HiveOS

Шаг 4 — Устанавливаем параметры разгона. Окно настроек для видеокарт от AMD отличается от карт для NVIDIA и имеет свои нюансы:

Оптимальный разгон и настройки RTX 3070 в Hive OS

• В поле +Core Clock Mhz (+Частота ядра Mhz) — указываем частоту в Mhz которую вы добавляете или снижаете от базовой.
• В поле Memory Clock, Mhz (Частота памяти, Mhz) — указываем значение частоты видео памяти. Частота видео памяти указывается умноженная на 2. Т.е. если вам нужно увеличить частоту на 1000 MHz, вбиваете 2000 Mhz. Это особенности разгона на Hive OS и Rave OS.
• В поле Вент., % (0 авто) — частота вращения вентиляторов. Оставляете 0 если у вас стоит Auto Fan.
• Предел потребления, W — указываете предел потребления карты в ваттах.
• Задержка в секундах перед применением разгона — указываете в секундах задержку начала разгона после того, как карта запустилась. Иногда это помогает от отвала видеокарты.
• Выключить подсветку (может не работать на некоторых картах) — очень редко работает.
• OhGodAnETHlargementPill — включает так называемую таблетку (Pill), используется только для карт серии gtx 10 80.
• Pill cmd line params — можно указать ревизию карт для которых для запуска таблетки.
• Задержка перед стартом таблетки в секундах — задержка применения таблетки от времени запуска видеокарты.

Популярные пресеты

В этом разделе, можно выбрать пресет или шаблона разгона который используют другие пользователи Hive OS для таких же карт как у вас.

Popular Presets

Нажимаете на нужный пересет разгона и он применится к вашей карте.

Разгон нескольких карт из рига

Разгон нескольких карт из рига

Заходите в настройки разгона всех карт, и по отдельности указываете значения разгона для каждой отдельной карты. Порядок от GPU 0 до GPU N…

Разгон видеокарт от AMD в Хайв ОС

Для карт от AMD есть гораздо больше настроек для разгона, вы можете указывать не только лимит потребления, но и вольтаж на память, на чип и другие, в зависимости от поколения графического чипа.

Разгон RX 5700 XT в Hive OS

• В поле Core Clock offset, Mhz — указываем частоту в Mhz которую вы добавляете или снижаете от базовой.
• В поле Core voltage, mV — указываем значения потребления графического чипа в милливольтах.
• В поле Memory Clock offset, Mhz — указываем значение частоты видео памяти. Частота видео памяти указывается умноженная на 2. Т.е. если вам нужно увеличить частоту на 1000 MHz, вбиваете 2000 Mhz. Как и для карт NVIDIA.
• В поле Memory voltage, mV — указываем значения потребления видеопамяти в милливольтах.
• В поле Power Limit — указываете предел потребления карты в ваттах.

Polular presets — работают так же как и на картах Nvidia. Выбираете нужный шаблон и применяете его.

Как включить уведомления в Hive OS на Telegram или Discord

Вы можете настроить уведомления по различным событиям в системе и получать их на свой telegram или discord. Какие уведомления можно получать на Telegram и Discord с Hive OS:

• Воркер в сети
• Воркер не в сети
• Воркер загрузился
• Сообщения об ошибках
• Предупреждающие сообщения
• Информационные сообщения
• Выполненные без ошибок
• GPU Temp >= Red Temp + 3°
• Почасовой отчет
• Скорость вентилятора >= Порог + 5%
• Коэф. подтв. шар >= Порог — 5%
• Средняя нагрузка (15 мин) >= Порог + 1
• Потеря GPU/платы
• GPU MEM TEMP >= Red MEM TEMP + 3°
• CPU TEMP >= Red CPU TEMP + 3°
• ASIC Board TEMP >= Red ASIC TEMP + 3°

Список уведомлений очень большой. Что в целом позволит вам во время узнавать и реагировать на любые события на ферме.

Как настроить эти уведомления?

Переходите на Фермы и выбираете нужный Воркер, там ищем вкладку — Настройки. Спускаемся к Уведомлениям.

Уведомления на telegram или discord в hive os

Для настройки уведомлений, перейдите по ссылке на Hive OS Bot, получите код в боте и на email. Введите их в системе и подписка будет оформлена.

Уведомления в Telegram в Hive OS

Обновление системы Hive OS и обновление драйверов для видеокарт

Какая версия Hive OS установлена?

Для обновление Hive OS, обратите внимание, не Ubuntu на базе которой написана Hive OS, а именно Hive OS, необходимо зайти в ваш воркер.

Обновление Hive OS

Желтым цветом вы увидите последнюю версию системы, а рядом белым цветом будет обозначена текущая версия Hive OS. В моем случае, стоит 0.6-203@210503, а последняя версия на данный момент 0.6-203@210512.

Обновление Hive OS до последней версии (Upgrade)

Для обновления Hive OS до последней версии, нажмите на желтую иконку («Upgrade or Downgrade»).

Обновление Hive OS

Во всплывающем окне, вы можете выбрать версию на которую вы можете обновиться, а также почитать основные изменения в новой версии. Выбрав версию, нажимаете серую кнопку внизу «Upgrade». После нажатия кнопки, нужно будет дождаться процесса обновления. Обычно это занимает не более 2х минут.

Кнопка Reboot after complete — обновит воркер после успешного обновления Hive OS.

Как откатиться на предыдущие версии Hive OS (Downgrade)

В той же иконке (Upgrade or Downgrade), выбираем предыдущие версии на которые мы можем сделать откат.

Белым цветом написаны предыдущие версии системы на которые вы можете откатится. Выбираете нужную и нажимаете Upgrade. Все очень просто.

Как обновить драйвера для карт NVIDIA

Обновление драйверов в Hive OS можно сделать только для карт Nvidia, для карт AMD драйвера обновляются вместе с дистрибутивом сомой системы. Т.е. при обновлении версии Hive OS. Прежде чем обновлять драйвера, посмотрите какие драйвера установлены на вашем риге.

Для этого перейдите в Фермы — Воркеры — Выберите нужный воркер и нажмите на него. Попав в воркер, можно посмотреть версию драйверов.

Версия драйвера в HiveOS

В нашем случае версия драйверов — 455.45.01.

Следующий шаг, это узнать последнюю актуальную версия драйвера для карт Nvidia. Нужно запустить Shell.

Находясь в воркере, выбираем «Удаленный доступ» и «Hive Shell Start».

Hive Shell старт

После запуска Hive Shell, открываем окно Hive Shell.

Вводим команду nvidia-driver-update —list.

Вы увидите список доступных драйверов для установки. Узнаете версию Cuda для вашего устройства.

Для обновления драйвера введите команду upt update.

После выполнения этой команды, вводим команду на обновление драйвера.

Если есть более новая версия драйвера, вводите команду nvidia-driver-update 455.38 (указываете версию драйвера), либо просто вбиваете команду nvidia-driver-update и он будет ставить самую последнюю актуальную версию.

Обновления займет пару минут, после успешного обновления драйверов на hive os для nvidia, вы должны увидеть следующее окно:

Nvidia settings reinstall seccessful

Все, обновление драйвера прошло успешно.

Driver installation successful

Как обновить драйвера для карт AMD в Hive OS

Драйвера для карт AMD обновляются вместе с обновлением образа Hive OS. Других варианты не рекомендуются.

Зомби режим в Hive OS

Шаг 1: Заходим в Flight Sheets (полетные листы) и создаем полетный лист. Монету выбираем ETH, прописываем свой кошелек (нужно предварительно его создать), пул, и майнер. Выбираем TeamRedMiner и нажимаем Настроить ( Setup Miner Config).

Создаем Flight Sheets (полетный лист) и выбираем майнер TeamRedMiner

В насройках майнера, находим поле Extra config arguments и вводим следующую команду — —eth_4g_max_alloc 4076.

Эта команда указывает сколько видеопамяти в карте будет использоваться под DAG файл. Все что больше этого значения будет размещаться в оперативной памяти. Чем выше эта цифра, тем меньше будет падение хэшрейта в майнинге. У нас стоит 4076 mb. Это цифру вам нужно подобрать самим. Если на 4076 все работает стабильно, попробуйте поднять на 10 mb.

Нажимаем Apply Changes и сохраняем полетный лист. Полетный лист называем как то понятно, Zomby List или как то так.

Более подробнее про майнинг на картах с 4GB видеопамяти читайте в статье по майнингу на RX 480, RX 570, RX 580.

Проверка логов в Hive OS для поиска проблем и ошибок

В Hive OS есть несколько журналов с логами, которые вы можете анализировать для поиска проблем, ошибок или проверки работы. Вы можете посмотреть журнал майнера и журнал системы.

Как посмотреть лог майнера в Hive OS

Miner Log

Ищем иконку под названием «Miner Actions» и выбираем раздел Miner Log. Вы увидите следующий лог из последних 100 строк работы майнера (это даже не лог, а просто экран майнера):

Miner Log

Настоящие файлы хранятся в /var/log/miner/xxxx/*.log. Как их увидеть?

Открываем «Remote Access» и выбираем Hive Shell Start.

После загрузки терминала, вы увидите иконку открытия терминала в новом окне:

Нажимаем на нее и переходим в терминал, который откроется в соседней вкладке.

У нас откроется терминал в котором мы прописываем команду «mc» и нажимаем Enter.

Переходим стрелками в папку /var/log/miner/xxxx/*.log. Где xxx — это название вашего майнера и внутри этой папки смотрим папку с логом. Для просмотра лога нажимаем F3. Для выхода из mc нажимаем F10.

Как посмотреть системный лог в Hive OS

Для доступа в главный системный журнал, вбейте в Hive Shell — less /var/log/syslog

Команды в Hive OS

Базовые команды

• agent-screen— показывает агент клиента Hive OS (чтобы выйти, нажмите Ctrl+A, D)
• firstrun -f— заново запросить ID рига и пароль
• mc— файловый менеджер, наподобие Norton Commander, но для Linux
• selfupgrade— обновление Hive OS через консоль, то же самое, что нажать кнопку в веб-интерфейсе
• sreboot— выполнить принудительную перезагрузку
• sreboot shutdown— выполнить принудительное отключение

Майнеры

• miner— открывает окно с запущенным майнером (чтобы выйти, нажмите Ctrl+A, D)
• miner start, miner stop— запускает или останавливает настроенный майнер
• miner log, miner config— лог / настройки майнера

Логи системы

• dmesg— показать системные сообщения, в основном, чтобы увидеть лог загрузки
• tail -n 100 /var/log/syslog— показать 100 последних строк из системного лога

Сеть

• ifconfig— показать интерфейсы сети
• iwconfig— показать беспроводные адаптеры

Горячие клавиши

Ctrl+C— остановить любую запущенную команду

Переключение между экранами майнеров, отсоединение от терминала:

• Ctrl+A, D— отсоединить от экрана (майнер или агент), чтобы оставить его работающим
• Ctrl+A, Space or Ctrl+A, 1,2,3— переключение между экранами, если у вас запущено несколько майнеров и т.д.

Продвинутые команды

Статус / Диагностика

• agent-screen log— показать логи разных частей (вы можете использовать log1 и log2) агента Hive
• hello— «поздороваться» с сервером: чтоб обновить IP адреса, настройки, и так далее (обычно выполняется при запуске)
• net-test— проверить и определить сетевое соединение
• timedatectl— показать время и дату настроек синхронизации
• top -b -n 1— показать список всех процессов
• wd status— показать статус и лог хешрейт-вотчдога

AMD

• amd-info— показать данные по картам AMD
• amdcovc— показать данные о питании карт AMD
• amdmeminfo— показать данные о памяти карт AMD
• wolfamdctrl -i 0 —show-voltage— показать таблицу напряжения для видеокарт AMD #0

Nvidia

• journalctl -p err | grep NVRM— показать последние ошибки видеокарт Nvidia
• nvidia-info— показать расширенные данные по картам Nvidia
• nvidia-driver-update— обновление драйверов Nvidia
• nvidia-driver-update 430— скачать и установить последний драйвер из серии 430.*
• nvidia-driver-update —nvs— переустановить только nvidia-settings
• nvidia-smi— показать данные по картам Nvidia
• nvtool —clocks— показать частоты ядра/памяти для всех видеокарт Nvidia

Оборудование

• gpu-fans-find— вращать вентиляторы GPU от первой до последней карты, чтобы упростить поиск необходимого GPU. Можно указать номер карты, тогда вентиляторы запустятся именно на ней. Если воркер запускается корректно, отследить какая карта какой шине соответствует довольно просто. Например, если карта GPU0 имеет шину 01:00.0, и её нужно найти, используйте команду gpu-fans-find 0. Эта команда на некоторое время раскрутит вентиляторы только на этой карте. И так далее по примеру.
• sensors— показать показания напряжения/температуры материнской платы и карты
• sreboot wakealarm 120— выключить блок питания и запустить через 120 секунд
• /hive/opt/opendev/watchdog-opendev power— эмуляция нажатия кнопки питания посредством OpenDev вотчдога
• /hive/opt/opendev/watchdog-opendev reset— эмуляция нажатия кнопки перезапуска посредством OpenDev вачдога

Апгрейд / Установка

• disk-expand -s— расширить раздел Linux, чтобы заполнить оставшееся на диске место
• hpkg list miners— список всех установленных майнеров
• hpkg remove miners— удалить все майнеры
• nvidia-driver-update —remove— удалить все загруженные пакеты драйверов Nvidia, кроме утсановленного на данный момент
• selfupgrade —force— принудительный апгрейд; это поможет в ситуации, когда selfupgrade сообщает, что версия Hive актуальна, но на самом деле это не так

Логи

• journalctl -u hive —no-pager— показать загрузочный лог Hive OS
• journalctl -u hivex —no-pager— показать лог X сервера (графический интерфейс)
• logs-on— записать все логи на диск, они сохранятся после перезагрузок
• logs-off— записать все логи в оперативную память, чтобы уменьшить износ USB-накопителя (по умолчанию)
• log=’/var/log/syslog’; gzip -c9 «$log» | base64 -w 0 | message file «$(basename «$log»)» payload— отправить файл /var/log/syslog на панель управления

Как запускать команды

Есть несколько способов запуска команд, прежде всего вам нужно зайти в нужный воркер:

• Выбрать пункт «Выполнить команду», и вбить необходимую команду.
• Выбрать пункт «Удаленный доступ», и выбрать Hive Shell Start.

Остались вопросы или что то не понятно?

Заходите на наш telegram канал и задавайте их напрямую автору. Помимо общения, публикуем то, чего нет на сайте. Будьте в курсе лучших возможностей заработка на криптовалюте!

Newsletter

Еженедельный отчет по криптопортфелю. Дайджест топовых новостей и возможностей в крипте. Подсвечиваем актуальные темы для заработка!

Владимир — CEO InsidePC. Более 10ти лет в интернет-маркетинге и IT индустрии, 4 года в трейдинге на NYSE, NASDAQ, более 3х лет исключительно в крипте. В фокусе трейдинг, инвестиции, ноды и майнинг. Держу руку на пульсе криптовалютной индустрии. Цель — развитие крипто индустрии в Украине.
Telegram

Load average hive os что это

В вычислениях UNIX загрузка системы (system load) является мерой объема вычислительной работы, которую выполняет компьютерная система. Средняя загрузка (load average) представляет собой среднюю загрузку системы за период времени. Обычно она представлена в виде трех чисел, которые представляют нагрузку на систему в течение последних одно-, пяти- и пятнадцатиминутных периодов.

Расчет нагрузки в стиле Unix

Все Unix и Unix-подобные системы генерируют безразмерную метрику из трех load average чисел в ядре. Пользователи могут легко запросить текущий результат из оболочки Unix, выполнив команду uptime:

Команды w и top показывают те же три числа средней нагрузки, что и ряд утилит с графическим пользовательским интерфейсом. В Linux к ним также можно получить доступ, прочитав файл /proc/loadavg.

Неактивный компьютер имеет число загрузки 0 (бездействующий процесс не учитывается). Каждый процесс, использующий ЦП или ожидающий его (очередь готовности или очередь выполнения) увеличивает номер загрузки на 1. Каждый завершающийся процесс уменьшает его на 1. Большинство систем UNIX учитывают только процессы в запущенном (на ЦП) или исполняемом (ожидающем ЦП) состоянии. Однако в Linux также есть процессы, находящиеся в непрерывном спящем режиме (обычно ожидающие активности диска), что может привести к заметно разным результатам, если многие процессы остаются заблокированными при вводе-выводе из-за загруженной или остановленной системы ввода-вывода. Это, например, включает блокировку процессов из-за сбоя сервера NFS или слишком медленного носителя (например, запоминающих устройств USB 1.x). Такие обстоятельства могут привести к повышенной средней нагрузке, которая не отражает фактического увеличения использования ЦП (но все же дает представление о том, как долго пользователям придется ждать).

Системы рассчитывают среднюю нагрузку как экспоненциально затухающее взвешенное скользящее среднее числа нагрузки. Три значения средней нагрузки относятся к последней, пяти и пятнадцати минутам работы системы.

Интерпретация

Для однопроцессорных систем с ограниченным ЦП можно рассматривать среднюю нагрузку как меру использования системы в течение соответствующего периода времени. Для систем с несколькими процессорами необходимо разделить нагрузку на количество процессоров, чтобы получить сопоставимый показатель.

Например, можно интерпретировать среднюю нагрузку «1.73 0.60 7.98» в однопроцессорной системе как:

Это означает, что эта система (ЦП, диск, память и т. д.) могла бы выполнить всю работу, запланированную на последнюю минуту, если бы она была в 1,73 раза быстрее.

В системе с четырьмя процессорами средняя загрузка 3,73 означает, что в среднем 3,73 процесса готовы к запуску, и каждый из них может быть запланирован для ЦП.

В современных системах UNIX обработка потоков по отношению к средней нагрузке различается. Некоторые системы рассматривают потоки как процессы для целей расчета средней нагрузки: каждый поток, ожидающий запуска, добавляет 1 к нагрузке. Однако другие системы, особенно системы, реализующие так называемую многопоточность M:N (M:N threading), используют разные стратегии, такие как подсчет процесса ровно один раз для загрузки (независимо от количества потоков) или подсчет только потоков, открытых в данный момент пользовательским планировщиком потоков к ядру, который может зависеть от уровня конкурентности, установленного для процесса. Linux, похоже, считает каждый поток отдельно как добавление 1 к нагрузке.

Загрузка ЦП против утилизации ЦП

Сравнительное исследование различных показателей нагрузки показало, что информация о загрузке ЦП, основанная на длине очереди ЦП, намного лучше справляется с балансировкой нагрузки по сравнению с утилизацией ЦП. Причина, по которой длина очереди ЦП лучше, вероятно, состоит в том, что, когда хост сильно загружен, его утилизация ЦП, вероятно, будет близка к 100%, и она не может отражать точный уровень загрузки. Напротив, длина очереди ЦП может напрямую отражать величину нагрузки на ЦП. Например, две системы, одна с 3, а другая с 6 процессами в очереди, с большой вероятностью будут иметь коэффициент использования, близкий к 100%, хотя они, очевидно, различаются.

Расчет загрузки процессора

В системах Linux средняя загрузка не рассчитывается для каждого такта, а определяется значением переменной, которое основано на настройке частоты HZ и проверяется на каждом такте. Этот параметр определяет тактовую частоту ядра в герцах (раз в секунду) и по умолчанию равен 100 для тактов 10 мс. Действия ядра используют это количество тактов для определения времени. В частности, функция timer.c::calc_load(), которая вычисляет среднюю нагрузку, запускается каждые LOAD_FREQ = (5*HZ+1) тактов или примерно каждые пять секунд:

Массив avenrun содержит 1-минутное, 5-минутное и 15-минутное среднее значение. Макрос CALC_LOAD и связанные с ним значения определены в sched.h:

Другие команды производительности системы

Другие команды для оценки производительности системы включают:

Load Average что это такое?

Load Average что это такое?

Если вам не понятно, что такое Load Average, как определить что система перегружена, то тогда вам нужно прочесть мою статью. Я постарался как мог рассказать про все значение средней нагрузки.

Load Average(Средняя нагрузка) – это среднее значение нагрузки на систему в целом, ну или нагрузка на физические компоненты системы. Эти значения измеряют количество потоков, которые ожидают и выполняются.

Изначально Load Average измерял только среднее значение нагрузки на процессор, но в последствии реализовали учет процессов находящихся в непрерывном состоянии. Это привело к тому, что показатели средней нагрузки стали учитывать нагрузку на диски, на сеть, ну и конечно на сам процессор. Большинство людей просто не знает этого и поэтому эти значения вызывают у них непонятные ощущения.

Load Averageдля обычно измеряется в трех диапазонах: 1, 5 и 15 минут. По этим данным можно оценить нагрузку и ее динамику, понять на сколько ваша система загружена. Но эти показания сами по себе не дадут вам большой пользы и значения 10-25 ничего не значат. Нужно еще знать количество процессоров, нагрузку на диски и так далее.

То есть, средняя нагрузка не должна превышать, в идеале, количество ядер у процессора. А вот если она больше количества ядер, то тут нужно разбираться из-за чего. Начать нужно естественно с процессора, затем проверить загрузку дисков, а так же проблемы могут быть в Ethernet сети.

По опыту высокая нагрузка превышающая количество ядер за 1 и 5 минут, но не превышающая за 15 минут говорит о нормальной работе системы, а такой кратковременный скачек вполне допустим. Если же у вас 4 ядра и средняя нагрузка за 15 минут равна 4 и более, то тут скорее всего ваша система перегружена и нужно проводить мероприятия по разгрузке. Вариантов тоже может быть много, от модернизации системы до перевода некоторых сервисов на другие устройства, например перенести базу данных на отдельный сервер или добавить SSD кэш.

Как оценить и выявить причину большой нагрузки на VPS или dedicated server

Как оценить нагрузку на сервер? Что такое load average?

Для оценки нагрузки на сервер в Linux используется понятие load average. Load average – это количество процессов, стоящих в очереди на исполнение. Если значение высокое, значит, некоторым процессам приходится ждать, пока другие освободят ресурсы сервера. В результате время исполнения некоторых процессов может сильно увеличиваться. Если сайт достаточно нагружен, то очередь понемногу растет, и в итоге сайт вообще перестает откликаться.

В load average три числа – это среднее количество процессов в очереди за 1, 5 и 15 минут. Теоретически load average должно быть меньше количества ядер. На VPS клиенту часто выделяют одно ядро, поэтому load average 1-1.5 может быть пределом, при котором не заметно тормозов. В один момент времени одно ядро может выполнять только один процесс. Планировщик ядра распределяет вычислительные возможности процессора между всеми процессами, выполняемыми в системе, и создаётся иллюзия одновременной работы. При этом всегда какое-то количество процессов стоит в очереди. Если речь идет о системе с одним ядром CPU, то при:

load average 10 сервер перегружен, надо принимать меры;

load average >20 сервер сильно тормозит, трудно получить ответ сервера

Если у Вашего сервера несколько ядер, то эти цифры надо увеличить на количество ядер.

Чтобы проверить текущее значение load average, достаточно набрать top в консоли.

Что вызывает большую нагрузку на сервер?

Типичными причинами высокой нагрузки на сервер являются следующие проблемы:

Как проверить загрузку CPU, memory, disk i/o?

Это зависит от того, хотите ли вы проверить текущую нагрузку на сервер или же посмотреть историю нагрузки на сервер. Для проверки текущей загрузки процессора, диска и памяти достаточно воспользоваться командой: top.

Для того, чтобы отслеживать историю нагрузки на процессор, оперативную память и диск, нужно установить и использовать инструмент sar. Как это сделать, подробно описано в этой статье: The Sysadmin’s Toolbox: sar.

Как диагностировать и откорректировать избыточную нагрузку на диск, подробно описано в этой статье: Избыточная нагрузка на диск на VPS: определение причин и устранение проблемы.

Load average hive os что это

Производительность сервера в реальном времени можно посмотреть с помощью утилиты Top. Характеристика Load average показывает нам о количестве процессов ожидающих своего выполнения. По Load average как правило измеряют производительность сервера.

Производительность также проверяется с помощью таких утилит как htop, uptime, top, w и многие другие. Во всех есть такой параметр Load averag. Разберем его подробней.

Load average

Состоит из трех групп цифр.

Проще говоря это интервалы времени, за которые была снята нагрузка, а именно 1 минута, 5 минут и 15 минут, соответственно. Как правило происходит ожидание ресурсов ввода/вывода дисковой подсистемы, центрального процессора или ввода/вывода сетевой подсистемы.

Высокий показатель нагрузки Load average сообщает, что система не справляется с высокой нагрузкой на сервер. Речь идет о всем сервере, а не об отдельных агрегатах. В моей практике был зафиксирован пик:

Это очень большой показатель, жесткие тормоза. Проблема с производительностью жестких дисков. Показатель Load average выше 3-х это уже критично.