Мультитерминальный ММ для MT4 - страница 4

 
-Aleks-:

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

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

Ваша "фактическая ситуация" - тот же хаос, только размноженный на несколько стратегий.

 

-Aleks-:

У меня торгует единовременно порядка 27 советников, проскальзывание даже по мелким ордерам создаст ком неучтенных расходов - убытки могут быть в совокупности значительными. К примеру, рассчитал мой алгоритм ТС тейк профит на открытии бара, отправил заявку менеджеру, тот передал её исполнителю у которого в очереде 75 ордеров, которые нужно выставить/удалить/модифицировать , через минуту дошла очередь до исполнения заявки, а цена скакнула в сторону TP, да так, что наткнулась на фроз уровень, соответственно исполнитель правит TP на ближайший доступный уровень, а этот уровень выходит за пределы (для АТС ) точки разворота и цена не достигает этого уровня, что делать исполнителю - спешно закрывать ордер или как, ведь от менеджера приказов по нему больше не поступит?

Зачем придумывать страшные сказки про очередь и фриз-левел?

Откуда появятся очереди в минуту, по сравнению с торговлей каждого советника отдельно?
Наоборот, из-за отсутствия постоянного ожидания ответа все будет работать быстрее, а приказы по одному инструменту можно будет вообще группировать (например, если один советник хочет открыть 0.1 бай, а второй - 0.2 бай, можно одной операцией открыть 0.3).

В крайнем случае, можно распараллелить исполнение приказов: по разным инструментам (один советник - один инструмент), или просто на несколько советников, как я сделал в трейд-бустере.

 

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

 
Andrey Khatimlianskii:

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

Вообще то советник с АТС потеряет информацию о своих виртуальных ордерах - в этом риск. Будет видно, что не открыто - допустим, но вот "как исправить" будет не ясно, так как некому будет исправлять - советник с АТС не будет знать о данной ситуации.
 
Andrey Khatimlianskii:
 

Зачем придумывать страшные сказки про очередь и фриз-левел?

Откуда появятся очереди в минуту, по сравнению с торговлей каждого советника отдельно?
Наоборот, из-за отсутствия постоянного ожидания ответа все будет работать быстрее, а приказы по одному инструменту можно будет вообще группировать (например, если один советник хочет открыть 0.1 бай, а второй - 0.2 бай, можно одной операцией открыть 0.3).

В крайнем случае, можно распараллелить исполнение приказов: по разным инструментам (один советник - один инструмент), или просто на несколько советников, как я сделал в трейд-бустере.

Фриз - не сказки, а проза жизни, по мимо фриза есть такая штука как "нет цены". Я просто говорю так, потому что более года торгую большим пакетом советников.
 
Andrey Khatimlianskii:

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

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

Вы мне помогли - спасибо!

Спасибо за пожелание удачи - вам так же - удачи!

Но я надеюсь продолжить наш интересный диспут ;)

 
Andrey Khatimlianskii:

В крайнем случае, можно распараллелить исполнение приказов: по разным инструментам (один советник - один инструмент), или просто на несколько советников, как я сделал в трейд-бустере.

Такое решение конечно может и поможет быстрей открывать ордера, но хотелось бы без него...
 
-Aleks-:
Вообще то советник с АТС потеряет информацию о своих виртуальных ордерах - в этом риск. Будет видно, что не открыто - допустим, но вот "как исправить" будет не ясно, так как некому будет исправлять - советник с АТС не будет знать о данной ситуации.

А как стратегия может исправить неоткрытую позицию?

Исправлять будет менеджер.

 
-Aleks-:
Фриз - не сказки, а проза жизни, по мимо фриза есть такая штука как "нет цены". Я просто говорю так, потому что более года торгую большим пакетом советников.

Ответьте на конкретный вопрос:

 Откуда появятся очереди в минуту, по сравнению с торговлей каждого советника отдельно?

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

Почему? Вы же не запихиваете все стратегии в одного советника?

Вот и сделайте "исполнителей", привязанных к одному инструменту - будет и проще в реализации, а сразу распараллеливание получите.

 
Andrey Khatimlianskii:

А как стратегия может исправить неоткрытую позицию?

Исправлять будет менеджер.

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


 Откуда появятся очереди в минуту, по сравнению с торговлей каждого советника отдельно?

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

 
Andrey Khatimlianskii:

Почему? Вы же не запихиваете все стратегии в одного советника?

Вот и сделайте "исполнителей", привязанных к одному инструменту - будет и проще в реализации, а сразу распараллеливание получите.

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