[Советник] Forex Setka Trader Mod и [EA]-Setka📌

2 часа назад, Старик сказал:

Если вы торгуете несколькими копиями пота на одной паре, то в каждой копии бота должен быть отличающийся магик!!  Безоговорочно!

Всё верно разные мэджики на каждой копии бота.

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

4 минуты назад, Виталий2701 сказал:

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

Держите, просто помню сам искал, через поиск файлов на форуме не нашел. Сейчас даже и не вспомню как нарыл (может по пути попался при изучении форума, пусть будет тут) 

(EA) - Setka v1.43-R295-SR10.ex454 скач.

14 минут назад, Виталий2701 сказал:

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

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

Только что, Zmanovskiy сказал:

Держите, просто помню сам искал, через поиск файлов на форуме не нашел.

Вот я тоже изнасиловал поисковик и толку ноль!)) Кланяюсь! Спасибо! Можно продолжить чтиво со спокойной душой! Скачано!!))

Только что, Zmanovskiy сказал:

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

Ну это может значить одно, что кривизна моих рук мне еще не известна до конца!))) Еще раз спасибо.

42 минуты назад, Виталий2701 сказал:

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

Чистка "буфера", опасаюсь не поможет. Все проще  и прозаичнее. 295-я не официальная версия, потому в топике не публиковалась, и есть только у меня на г-диске (адрес в подписи). Никакой "магии".

Это была первая, робкая попытка "разгона" опта. Более, она ничем от 285-й не отличается.

2 часа назад, Rigal сказал:

Я видел довольно пожилые версии кода сетки, там использовалось TICKVALUE из терминала, в том числе в тесте.

Пожалуйста, скажите мне, что эту механику переписали?

Вынужден Вас разочаровать. Других средств к получению TickValue и TickSize, кроме данных из терма, не используется.

А как бы Вы предложили эту "механику" переписать? Вместо ДЦ рассчитывать цену тика и его объем в валюте депозита? Это как?

Без подколок! Если иметь внятный алгоритм, это можно внедрить! Однако надо учитывать, что это задача по-тиковая! Сложный расчет"убъет", и без того, не выдающуюся производительность бота. Поэтому следует, сначала, оценить степень влияния изменения этих данных на результаты расчетов.

И еще момент! Цена и объем тика указаны в спецификации инструмента. Т.е. являются константой.

2 часа назад, Rigal сказал:

В 13.08.2020 в 18:12, Старик сказал:

Спойлер

Но вы правы: при TakeProffitType=0, если все ордера на месте и того же лота - первый раз вычисленный ТР с ходом времени меняться не должен.

Потому что при TakeProffitType=0 это простейшая арифметика: умножаются цены открытия ордеров на их лоты - и сумма делится на сумму лотов ордеров сетки.

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

И если вдруг, пусть в ролловер и на демке (как в вашем случае), вдруг начало меняться расстояние до ТР, то терем врет боту либо про лоты, либо про цены открытия ордеров.

Где-то до 1260 билда включительно чудес в торгах практически не было, а вот примернно с 1260+ на покореженном короной/трампом рынке отдельные чудеса наблюдаются.

 

простите меня, гуру сеток, но нет.

Спойлер

Давайте разберемся, как мы считаем тейк профит 

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

А как мы считаем безубыток?

Правильно, из цены закрытия вычитаем дистанцию, полученную делением текущего профита на стоимость пункта в валюте депозита, ака TICKVALUE

Ну и мелочи в виде TICKSIZE

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

Но, в мт5, например, ввели разное значение TICKVALUE для loss & profit.

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

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

Только приблизительно

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

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

 

да, всё верно: в приведенной цитате я написал неверно - без цены пипса БУ и ТР не высчитаешь.   

А цена пипса в половине пар плавает и, вместе с мт4, может внезапно и сильно огорчать...

Я сейчас свожу воедино все проблемки в торгах последнего времени - надо обобщить и хорошо подумать...

По памяти львиная доля сбоев в торгах в мт4 с билда более 1260.

