РЕКОРДная Разница между временем последенго тика по ВСЕМ символам Минус только, что полученный новый тик по символу 494013 милесекундa.
CR 018:51:47.334 ProverkaAktyalnostiTikov (ALRS,H1) Получен НОВЫЙ тик по символу SNGR-3.19 time_msc= 2019.03.1818:41:47.988
HN 018:51:47.335 ProverkaAktyalnostiTikov (ALRS,H1) ХОТЯ до этого был получeн тик ARMD time_msc 2019.03.1818:50:02.001
18:51:47.335 ProverkaAktyalnostiTikov (ALRS,H1) Локальное время получения нового тика по символу. 2019.03.1818:51:47.33418:51:47.335 ProverkaAktyalnostiTikov (ALRS,H1) Предпоследние Локальное время попытки получить новый тик по символу 2019.03.1818:41:47.204
有带注释的源代码。
觉得懒得看了吗?还是有什么是我不明白的?
我做到了。我得到了这个想法,但没有代码。我不明白你为什么要建议我。
你需要将流动性最强的工具添加到市场观察中。
然后,将这些乐器分层添加。
而且,当OnBookEvent()触发时,复制1个tick(最后)会有一个时间,并立即采取本地时间并进行比较。
你的方法如何更好?
我已经看了一下。我得到了这个想法,但没有代码。我不明白你为什么要建议我。
为什么你的方法更好?
因为它是正确的!
我犯了一个错误,不是本地时间,而是服务器时间。
1.蜱虫以数据包的形式进入终端。
2.每一个后续的数据包都可能包含没有在前一个数据包中 "堆叠 "的刻度线,但与前一个数据包的时间相同。
3.OnBookEvent()在 任何一个tick(价格、成交量的变化)到来时 被触发,即每个tick。(你触发了一个定时器--已经很糟糕了)。
4.你使用的是当地的计算机时间,这根本不需要!
这里实际上是你需要交易的一切(检查交易时段的时间)。
由以下人员添加
如果你需要毫秒级的精度,那么这个
添加
但所有这些都不会得到预期的结果(交易时间的界限),因为
一个交易时段 可能没有刻度,而时间并没有停止。
假设有人删除了他们的挂单,股票代码已经改变。
有一个信号,但有一个 "旧 "的相关性(时间不是当前时间)。
终端不广播确切的服务器时间。
你不了解我。让我们从头开始。
1) 在你的程序中,你调用TimeCurrent() 并获得Market Watch中一个选定符号的最后报价的到达时间。
让它成为18:00:00。
2) 通过下一个命令,你可以得到最后一个SBER tick的时间。
让它成为17:58:00
3)一点时间过去了,你再次要求SBER提供最后一次勾选的时间。
让它成为17:59:00
请注意这个问题:你认为在18:00:00通过TimeCurrent()可以不知道时间为17:59:00的刻度吗?
你不了解我。让我们从头开始。
1) 在你的程序中,你调用TimeCurrent() 并获得Market Watch中一个选定符号的最后报价的到达时间。
让它成为18:00:00。
2) 通过下一个命令,你可以通过SBER得到最后一次打钩的时间。
让它成为17:58:00
3)一点时间过去了,你再次要求SBER提供最后一次勾选的时间。
让它成为17:59:00
注意问题:你认为在18:00:00时通过TimeCurrent()不知道时间为17:59:00的勾选是否正常?
在我引用的代码中,你可以考虑到所有刻度(没有问题)。
最后一段代码没有使用TineCurrent(),而是使用了TimeTradeServer()--这个时候只需要
以一天的精度检查蜱虫,仅此而已!
让我们从头开始。
总的来说,你想做什么,想知道什么?
你为什么开始将滴答时间与当地时间进行比较?
最初的目的是什么?
现在我将向你展示这个问题在实践中的情况。我已经 完全重新设计了专家顾问。我让它有可能在OnTimer和OnBookEvent中捕捉新的ticks。
市场观察中共有45个符号。他们中的大多数都不是液体。
下面是在OnBookEvent中抓取新ticks的结果。
例如,在TimeCurrent的 18:50 捕捉到一个新的tick,符号SNGR-3.19 的时间为18:41。
然后是对本地计算机时间的测量,在的时刻。
1) 获得一个新的刻度线,即在最后一次调用CopyTick(或SymbolInfo,取决于设置)的时刻。
2)最后一次通话的时刻。
所以在这种情况下,问题的发生是因为get new函数在10分钟内没有被调用....。这是因为SNGR-3.19 的OnBookEvent事件在10分钟内没有产生。
也许终端把它放在事件队列中,但它不知为何从这个队列中消失了。 OnTimer没有这样的错误。是的,可能会有20秒的延迟。
你的初衷是什么?
为什么要用当地时间 来比较开球时间?
你的初衷是什么?
为什么需要将滴答时间与当地时间进行比较?
我想知道,从服务器上发生嘀嗒声到它到达终端的最大延迟。而且我想知道如何尽量减少这段时间。
这些知识可以用于编写我自己的测试器。你甚至可以要求开发商将延迟时间延长。
TimeCurrent() - 符号最后一次勾选的时间将小于延迟时间,所以可以使用。在第一个版本中使用当地时间 并不是一个好主意。
我想知道从服务器上发生嘀嗒声到它到达终端之间的最大延迟。以及如何尽量减少这个时间。
这些知识可以在我编写自己的测试器时使用。也许我还能用更长的延迟时间来迷惑开发者。
我明白了。继续说...没有我。
而对于论坛的其他成员来说
注意问题:你认为时间为17:59:00的TimeCurrent()在18:00:00不知不觉中打勾是正常的吗?
我认为这个问题是没有意义的。我们希望打钩序列至少要满足以下条件。
1.它必须是连续的,即每一个后续的勾股时间>=前一个勾股的时间。
2.实际情况。也就是说,最后到达的时间尽可能地接近当前时刻。
看来,问题出在第二点上。
第2点的论据如下:我希望从服务器上生成tick到我收到它的时间(滞后)最小,这样我就可以比别人更快地处理它并做出交易决定。但是!如果所有投标人的滞后都是一样的--那么就没有问题了(据我理解)。即经纪人的服务器有问题,但每个人的地位是平等的。如果有人在17:59:01得到了关于蜱虫的信息,而我甚至在18:00都没有得到它--这就是大问题。
而问题就在这里。问题是什么(是否有问题)?在经纪人的服务器上,它在很长一段时间内不给滴答(给每个人),或者在MT5中,它在很长一段时间内不接收。