IS 0 13:32:55.239 Trades '11391209': accepted exchange buy 1.00 AFKS at market
DM 0 13:33:07.896 Trades '11391209': deal #265475900 buy 1.00 AFKS at 9.095 done (based on order #284425784)
OD 0 13:33:07.898 Trades '11391209': order #284425784 buy 1.00 / 1.00 AFKS at 9.095 done in 12757.608 ms
你确定你读了整个问题吗？
...在两次调用GetMicrosecondsCount之间...
好吧，这就是我要说的。 第一个调用发生在同步之前，第二个发生在同步之后。 差别将是相同的：实际的微秒 数+同步校正。
好吧，这就是我所说的。 第一个调用是在同步之前，第二个调用是在同步之后。 差别是实际的微秒数+同步校正。
现在告诉我，两次调用GetMicrofsecondsCount之间的时间修正概率是多少？
如果你真的在测量微秒，概率接近于0。
而你测量微秒的时间间隔为秒或更多？为什么？真空中的Spherocon？
你错了，我在这里 特别引用了使用WinApi的代码。 运行它，在这个过程中改变时钟，然后看看结果。
如果你的论点是基于猜测，那么如何与你进行对话就不太清楚了。 而且你甚至认为没有必要熟悉话题讨论的过程。
现在告诉我，两次调用GetMicrofsecondsCount之间的时间修正概率是多少？
如果你真的在测量微秒，那么概率几乎为0。
而你用秒或更多的时间来衡量微秒？为什么？真空中的Spherocon？
我已经告诉过你，这个概率取决于同步期。 它越短，我们就越经常得到一个转变，即概率越高。 而且还取决于相邻测量之间的距离。它越长，我们就越经常打偏。 所以，概率是根据这两个参数来计算的，而不仅仅是用手指在天上算。
还有，为什么你说16毫秒以下的东西，例如，16毫秒以下的东西只能用这个函数测量。而即使是16-30毫秒也必须用这个函数来测量，否则误差会太大。
如果你认为这些都是小事，可以忽略不计，那么这纯粹是你的个人意见。 早些时候，我们在这里谈到了标准的系统函数QueryPerformanceCounter，它可以正常工作，没有任何偏移。 它的发明一定是有原因的。 顺便说一下，Renat在这里 声明它是有原因的。
这就是我们计算微秒的方法。
但事实上并非如此，而是关于QueryPerformanceCounter。
你才是对你提出的问题一无所知的人。
QueryPerformanceCounter中没有时间变化。 你是什么意思？ 你运行了我给你的链接的那个代码吗？
在检查了MQL5代码执行机后，发现我们在GetMicrosecondCount 中有一个混合计量方案。
这段代码的出现是因为试图减少时间测量调用的系统开销。其中一个开发者做得太过火了。
我们个人和Slava都确信，一个纯粹的QueryPerformanceCounter正在发挥作用。而且有这样一个密码。但我们错了，因为有一个混合模式的存在。
现在，纯粹的QueryPerformanceFrequency + QueryPerformanceCounter将发挥作用。
一句话：是的，我们把GetMicrosecondCount函数的实现和对其行为的保护都搞砸了。
斯拉瓦和我对此表示歉意!提醒大家注意明确或隐含地 使用 "应该 "短语。使用 "元引号应该 "而不是"请考虑"，现在是不可接受的。
请考虑这样的假设：更多的时候，字里行间的阅读与对话者所写的内容毫无关系。
实际的错误报告与论坛的协助和扑向MQ是不相容的事情。很难想象一个不断转变为憎恨者，又不断转变的人。
IS 0 13:32:55.239 Trades '11391209': accepted exchange buy 1.00 AFKS at market DM 0 13:33:07.896 Trades '11391209': deal #265475900 buy 1.00 AFKS at 9.095 done (based on order #284425784) OD 0 13:33:07.898 Trades '11391209': order #284425784 buy 1.00 / 1.00 AFKS at 9.095 done in 12757.608 ms朋友们，你们能告诉我该向谁请教吗--我想了解如何在不同交易所的同一产品的价格差异上做文章--我是这个行业的新手，我想了解一下。如果有任何建议，我将不胜感激--也许我应该写在另一个主题里？
我有机会接触到几个外国交易所，但不明白这一切是如何运作的