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

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

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

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

Так как тип клиента С, то дисконтов нигде нет. Но я знаю, что под позиции должно быть около 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 вносит какую то свою собственную внутреннюю задержку. Хотелось бы понять с чем она связана и можно ли настройками её убрать.

вопрос только о версии квика. Не об абсолютной задержке, а относительной. Независимо от брокера и биржи, так как и брокер и биржа одна и в том и другом случае. Между двумя версиями квика 6 и 7 наблюдается разница в периоде между отправкой транзакции и приходом ответа на транзакцию.Применительно например к языку qpile это время между отправкой команды SEND_TRANSACTION и приходом ответа от сервера (MAP SEND_TRANSACTION (DOUBLE wait_timeout_for_replay, MAP trans_params) Отправляет заявку с параметрами, указанными в массиве «trans_params» и ожидает ответа торговой системы в течение «wait_timeout_for_replay» (в секундах, не менее 5).) Вот период этого ожидания я и замеряю. И что мы наблюдаем - в 6 версии этот период допустим 60 мс, а в 7 - 100 мс. Разница таким образом 40 мс. Чем это объясняется? Что сделано нового в квике 7, которое вносит такую задержку?

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

Почему в 7 версии по сравнению с 6 увеличилось время выставления транзакций примерно на 40 мс? Что там сделано?

Andrey Bezrukov, да , точно, это доска опционов обновляется  

а почему на 6 версии не удастся снять, а на 7 удастся?

так если не обращаться к таблице всех сделок откуда процессор то, что то я не улавливаю

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

зачем вам "даблы" для номеров транзакций? эти номера не предназначены для каких либо вычислений

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

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

Прошу подсказать, что означают вот эти периодические ровно в 60 сек всплески использования сети? (Больше в сеть ничего не выходит, браузеры не работают, нет антивирусов и вообще ничего, только терминал QUIK)