Спасибо, что обратил внимание и на эту некорректность в посте, и на узкое место именно в этом вопросе! 

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

-----

55 минут назад, Виталий2701 сказал:

58 минут назад, Zmanovskiy сказал:

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

Ну это может значить одно, что кривизна моих рук мне еще не известна до конца!))) Еще раз спасибо.

Всё тот же роковой первый пост:

Индикаторные моды ADX-IMP и RSI-CCI-AS бота (EA) - Setka от @capteen 2019 года, мт4 и мт5

Последняя ссылка содержит в т.ч. архив со всеми безиндикаторными и индикаторными модами для мт4 и мт5 релиза 295.

295 релиз был промежуточным/рабочим и в топике не публиковался.

8 часов назад, capteen сказал:

Вынужден Вас разочаровать. Других средств к получению TickValue и TickSize, кроме данных из терма, не используется.

 

А как бы Вы предложили эту "механику" переписать? Вместо ДЦ рассчитывать цену тика и его объем в валюте депозита? Это как?

 

Без подколок! Если иметь внятный алгоритм, это можно внедрить! Однако надо учитывать, что это задача по-тиковая! Сложный расчет"убъет", и без того, не выдающуюся производительность бота. Поэтому следует, сначала, оценить степень влияния изменения этих данных на результаты расчетов.

 

И еще момент! Цена и объем тика указаны в спецификации инструмента. Т.е. являются константой.

@capteen, да, я долгое время считал, что TickSize - это константа

Забирал ее на старте советника и использовал.

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

https://www.mql5.com/en/forum/133792/page3#comment_3405179

