Мы запускаем облачный сервис MQL5 Cloud Network! - страница 66

 
Renat:

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

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

Можно уточняющий вопрос: в 527 это делалось по другому?

Я наблюдаю за PR несколько недель. И те машины (не одна), которые раньше достаточно стабильно (т.к. PR и раньше периодически менялся) показывали 76-78, после обновления на билд 540 так же стабильно показывают 30-31 (характер основной загрузки не поменялся).

Так что изменения налицо, и в теорию динамического пересчёта как-то не укладываются.

 

 
Ashes:

Можно уточняющий вопрос: в 527 это делалось по другому?

Я наблюдаю за PR несколько недель. И те машины (не одна), которые раньше достаточно стабильно (т.к. PR и раньше периодически менялся) показывали 76-78, после обновления на билд 540 так же стабильно показывают 30-31 (характер основной загрузки не поменялся).

Так что изменения налицо, и в теорию динамического пересчёта как-то не укладываются.

Я проверил статистику около 300 агентов на процессоре Pentium Dual-Core E5400 и у них средние показатели PR от 30 до 55.

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

 
Ashes:

Можно уточняющий вопрос: в 527 это делалось по другому?

Я наблюдаю за PR несколько недель. И те машины (не одна), которые раньше достаточно стабильно (т.к. PR и раньше периодически менялся) показывали 76-78, после обновления на билд 540 так же стабильно показывают 30-31 (характер основной загрузки не поменялся).

Так что изменения налицо, и в теорию динамического пересчёта как-то не укладываются.

 

Я об этом говорю почти с самого начала появления 540 билда. Даже специально провел ряд экспериментов, доказываюших существование проблемы. Игнорирование и отговорки со стороны разработчиков не понятны.
 
flexsun:
Я об этом говорю почти с самого начала появления 540 билда. Даже специально провел ряд экспериментов, доказываюших существование проблемы. Игнорирование и отговорки со стороны разработчиков не понятны.

Игнора в таком деле нельзя допускать -  проведем проверку.

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

 
flexsun:
Я об этом говорю почти с самого начала появления 540 билда. Даже специально провел ряд экспериментов, доказываюших существование проблемы. Игнорирование и отговорки со стороны разработчиков не понятны.
Можно вопрос? Сколько указано агентов и сколько реально потоков? Поставил по-честному 8 потоков - 8 агентов. PR стабилен 110-120. Как только решил еще добавить 8 агентов (общее число 16) сразу, что естественно, PR стал на активных ядрах в два раза меньше - 60. Убрал агентов - работа стабильна. Если поставить агентов больше колличества логических ядер, число которых рекомендует сам метатестер, то в пик нагрузки, когда все агенты задействованы, процессор, естественно, выполняет эти скажем например 16 задач присланых для указанных 16 агентов в два раза медленне. Логических ядер то всего 8. Так же бывает, когда у меня параллельно работает что-нибудь и забирает процентов 30 процессорного времени. Заканчивается работа приложения - выхожу, смотрю тестер, а у ядер, которые активничали в это время PR упал. Это все естественно, пришло 8 задач, 3 потока были заняты другим приложением, и эти задачи выполнялись на оставшихся 5 потоках чуть дольше, чем если бы в момент получения задач компьютер вообще ничего не делал. PR только тогда будет максимальным и верным, когда число агентов равно числу  логических ядер (потоков) и на компьютере не выполняется другая работа.
 

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

1- снизится нагрузка на серверы хранящие истории

2- намного увеличится скорость закачки

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

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

 
WChas:
Можно вопрос? Сколько указано агентов и сколько реально потоков? Поставил по-честному 8 потоков - 8 агентов. PR стабилен 110-120.

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


 
ilovebtc:

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

С учетом того, что закачка полной сжатой истории одного символа занимает около 12 Мб за 10 лет, то не имеет смысла качать малый объем данных распределенно.

Кроме того, на передний план выходит требование 100% синхронизации истории с той, что есть на компьютере заказчика вычислений.

 
Renat:

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

 

У меня тоже есть отдельные экземпляры, для которых ничего не изменилось при переходе с 527 на 540.

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

При этом количество агентов на машинах не менялось. 

 
Renat:

С учетом того, что закачка полной сжатой истории одного символа занимает около 12 Мб за 10 лет, то не имеет смысла качать малый объем данных распределенно.

Кроме того, на передний план выходит требование 100% синхронизации истории с той, что есть на компьютере заказчика вычислений.

Все понятно, я просто думал что история занимает немеряных размеров