gumgum: Ерундень какая-то, процессор грузит анентами и трафик идет, а вып. задач нет. Удалю нафиг.)
Прежде чем получить задачу на выполнение, агент должен закачать историю по тестируемому инструменту. Это происходит только в самый первый раз, задачи отдаются только тем агентам, у которых есть история, чтобы заказчик не ждал и не тратил время зря.
Значит ваши агенты начали закачивать историю. При поступлении следующей задачи агент уже не будет закачивать историю, а сразу приступит к выполнению.
Прежде чем получить задачу на выполнение, агент должен закачать историю по тестируемому инструменту. Это происходит только в самый первый раз, задачи отдаются только тем агентам, у которых есть история, чтобы заказчик не ждал и не тратил время зря.
Значит ваши агенты начали закачивать историю. При поступлении следующей задачи агент уже не будет закачивать историю, а сразу приступит к выполнению.
А процессор около 10 минут грузил это то же историю закачивал?
А процессор около 10 минут грузил это то же историю закачивал?
P.S. трафик там мизер был.
Ранее вы писали другое, агентов ваших нет, трудно что-то сказать
gumgum: Ерундень какая-то, процессор грузит анентами и трафик идет, а вып. задач нет. Удалю нафиг.)
Возможно, вашему агенту попалась задача с ошибкой, в этом случае задача не учитывалась. Мы исправили эту ошибку, будет в следубщем билде. То есть после обновления агентов такие проблемы должны свестись к минимуму.
А процессор около 10 минут грузил это то же историю закачивал?
P.S. трафик там мизер был.
Я подозреваю, что клауд спотыкнулся на зацикленных оптимизируемых/тестируемых кодах советников. Т.е. кто-то запускает оптимизацию с "левым" кодом, этот байткод приходит агенту, он его ставит на выполнение и приехали.
Прежде чем агентам раздавать байткод на выполнение, он проверяется на зацикливание? Думаю что нет, ибо это при различных условиях проверить сложно ( и практически на 100% проверить невозможно ). Это выводит из строя агента. Вероятность выхода из строя всей сети агентов очень высокая ( что вчера и произошло ) ибо против логического вируса Б. Гейтса: "10 goto 10" лекарств насколько я знаю нет ( кроме как терминирование Агента ). Но ресурс то он съел...
Прежде чем агентам раздавать байткод на выполнение, он проверяется на зацикливание? Думаю что нет, ибо это при различных условиях проверить сложно ( и практически на 100% проверить невозможно ). Это выводит из строя агента.
Нет, зацикливание отлавливается по таймауту (и еще как-то, возможно). Точнее скажет stringo.
Rosh: Нет, зацикливание отлавливается по таймауту (и еще как-то, возможно). Точнее скажет stringo.
Таймаут конешно хорошо, но ресурс то он съел и счетчик успешного выполнения задачи участник Cloud не получил + опустил PR агента + вывел из строя часть нодов клауда в рестарт ( что вчера и произошло )...
Как минимум эту задачу на первом этапе надо отшибать на рубеже самого инициатора задачи - т.е. сделать 1 прогон на его машине и только после успешного выполнения хотябы первого, далее отдавать его в клауд...
Rosh: Нет, зацикливание отлавливается по таймауту (и еще как-то, возможно).
В следующем билде будет лимит в 10 минут на выполнение любой из функций OnInit, OnDeinit, OnTick etc. Естественно, потраченное время будет учитываться и оплачиваться. При возврате такой ошибки от облачного агента клиентский терминал сразу же отключает облачную сеть.
Ещё добавлен контроль на исчерпание памяти. Нехватка памяти сразу же ведёт к критической ошибке. Для облачных вычислений введён порог - 16 таких ошибок, при достижении которого клиентский терминал отключает облачную сеть.
Также в облачных агентах добавлен контроль по объёму записи на жёсткий диск. Также после 16 превышений лимита записи облачная сеть отключается.
В следующем билде будет лимит в 10 минут на выполнение любой из функций OnInit, OnDeinit, OnTick etc. Естественно, потраченное время будет учитываться и оплачиваться. При возврате такой ошибки от облачного агента клиентский терминал сразу же отключает облачную сеть.
Ещё добавлен контроль на исчерпание памяти. Нехватка памяти сразу же ведёт к критической ошибке. Для облачных вычислений введён порог - 16 таких ошибок, при достижении которого клиентский терминал отключает облачную сеть.
Также в облачных агентах добавлен контроль по объёму записи на жёсткий диск. Также после 16 превышений лимита записи облачная сеть отключается.
Всё это будет в следующем билде
Ок, спасибо! заодно этим и дисциплинируете кодирование экспертов, которые уходят на расчет в Cloud.
В следующем билде будет лимит в 10 минут на выполнение любой из функций OnInit, OnDeinit, OnTick etc. Естественно, потраченное время будет учитываться и оплачиваться. При возврате такой ошибки от облачного агента клиентский терминал сразу же отключает облачную сеть.
Ещё добавлен контроль на исчерпание памяти. Нехватка памяти сразу же ведёт к критической ошибке. Для облачных вычислений введён порог - 16 таких ошибок, при достижении которого клиентский терминал отключает облачную сеть.
Также в облачных агентах добавлен контроль по объёму записи на жёсткий диск. Также после 16 превышений лимита записи облачная сеть отключается.
Всё это будет в следующем билде
ИМХО это не правильно, тем самым вы обрезаете выполнение как многих не трейдерских задач, так и долгосчитающих советников, загоняя тем самым сеть на оптимизацию машек. Мой опыт подсказывает что даже для того чтоб вписаться в правила чемпа приходится нещадно резать логику. Но на чемпе вы хозояин-барин, а тут почему я за свои деньги должен ограничиваться чтоб вписаться в 10 минут ???
Более правильным было бы перед подключением тестера к Cloud, делать разовый тест на локальных агентах и уже исходя из их PR расчитывать время стопаута.
Если мой тест делает расчёт в течении 2.5 часов то я соглашусь дождаться результатов разовых проходов чтоб подключится к сети, если же тест с ошибкой(зациклен) то результата не будет никогда и сеть не подключится вообще. Если же владелец машины отключил комп не дождавшись пока я досчитаю это его проблемы, нужно выдать эту задачу повторно другой машине.
А ещё имея пробный расчёт можно легко посчитать сколько стоит один проход задачи, и брать с заказчика вперёд, это будет мягко подталкивать заказчиков писать коды так чтоб они успевали исполняться на удалённых машинах до того как они будут отключены.
ЗЫ Если же я не вижу другого пути как только написать долгоиграющий код, то со всей ответственностью беру на себя риск что какое-то количество задач будет оплачено вдвойне тк машины просто отключились и задача была выдана повторно другому агенту.
Ерундень какая-то, процессор грузит анентами и трафик идет, а вып. задач нет. Удалю нафиг.)
Прежде чем получить задачу на выполнение, агент должен закачать историю по тестируемому инструменту. Это происходит только в самый первый раз, задачи отдаются только тем агентам, у которых есть история, чтобы заказчик не ждал и не тратил время зря.
Значит ваши агенты начали закачивать историю. При поступлении следующей задачи агент уже не будет закачивать историю, а сразу приступит к выполнению.
Прежде чем получить задачу на выполнение, агент должен закачать историю по тестируемому инструменту. Это происходит только в самый первый раз, задачи отдаются только тем агентам, у которых есть история, чтобы заказчик не ждал и не тратил время зря.
Значит ваши агенты начали закачивать историю. При поступлении следующей задачи агент уже не будет закачивать историю, а сразу приступит к выполнению.
А процессор около 10 минут грузил это то же историю закачивал?
P.S. трафик там мизер был.
А процессор около 10 минут грузил это то же историю закачивал?
P.S. трафик там мизер был.
Может и больше грузить. Все зависит от проца, нета и объема истории (не забываем что у каждого брокера она своя по идеи).
История как известно грузится в упакованном виде, а на компе разархивируется в рабочее состояние.
Если возможно рекомендую историю агентам подкинуть в ручную либо позаботиться о ее загрузки хотя бы с сервера разработчиков.
А процессор около 10 минут грузил это то же историю закачивал?
P.S. трафик там мизер был.
Ранее вы писали другое, агентов ваших нет, трудно что-то сказать
Ерундень какая-то, процессор грузит анентами и трафик идет, а вып. задач нет. Удалю нафиг.)
А процессор около 10 минут грузил это то же историю закачивал?
P.S. трафик там мизер был.
Я подозреваю, что клауд спотыкнулся на зацикленных оптимизируемых/тестируемых кодах советников. Т.е. кто-то запускает оптимизацию с "левым" кодом, этот байткод приходит агенту, он его ставит на выполнение и приехали.
Прежде чем агентам раздавать байткод на выполнение, он проверяется на зацикливание? Думаю что нет, ибо это при различных условиях проверить сложно ( и практически на 100% проверить невозможно ). Это выводит из строя агента. Вероятность выхода из строя всей сети агентов очень высокая ( что вчера и произошло ) ибо против логического вируса Б. Гейтса: "10 goto 10" лекарств насколько я знаю нет ( кроме как терминирование Агента ). Но ресурс то он съел...
.
Прежде чем агентам раздавать байткод на выполнение, он проверяется на зацикливание? Думаю что нет, ибо это при различных условиях проверить сложно ( и практически на 100% проверить невозможно ). Это выводит из строя агента.
Нет, зацикливание отлавливается по таймауту (и еще как-то, возможно). Точнее скажет stringo.
Таймаут конешно хорошо, но ресурс то он съел и счетчик успешного выполнения задачи участник Cloud не получил + опустил PR агента + вывел из строя часть нодов клауда в рестарт ( что вчера и произошло )...
Как минимум эту задачу на первом этапе надо отшибать на рубеже самого инициатора задачи - т.е. сделать 1 прогон на его машине и только после успешного выполнения хотябы первого, далее отдавать его в клауд...
Нет, зацикливание отлавливается по таймауту (и еще как-то, возможно).
В следующем билде будет лимит в 10 минут на выполнение любой из функций OnInit, OnDeinit, OnTick etc. Естественно, потраченное время будет учитываться и оплачиваться. При возврате такой ошибки от облачного агента клиентский терминал сразу же отключает облачную сеть.
Ещё добавлен контроль на исчерпание памяти. Нехватка памяти сразу же ведёт к критической ошибке. Для облачных вычислений введён порог - 16 таких ошибок, при достижении которого клиентский терминал отключает облачную сеть.
Также в облачных агентах добавлен контроль по объёму записи на жёсткий диск. Также после 16 превышений лимита записи облачная сеть отключается.
Всё это будет в следующем билде
В следующем билде будет лимит в 10 минут на выполнение любой из функций OnInit, OnDeinit, OnTick etc. Естественно, потраченное время будет учитываться и оплачиваться. При возврате такой ошибки от облачного агента клиентский терминал сразу же отключает облачную сеть.
Ещё добавлен контроль на исчерпание памяти. Нехватка памяти сразу же ведёт к критической ошибке. Для облачных вычислений введён порог - 16 таких ошибок, при достижении которого клиентский терминал отключает облачную сеть.
Также в облачных агентах добавлен контроль по объёму записи на жёсткий диск. Также после 16 превышений лимита записи облачная сеть отключается.
Всё это будет в следующем билде
В следующем билде будет лимит в 10 минут на выполнение любой из функций OnInit, OnDeinit, OnTick etc. Естественно, потраченное время будет учитываться и оплачиваться. При возврате такой ошибки от облачного агента клиентский терминал сразу же отключает облачную сеть.
Ещё добавлен контроль на исчерпание памяти. Нехватка памяти сразу же ведёт к критической ошибке. Для облачных вычислений введён порог - 16 таких ошибок, при достижении которого клиентский терминал отключает облачную сеть.
Также в облачных агентах добавлен контроль по объёму записи на жёсткий диск. Также после 16 превышений лимита записи облачная сеть отключается.
Всё это будет в следующем билде
ИМХО это не правильно, тем самым вы обрезаете выполнение как многих не трейдерских задач, так и долгосчитающих советников, загоняя тем самым сеть на оптимизацию машек. Мой опыт подсказывает что даже для того чтоб вписаться в правила чемпа приходится нещадно резать логику. Но на чемпе вы хозояин-барин, а тут почему я за свои деньги должен ограничиваться чтоб вписаться в 10 минут ???
Более правильным было бы перед подключением тестера к Cloud, делать разовый тест на локальных агентах и уже исходя из их PR расчитывать время стопаута.
Если мой тест делает расчёт в течении 2.5 часов то я соглашусь дождаться результатов разовых проходов чтоб подключится к сети, если же тест с ошибкой(зациклен) то результата не будет никогда и сеть не подключится вообще. Если же владелец машины отключил комп не дождавшись пока я досчитаю это его проблемы, нужно выдать эту задачу повторно другой машине.
А ещё имея пробный расчёт можно легко посчитать сколько стоит один проход задачи, и брать с заказчика вперёд, это будет мягко подталкивать заказчиков писать коды так чтоб они успевали исполняться на удалённых машинах до того как они будут отключены.
ЗЫ Если же я не вижу другого пути как только написать долгоиграющий код, то со всей ответственностью беру на себя риск что какое-то количество задач будет оплачено вдвойне тк машины просто отключились и задача была выдана повторно другому агенту.