два робота в одном квике

скрипты (колбеки) работают быстро?

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

По мотивам этой реплики ещё уточняющий вопрос. Если у меня в одном КВИКе работает один единственный ММВБ-шный робот по дата-сорс колбеку. И я по недогадливости не отключил приём данных ФОРТС (Система-Заказ данных). И текущая таблица по ФОРТС тоже открыта. Значит, пока принимается сделка ФОРТС, сделка ММВБ ждёт и становится в очередь?

Да, нужна быстрая реакция на события. При этом не хочется нагромождение из второго КВИКа или второй виртуалки. Только если это действительно даст ускорение реакции. Когда произойдёт нужная ситуация на рынке, мне нужно сразу выставить заявку.

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

мой вопрос не про заявки, а про анализ рыночной информации

Обе виртуалки стоят на одном физическом сервере с одним сетевым интерфейсом? Оба квика подключены к одному серверу QUIK?
За счёт чего предполагается получить "выигрыш я в скорости"?

это скорее всего квант винды для процесса. он кратен 10 мс.
либо задержка сервера брокера
Замечу, что если два скрипта в одном квике, то колбеки будут выполняться последовательно а не параллельно.
потому что колбеки исполняются в основном потоке квика и не зависят от числа скриптов.
просто для каждого скрипта будет дублироваться вызов колбека. т е колбеков будет в два раза больше.
Чтобы колбеки исполнялись параллельно надо внутри колбеков открывать потоки.
А луче (я делал именно так) колбеки выносить в отдельные скрипты. В резлутате будет вообще-то, для каждого колбека будет свой поток.

Не уловил мысль.
1. Расскажите пожалуйста как внутри колбеков открывать потоки
2. Если колбеки выносить в отдельные скрипты, то чем это принципиально отличается от моего варианта, когда внутри одного квика крутится первый робот на фортс и второй робот на ММВБ? Колбеки как раз разнесены по разным скриптам. Разве это не тот вариант, который Вы предложили?
П.С. Я очень плохо ориентируюсь в терминах железа и программирования, извините пожалуйста если я что то не понимаю.

Николай Камынин, я кажется понял вашу мысль. Вы создаёте скрипт с колбеками, без функции main? Скрипт заполняет данными файл.
А рядом крутится торговый робот с функцией main, который считывает данные из файла?
То есть если я создаю:
1. Отдельный скрипт с колбеком ДатаСорс для ммвб
2. Отдеьный скрипт с колбеком ДатаСорс для фортс
3. Отдельный скрипт - торговый робот (без колбеков, берёт данные из файла от соседних колбеков), то они не конкурируют, а работают параллельно?

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

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

Космонавт,
Как я полагаю параллельного получения колбэков с одного сервера QUIK не добиться (разработчики меня поправят, если ошибаюсь) даже на нескольких терминалах.
Значит, то что вы можете ускорить - это исполнение кода самого колбэка, если он у вас действительно медленно работает.
Добиться этого можно либо увеличением частоты процессора либо распараллеливанием исполнения по разным потокам (при наличии ресурсов). Но не внутри одного квика, а в разных терминалах.

Ок. То есть именно увеличение частоты процессора?
Я думал идти по пути увеличения числа ядер. Но у меня и так при 4 ядрах загрузка процессора около 25 или 30 процентов.
Увеличить частоту на виртуалке как раз можно, там есть опция перейти на более дорогое железо.

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

а вот это уже недостаток теоретических знаний по обработке результатов экспериментов.

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

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

Колбек, о котором идёт речь - SetUpdateCallback к функции дата сорс. Внутри него считается несложны индикатор.
Центром прибыли и главной денежной машинкой является робот на ММВБ. Я хочу дать ему полное преимущество.
Попутно я экспериментирую с точно таким же роботом для ФОРТС. Денег он даёт меньше, но сделки на ФОРТС сыпятся чаще, я боюсь что он отбирает скорость от робота ММВБ.
Поэтому я хочу исключить его "вредоносность" для робота на ММВБ.
Это и есть суть моей проблемы.

Давайте воспользуемся бритвой Оккама.Усложнять решение можно только если это необходимо.
1 решение самое простое. Его дал Н.Камынин. Внутри одного КВИКа создать 2 скрипта без функции main. В каждом из них сидит свой колбек. Первый ФОРТС, второй ММВБ. Они раздают информацию на двух роботов ММВБ и ФОРТС. Старатель вроде как отвергает этот вариант.
2 решение немного сложнее: два КВИКа с разными ЮИДами, в каждом из которых крутится свой робот. ФОРТС в одном КВИКе, ММВБ в другом.
3 решение самое сложное (я сейчас им пользуюсь). Две виртуалки, в каждой из которой сидит свой КВИК со своим роботом. Но и тут Старатель опровергает преимущества, но толком не объясняет почему.

