Ядра процессора

Страницы: 1
RSS
Ядра процессора
 
Господа, прошу дать совет в выборе конфигурации виртуалки.
Арендую у UltraVDS.
Пользовался конфигурацией 4 ядра (2,2 Ггц), 4 гб оперативки. Загрузка процессора всегда была ниже 30%. Оперативной памяти тоже использовалось мало, намного меньше 4 Гб.
Я решил ради экономии уменьшить конфигурацию до
2 ядра, 2 гига оперативки.
Пользуюсь. Всё хорошо. Проц загружен меньше 50%, памяти хватает.
Вопрос 1. От понижения железа станут ли роботы медленнее реагировать на события? Колбек DataSourse, приход данных в стакан, колбек OnParam, колбек таблицы всех сделок? У меня такая стратегия, что чем быстрее реакция на события, тем лучше она зарабатывает, поэтому я готов вернуться на старую конфигурацию, если это реально влияет.
Вопрос 2. Стоит ли играться с настройками "Приоритет"? Это в диспетчере задач, где выставляется приоритет для процессов. Если да, то какому процессу давать повышенный приоритет: info.exe, winRos или обоим?
Спасибо.
С Новым Годом!!!
 
Более быстрый процессор решит любую математическую задачу быстрее чем его медленный собрат.
Однако, для конкретной задачи это может быть очень не существенно, что там за математика предшествует коллбекам неизвестно, поэтому кроме как тестированием это не проверить.
 
Станислав, вопрос не про скорость процессора, а про количество ядер. Если при 4 ядрах загрузка ниже 50%, какой смысл держать 4 ядра, может можно понизить до 3?
 
Для максимальной производительности количество ядер должно быть не менее, <количества запущенных роботов + 1> (если QUIK один).
Если это условие соблюдено и частоты процессоров в обоих случаях одинаковы, то потери в производительности быть не должно.
Но есть технология Turbo Boost, которая может изменить расклад. Не знаю работает ли она на виртуалках.

Что касается памяти, то тут немного сложнее. Дело в том, что Windows часть данных выгружает в swap-файл на HDD или SSD (даже если памяти полно). Чем меньше ОЗУ, тем больше данных будет выгружено в swap, а операции чтения/записи на HDD во много раз более затратны, чем с ОЗУ. Поэтому оперативной памяти в Windows много не бывает ))
Если же комп будет часто "свопиться", то потеря в производительности может быть очень существенной.
 
Цитата
Космонавт написал:
Станислав, вопрос не про скорость процессора, а про количество ядер. Если при 4 ядрах загрузка ниже 50%, какой смысл держать 4 ядра, может можно понизить до 3?
Зависит от того как реализована многопоточность в квике. Но все же повышение нагрузки с 30 до 50% на ядро, говорит о том, что некие задачи теперь работают последовательно, а раньше разбрасывались параллельно по ядрам.
 
Цитата
Станислав написал:
Цитата
Но все же повышение нагрузки с 30 до 50% на ядро,
вот тут у вас ошибка.
это общая загрузка процессора, всех ядер.
 
Цитата
Космонавт написал:
 Вопрос 1.   От понижения железа станут ли роботы медленнее реагировать на события? Колбек DataSourse, приход данных в стакан, колбек OnParam, колбек таблицы всех сделок?
 Вопрос 2.   Стоит ли играться с настройками "Приоритет"? Это в диспетчере задач, где выставляется приоритет для процессов. Если да, то какому процессу давать повышенный приоритет: info.exe, winRos или обоим?
1. Все реакции на события в квике - в один поток обрабатываются, т.е. не одном ядре.
второе нужно лишь чтобы система не мешала.

2. Все полезное выполняется только в info.exe
winros лишь для експорта в метасток, этот файл вообще можно смело удалить.
с точки зрения скорости реакции я думаю (но лишь из теоретических предпосылок) есть смысл поднять приоритет процессу инфо-ехе
это должно давать ему приоритет при конкуренции за ядра прооцессора от иногда возникающих системных фоновых задач (другого же у вас нет,надеюсь?)
хотя конкуренции у вас нет судя по загрузке, это хорошо.
но не поднимайте до реал тайм! Сначала попробуйте на локальном компе, чтобы понять к чему это приводит.
 
Цитата
Старатель написал:
Для максимальной производительности количество ядер должно быть не менее, <количества запущенных роботов + 1> (если QUIK один).
Хотя, если все вычисления производятся в колбэках, то для каждого Квика достаточно двух ядер. Здесь большую роль играет частота процессора.
 
*Хотя, если все вычисления производятся в колбэках, а в main - пустой цикл, то для каждого Квика достаточно двух ядер.
 
Рекомендую сделать хронометраж а потом принимать решение.
Но если нужна действительно скорость то надо уходить на прямое подключение к бирже либо выделенный серевер у брокера (есть предложения у некоторых брокеров)
 
Цитата
Николай Камынин написал:
Рекомендую сделать хронометраж а потом принимать решение.
Но если нужна действительно скорость то надо уходить на прямое подключение к бирже либо выделенный серевер у брокера (есть предложения у некоторых брокеров)
у открытия есть.
мне дали 20 дней тестов бесплатно
 
Цитата
Старатель написал:
*Хотя, если все вычисления производятся в колбэках, а в main - пустой цикл, то для каждого Квика достаточно двух ядер.
здесь достаточно умножать на 1.1, а не на 2.
ну и округлять вверх.
 
Цитата
Космонавт написал:
Станислав, вопрос не про скорость процессора, а про количество ядер. Если при 4 ядрах загрузка ниже 50%, какой смысл держать 4 ядра, может можно понизить до 3?
Теоретически:
одно ядро - ввод-вывод с внешних накопителей
одно ядро - работа с каналами связи
одно ядро - обслуживание основного потока КВИК
по ядру на каждый торгуемый инструмент
итого примерно 4000 ядер для торгов на ММВБ
еще несколько десятков тысяч ядер для торговли на западных площадках
правда программу надо писать на CUDA и ставить  NVIDIA
и это уже будет не КВИК.
А для КВИК хватит и двух и даже одного.
как говориться, от числа колес скорость велосипеда не зависит.
 
Остапа несло.
 
Пользовался бесплатным сервисом https://aws.amazon.com/ru/free/
Установил QUIK 6.17, инструменты RI Si. 1 ядро, памяти 512Мб маловато, но у меня все работало.  
 
Цитата
Николай Камынин написал:
А для КВИК хватит и двух и даже одного
Как-то делал "связки", типа quik с коннектором, программа анализа (предполагалось в будущем -- робот) и дополнительное приложение с несколькими сервисами (показывать главное, реализовывать стронний поток). Обе программки должны били еще следить друг за другом и квиком, чтоб не было зависаний. должны были друг друга перезапускать, заставлять коннектиться и т.п.
Связь между приложениями реализовывал с использованием SendMessage (в том числе).
Возникали ситуации, когда SendMessage не получал ответа по причине единого потока, ждущего самого себя.
Приходилось по всякому изъязвляться.
Так вот, были ситуации когда вышеописанные схемы на двухядерном компе работали, а на целероне отказывались.
Страницы: 1
Читают тему (гостей: 1)
Наверх