Дмитрий (Все сообщения пользователя)

Да. Один брокер ВТБ. И на одном сервере даже. Просто 2 UID. Версии одинаковые.

не 2 компа, а 2 квика

Да сравнивал - память и ЦП одинаково, а сеть у одного просто останавливается, то есть перестают приходить пакеты TCP, но само соединение не разрывается. В этот самый момент опять проверял активность данного терминала - никаких дополнительных трудоёмких задач он не выполняет.

Поставил 3 сек. Но опять произошло зависание приёма данных на 60 секунд. При этом в файл curr_data.log ничего не записалось. Так что дело не в нём. Так же дело и не в интервале обновления, потому что в другом терминале стоит 1 сек и существенно больший объём данных принимается и он не зависал. Может это брокер блокирует?

Версия 7,27,2,1.

Да, через некоторое время данные начинают поступать. Оба терминала на одном компьютере с одними настройками. Проблема почему то появляется только на одном терминале. Параметр приема данных - исходя из настроек открытых пользователем таблиц и интервал обновления данных  - 1 сек.
Файл curr_data.log как то связан с таблицей текущих параметров насколько я знаю? Эти таблицы есть в обоих терминалах. Почему тогда на первом терминале он пустой и что означает повторяющийся набор символов на другом терминале как будто какой то цикл идёт?

Принято за секунду - становится равным 0. И соответственно задержка данных при обмене с сервером становится равной времени отсутствия приема данных - 50, 100 или больше секунд

Здравствуйте! Периодически зависает приём данных в квике, то есть скорость входящих данных становится равной 0. Причём на другом терминале на этом же сервере приём продолжается. При этом на терминале где не поступают данные в это время происходит запись в лог файл curr_data.log следующего содержания: (скриншот). При этом на другом терминале этот файл пустой. с чем это связано?

Через карман транзакций при выставлении новой заявки по опционам параметр Проверять диапазон цен учитывается. Здесь нет необходимости что то менять. Хорошо, не надо ничего менять:)

Здравствуйте! Параметр при выставлении новой заявки: «Проверять диапазон цен» – если флажок включен, то цена заявки проверяется торговой системой на соответствие диапазону допустимых значений цены по этому инструменту. Доступно только для класса «Опционы FORTS».
Почему данный параметр не соблюдается при транзакции "перестановка заявок на рынке FORTS" для класса «Опционы FORTS»? То есть при выставлении новой заявки вне лимита выходит сообщение: Ошибка создания заявки. [GW][32] "Цена сделки вне лимита". А при перестановке уже существующей заявки на цену вне лимита транзакция проходит успешно - это серьёзный риск.

Karina Dmitrieva, да, конечно

Здравствуйте! Почему до сих пор нет функции удаления сразу всех активных заявок?

На фондовой секции!

Доброе здравствуйте! Сколько не бился, а не смог понять сколько же свободных денег под открытие новых позиций осталось?

Так как тип клиента С, то дисконтов нигде нет. Но я знаю, что под позиции должно быть около 21000. А вот как эту сумму извлечь из данной таблицы?

Здравствуйте! При открытии нового графика инструмента иногда происходит зависание программы  - открывается пустой график и висит некоторое время (видимо для получения данных графика) и при этом если в этот момент отправлялась какая либо транзакция, то она тоже зависает, то есть не получает ответа от сервера и размораживается только вместе с открытием графика. Можно ли это как то исправить - чтобы не зависала транзакция. Версия QUIK 7,27,2,1

Здравствуйте! Не отображается комментарий в таблице заявок при подаче поручения через команду QPILE.
Формат команды
T = SET_VALUE(T, "COMMENT", "123")
Как правильно написать?

На самом деле поток info.exe!GET_INFO_PARAM+0x2380b0 это импорт транзакций из файла и чем больше строчек в файлах три и тро, тем больше ресурсов потребляется. Странно, что никто не знает об этом.

Да, но этот скрипт в отдельном же потоке идёт.

Версия 7,27,2,1. В принципе уже убрал, скопировав папку с "нормальным" квиком. А сам этот поток на самом деле легко удаляется в процесс эксплорер без последствий для работы программы, отсюда вывод, что не нужен он.

Здравствуйте! У меня запущено 2 квика.  В каждом из них работает поток info.exe!GET_INFO_PARAM+0x2a2938 Внезапно во втором квике появился дополнительный поток
info.exe!GET_INFO_PARAM+0x2380b0, который отъедает много ресурсов. С чем он связан и как его убрать? Информация на скриншоте.

Andrey Bezrukov, кстати не может ли это быть из за конфликта транзакций? например в тоже самое время как в скрипте qpile идёт обращение к функции SEND_TRANSACTION происходит отправка транзакции через другой источник, в частности посредством импорта транзакций из файла tri

квик 7,27,2,1. На других рынках не известно, есть ли такая ошибка, так как работа идёт только на срочном рынке. Логирование сделаю - может действительно что то проявится

