За сколько готовы продать час работы одного ядра компьютера для оптимизации советника - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Проголосовал за $1.
Еще хотелось бы отметить, что и за текущую (очень маленькую) цену не всегда есть потребности (объем работы) или сама система так построена, что распределяет нагрузку по своей логике и не даёт работу для более слабым или малоядерным процессорам. Для эксперимента держал задействованным только одно ядро, включен две недели а работал всего где то 20 часов.
В кармане, перед которым обычно ставят вентиь на вдув, стоят винчестеры, которые сами в работе не холодные. //-- Отчасти по этой причине со стороны процессора делают своё "окно" с воздуховодом, чтобы не гонять на процессор теплый воздух внутри корпуса.
Всё, что писАл выше - собственный опыт.
Alexey:
Если он при 70 неделю работать будет, что с ним будет тогда
Если больше 70 температура не идет, и при этой температуре компьютер продолжает функционировать, то значит уже ничего с процессором не будет.
Есть угроза для электролитных конденсаторов - их износ повышается. Поэтому повышенная температура северного моста и процессора будет влиять на температуру близ лежащих компонентов.
Проголосовал за $1.
Еще хотелось бы отметить, что и за текущую (очень маленькую) цену не всегда есть потребности (объем работы) или сама система так построена, что распределяет нагрузку по своей логике и не даёт работу для более слабым или малоядерным процессорам. Для эксперимента держал задействованным только одно ядро, включен две недели а работал всего где то 20 часов.
Не совсем понял, у Вас при оптимизации ядра не загружются? На каком терминале?
Ну загрузка 100% означает лишь одно - рабочая станция не будет отвечать на запросы пользователя, если приоритет дан одному процессу, то все остальные (даже системные) будут просто висеть, в т.ч. и работа Ethernet сети, клавиатура, дисплей и т.п. периферия.
Ну, а если по производительности хотите проверить и сравнить виртуальные ядра с физическим процессором, тут поможет любой софт для теста производительности. Запустите на реальной машине и на виртуальной.
Уверен что 32 виртуальных ядра по 3 ГГц дадут приемлемо сравнимый результат. Во всяком случае я еще не работал на мейнфреймах с общей частотой 100+ ГГц.
Так, как раз приоритет программе ставится минимальный в винде - так компьютер не тормозит при использовании любых других приложений. а при появлении свободных ресурсов - отдает их на оптимизацию. Только можно ли так сделать с VPS?
Так, как раз приоритет программе ставится минимальный в винде - так компьютер не тормозит при использовании любых других приложений. а при появлении свободных ресурсов - отдает их на оптимизацию. Только можно ли так сделать с VPS?
Тогда к чему обсуждение загрузки проца 100% ? ))) Если приоритет минимальный...
На VPS разве что-то мешает запустить распределенные вычисления ?? Вроде нет.
Тогда к чему обсуждение загрузки проца 100% ? ))) Если приоритет минимальный...
На VPS разве что-то мешает запустить распределенные вычисления ?? Вроде нет.
Загрузка 100%, но приоритет использования ресурсов разный. Меня больше интересует четверка.
Про VPS не понял.
Тогда к чему обсуждение загрузки проца 100% ? ))) Если приоритет минимальный...
На VPS разве что-то мешает запустить распределенные вычисления ?? Вроде нет.
Так как гипервизоры в реальности (нет таких технических средств) не умеют жестко контролировать использование разделяемых CPU, то велик риск гарантия, что VPS с нагрузкой в 100% CPU убьет производительность соседей.
Поэтому хостер ставит алерты для контроля нагрузки каждым VPS, а потом смотрит вручную(получив алерт) и принимает решение: сначала предупредить клиента, сразу застопить или подрезать ресурсы. Но так как зачастую нельзя на ходу сменить лимиты у VPS, то вариантов всего два. Чаще один - застопить.
Мой личный опыт: почти все наши проблемы (с 5 хостерами по миру) с VPS были одинаковыми - мгновенная остановка, никаких возвратов средств, иногда даже без писем с уведомлениями.
Ответ про распределенные вычисления на VPS: это невозможно ни теоретически, ни практически. Если не считать жуткий по стоимости расчетный Amazon (покупка оборудования себе окупится на 1-2 месяца).
В противовес расчетам в Амазоне у нас есть на порядки более дешевое и мощное решение с MQL5 Cloud Network, где можно гонять как независимые задачи, так и заниматься связанными Map/Reduce задачами через сбор данных по фреймам. Я для примера могу выложить распределенный переборщик MD5 паролей в клауде - работает отлично.
Так как гипервизоры в реальности (нет таких технических средств) не умеют жестко контролировать использование разделяемых CPU, то велик риск гарантия, что VPS с нагрузкой в 100% CPU убьет производительность соседей.
Поэтому хостер ставит алерты для контроля нагрузки каждым VPS, а потом смотрит вручную(получив алерт) и принимает решение: сначала предупредить клиента, сразу застопить или подрезать ресурсы. Но так как зачастую нельзя на ходу сменить лимиты у VPS, то вариантов всего два. Чаще один - застопить.
Мой личный опыт: почти все наши проблемы (с 5 хостерами по миру) с VPS были одинаковыми - мгновенная остановка, никаких возвратов средств, иногда даже без писем с уведомлениями.
Ответ про распределенные вычисления на VPS: это невозможно ни теоретически, ни практически. Если не считать жуткий по стоимости расчетный Amazon (покупка оборудования себе окупится на 1-2 месяца).
В противовес расчетам в Амазоне у нас есть на порядки более дешевое и мощное решение с MQL5 Cloud Network, где можно гонять как независимые задачи, так и заниматься связанными Map/Reduce задачами через сбор данных по фреймам. Я для примера могу выложить распределенный переборщик MD5 паролей в клауде - работает отлично.
Так как гипервизоры в реальности (нет таких технических средств) не умеют жестко контролировать использование разделяемых CPU, то велик риск гарантия, что VPS с нагрузкой в 100% CPU убьет производительность соседей.
Поэтому хостер ставит алерты для контроля нагрузки каждым VPS, а потом смотрит вручную(получив алерт) и принимает решение: сначала предупредить клиента, сразу застопить или подрезать ресурсы. Но так как зачастую нельзя на ходу сменить лимиты у VPS, то вариантов всего два. Чаще один - застопить.
Мой личный опыт: почти все наши проблемы (с 5 хостерами по миру) с VPS были одинаковыми - мгновенная остановка, никаких возвратов средств, иногда даже без писем с уведомлениями.
Ответ про распределенные вычисления на VPS: это невозможно ни теоретически, ни практически. Если не считать жуткий по стоимости расчетный Amazon (покупка оборудования себе окупится на 1-2 месяца).
Если коротко, то поставщики VPS вводят клиентов в заблуждения, продавая заявленный ресурс, так как этим ресурсов воспользоваться фактически нельзя, за исключением краткосрочных пиковых нагрузок? И при запуски оптимизации аккаунт будет просто заблокирован или процесс остановлен принудительно?