Бета-версия платформы MetaTrader 5 build 1625: Пользовательские финансовые инструменты - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Так как задач в клауде мало, то всегда получается, что приоритено отдаются задачи самым быстрым агентам. Тем самым слабые агенты получают очень мало заданий.
Это логично, так как вся сеть оптимизируется на максимальную скорость вычислений и минимальный пинг.
Не совсем понятно вот это:
Мы проверим, есть ли какие-либо задержки в обновлении этих данных в интерфейсе сайта. На сайте могут быть задержки. В самой облачной сети на управляющих серверах конечно же все показатели производительности обновляются очень часто много раз в сутки, так как это важно для распределения задач.
Так как задач в клауде мало, то всегда получается, что приоритено отдаются задачи самым быстрым агентам. Тем самым слабые агенты получают очень мало заданий.
Это логично, так как вся сеть оптимизируется на максимальную скорость вычислений и минимальный пинг.
Как на счет вот этого примера:
Я уже проверил. За 10 секундый тест, запущен 50000 раз, Cloud работал примерно 2 минути (в 12 раз больше чем тест). Подключились примерно 3000 агента, а без работа стояли примерно 10 000 агента, в том числе и 80% от моих агентов. Если Cloud работал на польной мощности, подключая все 13-15 000 агента, то тогда он выполнил бы задание может быть в 3-4 раза быстрее.
?
Как на счет вот этого примера:
?
А вы не учитываете, что каждая задача на агент должна быть некоторого минимального размера, чтобы накладные расходы по передаче пакетов не привысили затрат на сами расчеты? Если в пределе поделить все задачи так, что для каждой - свой пакет, то логика оптимизации должна переехать из облака в терминал.
А вы не учитываете, что каждая задача на агент должна быть некоторого минимального размера, чтобы накладные расходы по передаче пакетов не привысили затрат на сами расчеты? Если в пределе поделить все задачи так, что для каждой - свой пакет, то логика оптимизации должна переехать из облака в терминал.
Учитываю. Наверное, в этом и было дело.
Надо посложнее задание запустить в сеть для проверки.
Или просто услышать ответ Рената, который знает внутреннее устройство облака.
Как на счет вот этого примера:
Не имеет экономического смысла раздавать быстрые задания по 1 штуке на каждого агента, так как накладные расходы будут кратно выше полезной нагрузки.
Поэтому задачи (особенно быстрые) раздаются пакетами на одного агента. Запуская мгновенные задачи, нельзя оценить охвата и нагрузки сети.
Кроме ускорения расчетов, у нас есть и другое ограничение - разумная экономия ресурсов нашей облачной инфраструктуры. Просто задумайтесь о стоимости репликации рыночного окружения (чарты, история, и тд) на 10 000 агентов, чтобы выполнить задачку на 10 мс полезной нагрузки, размазав ее по всем.
Будут ли опубликованы статьи, обьясняющие на доступном уровне суть и цель применения пользовательских фин.инструментов? Я например никак не могу усвоить до конца в чем их "фишка".
Не имеет экономического смысла раздавать быстрые задания по 1 штуке на каждого агента, так как накладные расходы будут кратно выше полезной нагрузки.
Поэтому задачи (особенно быстрые) раздаются пакетами на одного агента. Запуская мгновенные задачи, нельзя оценить охвата и нагрузки сети.
Кроме ускорения расчетов, у нас есть и другое ограничение - разумная экономия ресурсов нашей облачной инфраструктуры. Просто задумайтесь о стоимости репликации рыночного окружения (чарты, история, и тд) на 10 000 агентов, чтобы выполнить задачку на 10 мс полезной нагрузки, размазав ее по всем.
Каждая заинтересованная страна имеет своя разумная логика, свои решения и свои действия, но вы сами видите конечний резултат - ЗАДАЧ В КЛАУДЕ МАЛО !!!
Каковы причины для этого?
Один пример:
Хлеб высшего качество продается по цене 10 USD, но никто не хочет покупать его.
В то же время есть производители хлеба, которые готови продават нормальный хлеб по 3-5 USD. Есть и много покупатели, которые согласны закупить этого хлеба. Вообще есть огромный потенциал торговли более дешевого хлеба в болыших обемах, но магазин не хочет заниматся с этом. Конечный резултат:
1. У покупателей нет хлеба
2. У производителей нет заказов на производство
3. У магазина нет продажи
Можно ли разрешить проблема? Конечно можно. Надо попросить рынок и он сразу ответить примерно следующее:
Дайте право продавцов и покупателей сами договориться о цене и качество хлеба. Это позволит достичь максимального объема продаж и комисии для организатора торгов. Работа будеть для всех, СПРАВЕДЛИВОСТ ВОЗТОРЖЕСТВУЕТ и все будуть удовлетворены.
Мое предложение следущее:
1. Каждый поставчик агентов имеет право сам определят цена каждого своего агента.
2. В сервере поддерживаются 3 списка агентов, отсортивованые по PR, по цена и по ефективности (PR/цена)
3. Потребители клауда имеют выбор с каким списком агентов работать - быстрые, дешевые или ефективные.
4. Каждый агент присуствует во все 3 списка, но имеет разная позиция в резултат разной сортировки.
5. Задачи раздаются по очереди выбраного от клиента список.
6. Все работает в реалном времени. Например поставчик уменшаеть цена агента до нуля и если в облака есть задач, сразу получает одна из них. Или во время теста клиент меняет список и сразу с ним начинают работат агенты от другом списке.
И последнее:
Логика Connect/Disconnect агентов меняется. Все агенты находится в Connected State, что бы облак имел быстрый доступ к ним. Disconnected будут только агенты, которые имеют какой то проблем (нет RAM, нет дисковое пространство и т.д.)
На MetaQuotes-Demo доступна бета-версия 1625 с массой улучшений в скорости работы.
Попробуйте эту версию, пожалуйста.
Релиз будет 14 июля 2017.