Вот я и прошу уважаемых собеседников дать ответ что лучше с точки зрения скорости. Скрипт ФОРТС не должен мешать роботу на ММВБ.

Космонавт,
Никто не сможет дать вам точный ответ, какой вариант будет достаточным и необходимым конкретно в вашем случае. Поскольку вы и сами то толком не знаете, была ли необходимость что-то усложнять. А мы и подавно этого не знаем. Тов. swerg задаёт вам правильные вопросы, прислушайтесь к ним.

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

"Позвольте пару слов без протокола.."
Будем рассматривать работу на многоядерном компе.
---------------------------------
Колбеки.
Полагаю, что в QLUA сделано так, что одноименные колбеки - это таблица указателей на соответствующие функции в скриптах.
Т е например колбек  OnOrder.
Если запускаем две скрипта в которых стоит этот колбек, то в основном потоке будет стоять последовательно два вызова функций этой функции из каждого скрипта.
Как это можно ускорить?
Есть несколько способов.
Вот для примера два из них, которые я делал сам.
------------------------------
Вариант1.
В скриптах создаем пулы потоков для каждого типа колбеков.
Внутри колбека  запускаем соответствующий поток.
При этом потоки можно выделять на каждый инструмент.
Сколько инструментов - столько потоков.
-----------------
Сложность этого варианта в создании и управлении пулами потоков.
---------------------------------
Вариант 2.
На каждый колбек пишем свой скрипт. Его так и называем OnOreder, onParam и т д
Внутри скрипта функция колбека сразу передает управление в Main.
в результате скриптов будет по числу колбеков.
Кроме того , для каждого робота пишем свой скрипт.
т е к колбекам добавляются скрипты роботов
При этом в роботах нет колбеков.
----------
Сложность этого варианта в синхронизации потоков.
Создавать потоки не надо, так как они создаются средствами QLUA.
---------------------------

Космонавт,
похоже вы плохо представляете себе работу информационных потоков с биржи.

1.Данные в терминал в любом случае поступают последовательно. Просто, если у вас заказаны 10 инструментов, это визуально и по временнЫм ощущениям может трактоваться как параллельный приход данных по всем инструментам. Если же заказанных инструментов будет 30, а тем более под 100, то последовательность данных начнет проявляться.
2. Поток биржевой информации сначала - в течение определенного времени - поступает к вашему брокеру, затем проходит обработку на сервере брокера, так как сервер выделяет для отправки вам именно те инструменты, что вы заказывали. И только потом идет отправка на ваш терминал пользователя.
Скорость поступления биржевого потока на сервер брокера определяется возможностями канала, связывающего сервер брокера с биржевым шлюзом + аппаратные возможности сервера брокера в части скорости обработки поступающей информации. При общих равных условиях можно считать эту величину более-менее совпадающей со скоростью поступления информации, если бы вы напрямую были подключены к биржевому шлюзу (тот же сервис Plaza).
Скорость обработки поступившей с биржи информации зависит уже исключительно от того, какие механизмы и нагрузки действуют на сервере вашего брокера. Одно дело - если ваш брокер просто делает выборку по запрошенным инструментам и сразу отправляет ее на ваш терминал клиента, и совершенно другая ситуация, если ваш брокер перед отправкой информации вам по умолчанию проводит  различные тесты и процедуры, которые могут существенно увеличивать величину задержки информации на сервере перед тем, как отправить ее вам. Этот показатель зависит исключительно от особенностей сервера и ПО вашего брокера.
Наконец, скорость обработки поступающей в ваш терминал информации зависит от скоростных характеристик вашего канала связи с брокером и от объема тех субзадач, что включены вами в рамках основного рабочего сеанса на вашем терминале клиента. Этот показатель целиком и полностью определяется вашим провайдером в части скорости информационного прохождения канала, вашим "железом" и количеством тех задач, что вы  выполняете в вашем терминале QUIK.
3. Если вы ставите перед собой задачу добиться минимальной скорости взаимодействия с биржей, то выход только один: арендовать у Мосбиржи подключение к биржевому шлюзу, поставить FIX-интерфейс и собственное ПО по получению и отправке информации. В этом случае вы получите скорость обмена данными как у брокера непосредственно с биржей, а скорость обработки информации вашим клиентским местом будет определяться характеристиками вашего компьютера и оперативностью реагирования вашего ПО. Но в финансовом плане - это самый затратный способ.