Если отправить команду R = SEND_TRANSACTION(15, T) без задания массива T, то возникает другая ошибка
Произошла ошибка при расчете скрипта ... Unknown identifier T [ R = SEND_TRANSACTION(15, T) ]
А если отправить команду с пустым массивом T
T = CREATE_MAP()
R = SEND_TRANSACTION(15, T)
то скрипт работает нормально, а только в ответе на транзакцию приходит RESULT=0;RESULT_EX=5;DESCRIPTION=Не указан идентификатор транзакции;

В моём случае массив T заполняется стандартно:

 T = CREATE_MAP()
 TRANS_ID = TRANS_ID+1
 T = SET_VALUE(T, "TRANS_ID", TRANS_ID)
 T = SET_VALUE(T, "ACTION", "MOVE_ORDERS")
 T = SET_VALUE(T, "MODE", "2")
 T = SET_VALUE(T, "CLASSCODE", CLASSCODE)
 T = SET_VALUE(T, "SECCODE", TICKER)
 T = SET_VALUE(T, "FIRST_ORDER_NUMBER", KEY)
 T = SET_VALUE(T, "FIRST_ORDER_NEW_QUANTITY", QUAN)
 T = SET_VALUE(T, "FIRST_ORDER_NEW_PRICE", PR)

здесь никаких ошибок быть не может.

Сама ошибка расчета скрипта Error while function call SEND_TRANSACTION возникает спонтанно и не каждый день после отправки до её возникновения тысяч транзакций с точно такими же параметрами. При работе до этого на 6 версии квика с 14 значными номерами заявок такой ошибки никогда не возникало. Есть мнение, что данная ошибка как то связана с 19 значными номерами заявок

Здравствуйте! Что означает данная ошибка?
Произошла ошибка при расчете скрипта ...  Error while function call SEND_TRANSACTION [ R = SEND_TRANSACTION(15, T) ]

ну значит сам квик не виноват, я и не настаиваю

Понять моя ли это проблема. Тест на другом сервере брокера показал, что распределение происходит нормально. Вот для сравнения график частот


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

В том то и дело, что я его отключил (или попытался отключить по инструкции майкрософт). На квике 6 работало нормально, то есть график частот имеет один пик, а на квике 7 появляется ещё один пик в районе 220 мс.

И ещё одна особенность - все значения времени ответа сгруппированы по одним и тем же уровням с интервалом 15 мс, как видно на следующем графике (разными цветами опять показаны 2 пика распределения, а между ними пустая область)

Похоже квик 7 по какому то своему протоколу отправляет транзакции в отличие от TCP

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

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

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

order_num некорректный будет, так как там 19 знаков и они округляются. Берите номер заявки из result_msg (сообщение о транзакции), вырезав его из текста сообщения

Верно, сейчас проверил - выдаёт текстовое значение номера, хотя в 6 версии квика там было число

Подскажите какие файлы можно удалять? Я знаю, что нельзя metastok.dat portfolio.dat scripts.dat А остальные за что отвечают?
@echo off

del acnt.dat /F /Q
del alerts.dat /F /Q
del alltrade.dat /F /Q
del banners.dat /F /Q
del classes.dat /F /Q
del firms.dat /F /Q
del hotkey.dat /F /Q
del limits.dat /F /Q
del locales.dat /F /Q
del metastok.dat /F /Q
del orders.dat /F /Q
del par.dat /F /Q
del portfolio.dat /F /Q
del search.dat /F /Q
del scripts.dat /F /Q
del sec.dat /F /Q
del StratVolat.dat /F /Q
del tmsg.dat /F /Q
del tradermsg.dat /F /Q
del trades.dat /F /Q
del trans.dat /F /Q
del transresult.dat /F /Q

del *.log /F /Q

start info.exe

Подскажите какой из терминалов 7 версии наиболее оптимален в плане исправленных критических ошибок и в плане отсутствия всяких добавлений для красоты, которые отъедают процессор и оперативную память? То есть нужно чтобы и добавлений не было и ошибок

при отправке заявок очередь скорее возникнет у брокера, чем у процессора

может хватит уже этими номерами мучить? Во первых они уже отменены и неизвестно когда будут. А во вторых уже всё разжёвано как их использовать на 7 версии

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

Как я и предполагал. А потом вообще отменят видимо

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

и даже в квик 6

выше в этой теме уже писалось как

до 25 мая всё может случится, может ишак помрёт, а может падишах. Кому только понадобилось работать с 19 ! значными номерами как с числами?? Народ, вы что там считаете 19 значными номерами, прибыль что ли?

 Если бы с ростом версии квика и прибыль росла

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

чудеса! а я всю жизнь номер отправлял. Надо будет протестировать с trans_id. Тогда вообще какие проблемы то? если номер вообще не участвует

как это только по trans_id? разве номер заявки не нужно указывать в транзакции на снятие?

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

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

Попробую в картинках объяснить суть, может так понятнее станет. Речь исключительно о статусе 3, когда приходит дискрипшн с номером заявки.
Вот график вышеприведённых и подробно описанных задержек для 6 версии:



А вот график для 7 версии:



Разница между ними не нулевая, как хотелось бы предположить:



Очевидно что квик 7 вносит какую то свою собственную внутреннюю задержку. Хотелось бы понять с чем она связана и можно ли настройками её убрать.