Фрагмент:

     * https://www.mql5.com/en/forum/127584 CB: MODE_TICKSIZE will usually return the
     * same value as MODE_POINT (or Point for the current symbol), however, an
     * example of where to use MODE_TICKSIZE would be as part of a ratio with
     * MODE_TICKVALUE when performing money management calculations which need
     * to take account of the pair and the account currency. The reason I use
     * this ratio is that although TV and TS may constantly be returned as
     * something like 7.00 and 0.0001 respectively, I've seen this
     * (intermittently) change to 14.00 and 0.0002 respectively (just example

Я перевел все на опрос терминала в реальном времени, на тике, на котором выполняется расчет.

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

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

Которой у тестера, конечно, нет для кроссов, но он использует какую-то величину. И при этом это не та же величина, которую он возвращает советнику по запросу TickValue

Мы это обсудили вот тут: https://www.mql5.com/en/forum/336141

В итоге я стал в тестере использовать аппроксимацию: зная дистанцию, которую прошла каждая сделка в прибыль, или в убыток и начисленный на эту дистанцию профит, можно вычислить TickValue, которое тестер использовал в вычислениях: TesterTickValue = DirectionSign * OrderProfit / (ClosePrice - OrderOpenPrice) / OrderLots * tickSize

Здесь  DirectionSign = 1 для BUY  и -1 для SELL

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

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

Полученные уровни безубытка можно слить, как Volume Weighted Average Price: (Lots1 * Breakeven1 + Lots2 * Breakeven2 + ...) / (Lots1 + Lots2 +. ...)

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

Зачем все это?

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

8 часов назад, Старик сказал:

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

Я описал подход. У меня довольно глубоко в библиотеках эти вычисления и с кандачка не выкусишь - очень много контекста потянется.

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

А, и чтобы добить этот вопрос:

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

Это никак не влияет на расположение точки безубытка по торговому профиту - там все понятно, безубыток в цене открытия.

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

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

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

Будет он двигаться.

Советник - демо

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

На каждом тике:

- считает безубыток в покупку двумя способами - штатный TickValue и рассчитанный по профиту сделок и усредненный,  рисует две голубые линии, логгирует расхождение двух значений, если включена опция Noisy

- то же самое для продаж, коралловым цветом

- то же самое для полной совокупности, жирная желтая линия

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

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

Это ожидаемо - TickValue остается константой.

А вот если запустить его на, скажем, USDJPY (где, казалось бы, у метатрейдера по-прежнему всегда есть котировка, чтобы превратить йену в доллар, ибо это та же котировка) и посмотреть, что происходит, можно заметить, что уровень, вычисляемый по тестерному TickValue непрерывно плавает - и плавает тем сильнее, чем дальше от него уходит цена.

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

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

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

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

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

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

Поэкспериментируйте с этим перцем на разных парах в визуале.

При наведении на уровень, подсвечивается его имя.

Если имя заканчивается на заглавную Т - это уровень, построенный по значению TickValue из тестера.

Если буквы Т нет - уровень вычислен по отношению профита к дистанции.

И сразу оговорюсь: советника я накидал исключительно для демонстрации феномена.

Он крайне неоптимален, пересчитывает. все сделки по много раз на тике и ни в коей мере не отражает мое отношение к разработке.

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

BreakEvenCompare.mq428 скач.

В 02.02.2020 в 11:28, kvv75 сказал:

в Robo я вообще на разобрался и не увижу где момент закрытия

Кстати да, в вашем терминале от Робо в Истории счета (между ТР и ценой закрытия) нет столбца "Время" с временем закрытия - и я не понял как его можно on|off.

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

Возможно, что вам стоит скопировать метаквотовский терем (скачать не из ДЦ) и уже его подключить к Робо.

Но, коллега @kvv75 , я вам пишу по другой причине - у вас были удивительные сбои в 2-х ДЦ с обновления терема в январе 2020 (до этого ничего подобного не было).

Мы некую дополнительную защиту на ваш случай добавили и еще подумаем/проверим достаточно ли её или еще надо думать и писать код - и пока не опубликовали.

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

@Rigal огромное спасибо и за осветление очень непростого и "подставочного" вопроса - и за потраченное время на написание этих наполненных смыслом постов!

Точно будет и что потестить, и над чем много раз подумать...

Проблема, несомненно, в этом есть - и в мт4 она намного сложней, чем в мт5 с намного большим объемом более широкой и точной информации.

Блин, между мт4 и мт5 намного больше отличий, чем хотелось бы...

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

Насколько помню, у части пар цена пипса фиксированная, а у остальных (за время жизни сетки) плавает в пределах доли% или 1%-2% . И 1% уже немало.

Т.е. в TickValue max меняется 2-3 знак после запятой и очень небыстро, сетки на откатах намного чаще закрываются быстрей значимых изменений TickValue. 

А новая сетка новые цены пипса - ну и ладно...

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

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

В итоге, при расстоянии до ТР от 5 до 100+ пипсов 4-х знак, в абсолютном большинстве случаев среднее изменение цены пипса меняет уровень ТР на долю пипса.

Исходно у нас ТР пересчитывался и модифицировался после открытия/выставления каждого ордера и по таймеру (дефолтно каждые 90 секунд, можно чаще).

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

В итоге не в точности, но мы частично реализовали идею, что если пересчитанный уровень ТР отличается менее чем на 1 пипс 4-х знак, то нехер модифицировать.

Это в сотни раз уменьшило частоту модификаций ТР сеток - что, в т.ч., несколько повысило скорость тестирования бота без существенного изменения результатов тестов.

К сожалению, как показывает изложенная вами информация, это всё же скорее торгово-технологический компромисс.   

И всё же скорее придется выписать дополнительные анализ и контроль - для избежания проблем наподобие рассматривавшегося инцидента у коллеги @kitaro_777.

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

Вот, кстати, хороший пример на USDJPY

БОльшая часть позиции - продажи. Открыта одна позиция в покупку.

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

Безубыток, пересчитанный из TickValue,  которое вернул терминал, находится под  сделкой, на заметном расстоянии.

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

Но изменения, которые требуются в расчетах - это вычисление tickValue из OrderProfit и дистанции между ценой закрытия и ценой открытия.

Разные для покупок и продаж

         if(MathAbs(OrderProfit()) < 0.01 || MathAbs(cp(_tick, OrderType()) - OrderOpenPrice()) < DBL_EPSILON) {
            if(tickValue[OrderType()] < DBL_EPSILON)
               tickValue[OrderType()] = SymbolInfoDouble(Symbol(), SYMBOL_TRADE_TICK_VALUE);
         } else {
            tickValue[OrderType()] = sgn(OrderType()) * OrderProfit() / (cp(_tick, OrderType()) - OrderOpenPrice()) / OrderLots() * tickSize;
         }

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

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

В целом, вычисление несложное. 

Вопрос, конечно, как и куда оно там вписывается.

10 минут назад, Старик сказал:

@Rigal огромное спасибо и за осветление очень непростого и "подставочного" вопроса - и за потраченное время на написание этих наполненных смыслом постов!

Точно будет и что потестить, и над чем много раз подумать...

Проблема, несомненно, в этом есть - и в мт4 она намного сложней, чем в мт5 с намного большим объемом более широкой и точной информации.

Блин, между мт4 и мт5 намного больше отличий, чем хотелось бы...

Спойлер

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

Насколько помню, у части пар цена пипса фиксированная, а у остальных (за время жизни сетки) плавает в пределах доли% или 1%-2% .

то есть максимум меняется 2-3 знак после запятой и очень небыстро, сетки на откатах намного чаще закрываются быстрей существенных изменений цены пипса. 

А новая сетка новые цены пипса - ну и ладно...

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

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

В итоге, при расстоянии до ТР от 5 до 100 пипсов 4-х знак максимум, в абсолютном большинстве случаев среднее изменение цены пипса меняет уровень ТР на долю пипса.

 

Исходно у нас ТР пересчитывался и модифицировался после открытия/выставления каждого ордера и по таймеру (дефолтно каждые 90 секунд, можно чаще).

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

В итоге не в точности, но мы частично реализовали идею, что если пересчитанный уровень ТР отличается менее чем на 1 пипс 4-х знак, то нехер модифицировать.

Это в сотни раз уменьшило частоту модификаций ТР сеток - что, в т.ч., несколько повысило скорость тестирования бота без существенного изменения результатов тестов.

 

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

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

 

 

@Старик, я и сам хотел систематизировать и проверить этот момент давно, вот и случай.

В реальных торгах этого и не будет происходить: на реале величина TickValue в точности соответствует арифметике расчета прибыли/убытка.

Все выкладки относятся к тестам - но было бы здорово, если бы мы могли тестировать то же самое, что советник делает на реале

В 02.02.2020 в 12:29, kvv75 сказал:

В 02.02.2020 в 12:19, gudvin сказал:

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

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

После чего поменял VPS и таких проблем  больше не было. 

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

По возможности поясните пожалуйста применительно к моему случаю!

@kvv75 Вы зимой сохранили и выкладывали в топик логи бота и терминала того проблемного дня. 

Вы сейчас можете их скачать в своем зимнем посте и сейчас изучить заново.  

Сверьте в 2-х логах этого проблемного зимнего дня в предшествующих проблемным и в собственно проблемных/сбойных торгах:

- для нескольких ордеров разных пар в разное время суток

- время выдачи приказа бота на открытие ордера - по логу бота,

- время принятия теремом/сервером приказа бота открыть ордер - по логу терминала,

- время открытия ордера на сервере - по логу терминала

- время принятия ботом отчета сервера/терема об открытии ордера - по логу бота.

В норме вся эта цепочка действий происходит за 1-2 секунды max - и бот, отдав приказ открыть ордер, переходит в режим ожидания и max через секунду, реже 2-3 секунды получает подтверждение "ордер открыт" в виде его №.

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

Я не берусь утверждать, что всё 100% именно так.

Но связь с сервером ДЦ с микропаузами из-за проблем с собственно связью или ограничениями/тормозами в работе "выделенного" вам "процессора" VPS теоретически могут создавать напряги именно в том направлении, в котором это у вас и произошло.

Тоже надо учитывать, что хоть мт4 старый и неплохой продукт, но он не идеален и мы точно не знаем насколько он безупречен в отработке форс-мажоров типа инет/VPS чудит.

4 часа назад, Старик сказал:

В норме вся эта цепочка действий происходит за 1-2 секунды max - и бот, отдав приказ открыть ордер, переходит в режим ожидания и max через секунду, реже 2-3 секунды получает подтверждение "ордер открыт" в виде его №.

 

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

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

4 часа назад, Старик сказал:

Тоже надо учитывать, что хоть мт4 старый и неплохой продукт, но он не идеален и мы точно не знаем насколько он безупречен в отработке форс-мажоров типа инет/VPS чудит.

Нормально там все. В терме есть механизмы работы на медленных каналах и медленных машинах. Проблема где-то в другом.  _{Очень сильно подозреваю, что в целенаправленной борьбе с нашим ботом.}

В 23.08.2020 в 01:01, capteen сказал:

В 22.08.2020 в 20:12, Старик сказал:

В норме вся эта цепочка действий происходит за 1-2 секунды max - и бот, отдав приказ открыть ордер, переходит в режим ожидания и max через секунду, реже 2-3 секунды получает подтверждение "ордер открыт" в виде его №.

 

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

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

я пишу о его же реальных торгах в этот же день несколькими минутами раньше и позже сбоя/перепута_пар в отчетах сервера ботам об открытии ордеров

0    16:52:06.421    '3167134': order sell market 0.10 CADJPY sl: 0.000 tp: 0.000
0    16:52:08.421    '3167134': order was opened : #134875942 sell 0.10 CADJPY at 82.018 sl: 0.000 tp: 0.000

0    16:58:16.093    '3167134': order buy market 0.30 CADJPY sl: 0.000 tp: 0.000
0    16:58:18.203    '3167134': order was opened : #134881851 buy 0.30 CADJPY at 81.949 sl: 0.000 tp: 0.000

...

0    17:15:15.173    '3167134': order buy market 0.10 EURCAD sl: 0.00000 tp: 0.00000
0    17:15:16.220    '3167134': order was opened : #134895610 buy 0.10 EURCAD at 1.46563 sl: 0.00000 tp: 0.00000

0    17:17:30.877    '3167134': order buy market 0.10 EURUSD sl: 0.00000 tp: 0.00000
0    17:17:32.533    '3167134': order was opened : #134896348 buy 0.10 EURUSD at 1.10781 sl: 0.00000 tp: 0.00000

Длительность исполнение приказа на открытие ордера 1-2 секунды - в том числе на EURUSD и EURCAD, втянутыми в скандал в сбое/перепуте в 17:04 31 января.

Наиболее вероятно, что всё же возможной причиной сбоя оказались перелогины к счету - вследствие которых и приказы бота на открытие ордера могли теряться, и перепуты отчетов сервера могли быть спровоцированы...   А вот кто виновен в перелогинах, VPS или ДЦ - это уже другой вопрос.

Безусловно, бот достаточно долго может ждать подтверждение открытия ордера.   Но в реале в тот же день, до и после, открытие ордеров это max 1-2 секунды.

И, кстати, это долго.  Достаточно отморожено...  

Вопрос может глупый, но тут пару дней был диалог уважаемых Rigal и Старик, и если честно я ну совсем мало что понял из этого диалога.  Подскажите, мне нужно в это вникать и разбираться для торгов и тестов (без доп. литературы не вникнуть), или это тонкие настройки для разработчиков и программистов?

1 час назад, Devil13 сказал:

Вопрос может глупый, но тут пару дней был диалог уважаемых Rigal и Старик, и если честно я ну совсем мало что понял из этого диалога.  Подскажите, мне нужно в это вникать и разбираться для торгов и тестов (без доп. литературы не вникнуть), или это тонкие настройки для разработчиков и программистов?

Это тонкие настройки, в первую очередь для скальперов. ИМХО отклонение в 0.1%-1.0% от запланированной прибыли не является сверхпринципальным для нашего стиля торгов.

3 часа назад, Старик сказал:

Наиболее вероятно, что всё же возможной причиной сбоя оказались перелогины к счету - вследствие которых и приказы бота на открытие ордера могли теряться, и перепуты отчетов сервера могли быть спровоцированы...   А вот кто виновен в перелогинах, VPS или ДЦ - это уже другой вопрос.

Перелогины явно отображаются в логе бота!

Если верить документации Метаквот, то при испольнении приказа торговый поток в терминале останавливается. Т.е. пока не будет получен ответ от сервера о завершении исполнения одного приказа, другой приказ не будет отправлен. А вот как отвечает сервер - тайна покрытая мраком. Можно подозревать, что там другой, явно многопоточный, механизм. И вот в этом-то механизме и проявляются сбои при перегрузах или в ролловер. Частичную защиту (проверку) мы уже ввели. Что еще можно сделать? Например добавить задержку 1-10 тиков для отправки приказа, но это приведет к проскальзываниям...

7 часов назад, Devil13 сказал:

Вопрос может глупый, но тут пару дней был диалог уважаемых Rigal и Старик, и если честно я ну совсем мало что понял из этого диалога.  Подскажите, мне нужно в это вникать и разбираться для торгов и тестов (без доп. литературы не вникнуть), или это тонкие настройки для разработчиков и программистов?

Не, правильный вопрос, совершенно ни разу не глупый.

Коллега Rigal обратил внимание на неточность в моём ответе о вычислении ТР сетки + потом обсудили его подход к этому вопросу и альтернативные решения для тестера мт4.

Цитата

В реальных торгах этого и не будет происходить: на реале величина TickValue в точности соответствует арифметике расчета прибыли/убытка.

Все выкладки относятся к тестам - но было бы здорово, если бы мы могли тестировать то же самое, что советник делает на реале 

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

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

-----

5 часов назад, capteen сказал:

9 часов назад, Старик сказал:

Наиболее вероятно, что всё же возможной причиной сбоя оказались перелогины к счету - вследствие которых и приказы бота на открытие ордера могли теряться, и перепуты отчетов сервера могли быть спровоцированы...   А вот кто виновен в перелогинах, VPS или ДЦ - это уже другой вопрос.

Перелогины явно отображаются в логе бота!

 

Если верить документации Метаквот, то при испольнении приказа торговый поток в терминале останавливается. Т.е. пока не будет получен ответ от сервера о завершении исполнения одного приказа, другой приказ не будет отправлен. А вот как отвечает сервер - тайна покрытая мраком. Можно подозревать, что там другой, явно многопоточный, механизм. И вот в этом-то механизме и проявляются сбои при перегрузах или в ролловер. Частичную защиту (проверку) мы уже ввели. Что еще можно сделать? Например добавить задержку 1-10 тиков для отправки приказа, но это приведет к проскальзываниям...

Ну, мы зацепились за единственный и уникальный сбой 31 января 2020 (посты 1 и 2 февраля), когда сервер после переподключения к счету ошибочно сообщал ботам об открытии ордеров других ботов. 

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

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

Да, проверку этой редчайшей ситуации мы добавили. 

Я только не помню добавили ли мы паузу секунд 30 для дать серверу всё же открыть ордер и потом боту ордер увидеть - и не пытаться без необходимости открыть ордер повторно.

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

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

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

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

Экономить на использовании хорошего VPS даже в торгах сетками идея вряд ли хорошая...

Ради интереса посмотрел спрэды на центовике в Робо через 15 минут после открытия торгов...

AUDNZD 20 pips, EURCAD 16 pips, EURGBP 12 pips, GBPCAD 13 pips, EURJPY 16+ pips - а в самые первые минуты открытия торгов/суток и того больше.

Pips это пипсы 4-х знак - в пунктах 5-ти знак умножьте на 10 (200, 160, 120, 130, 160 пунктов соответственно).

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

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

Первый час недели лучше не торговать.

Ну и вообще хорошо посмотрите подходят ли сеты с шагом или Тр=5 пипсов счету со спрэдом 15-20 пипсов на открытии торгов.