MT5 速さにこだわる人へ。 - ページ 12 1...5678910111213141516171819...39 新しいコメント TheXpert 2013.07.02 13:55 #111 shelandr:質問の意味がわからない...EAは全てのティックを処理します。ティックは通常、毎分2〜3であり、価格の動きで、毎分200のようなものに増加する - または毎秒4〜5(私は秒に分では間違って変換したとは思わないでください - 別の関係があります)。分と秒のどちらが間違っているかは分かりませんが、その方が正確です。どうしても処理が遅くなり、おそらくティックの受信をブロックする同期トレード 操作を除いて、CPU負荷を視覚的にコントロールすることができます。 さて、EAもスクリプトもターミナルに入るティックをブロックすることはできないことをお知らせしておきます。でも、何を言ってるんだろう......どうぞ、ダンピングしてください。 Андрей Шелихов 2013.07.02 14:10 #112 TheXpert: EAやスクリプトでは、ターミナルに入ってくるティックをブロックすることはできないことを理解しておいてください。ブロックしているとは言っていません。ただ、物理的にモデムとネットワークカードのポートが、ギガビットでない限り、すべてを通過することはできません。 インターネットのトラフィックも予測不可能です。しかし、同期取引 操作はブロックされる...数学を学ぼう。インジケータは、ブロックするのではなく、流れの中で機能します。しかし、スクリプトやExpert Advisorは遅くなる(MT4のドキュメントにもある)。 sion 2013.07.02 14:18 #113 shelandr:チャンネル帯域を広げれば、最大周波数も上がると思うのですが...全てのテロップを受信する時間は多分ないでしょう...。 トレーディング、自動売買システム、ストラテジーテストに関するフォーラム MT5 速さにこだわる人へ。 シェランダー 2013.07.02 08:24 自分の取引ロボットを使いたい、まだ取引ロボットができない、取引ロボットに戻れない、ただ、自分の取引ロボットを参考にしたくない、取引ロボットのやり方を勉強しなければならない、相場を変えたくない、などです。 同じことを10回聞くより、やったほうがいいんじゃない? Андрей Шелихов 2013.07.02 16:16 #114 papaklass:明確にすること。1.次のティックでエキスパートの開始時刻を記憶する。2.Expert Advisorが1ティック動作したら、現在時刻から 最初に記憶した時刻を引きます。6ms以上の差がある場合は、EAが遅くなるのはチャンネルのせいではなく、EAがチャンネルの速度に対応できていないことを意味します。MT5でそのようなカウンターがあるのですが、0msと表示されています。MT4にはミリ秒はありません。また、ティック間の慣性を測定すると、3000msと表示されることがあります。また、端末の稼働率を測定する必要があるのですが、それもうまくいっています。サーバーとのやり取りは別のタイミングで行われ、パケットの長さにもよりますが、6msは関係ありません。同じ、トレードを成立させ、ポジション、オーダーなどの情報を別パッケージにしたのか、ティックパケットに追加したのかがわからない(最初に開示しているのだが)。今よく見たら、Work=16msの時もありました。市場は落ち着いていますが。間隔は約500msecです。 Андрей Шелихов 2013.07.02 16:26 #115 sion:同じことを10回聞くより、そうしたほうがいいんじゃない? 私もそうしています。それに、聞くのではなくて、答えたり、-伝えるという感じです。 Андрей Шелихов 2013.07.02 16:39 #116 papaklass:同じ方法で簡単にインターネットカララの速度を確認することができます。OrderSend();の前の時間を記憶しておき、オーダーチケットを受け取った後の時間と比較する必要があります。関数 GetTickCount() は、ミリ秒を計測するのに役立ちます。今、よく見てみると、Work=16msの時もありますね。市場は落ち着いていますが。間隔は約500msです。トレードはないものの今度は、取引操作でポジションを決済しようとしたところ、36msと表示されました。そして、今度はアイドルが64msを示した。こんなにも広がるとは、どういうことだろう。 Renat Fatkhullin 2013.07.02 16:49 #117 shelandr:今、もっとよく見てみると、Work = 16msが抜けていることがあります。市場は落ち着いていますが。間隔は約500msです。トレードはないものの今度は、取引操作でポジションを決済しようとしたところ、36msと表示されました。そして、今度はアイドルが64msを示した。そんなバリエーションに、どんな意味があるのだろう。GetTickCountによる 時間計測の精度は、16ms以内です。 つまり、32ms以内のタイミングは信用できないのです。実時間が0~31msの場合、GetTickCountの応答は0または16に丸められることが多くなります。 sion 2013.07.02 16:55 #118 shelandr: 私もそうしています。それに、聞くけど答えるとか、-伝えるとか、そういうことではないんです。 お答えするならば、「最大周波数が上昇する...」というのはどういうことなのか、特にその周波数のチャンネル速度への依存性は...? Андрей Шелихов 2013.07.02 17:02 #119 Renat:GetTickCountの時間計測の精度は16ms以内です。 つまり、32ms以内の測定は信用できない。実時間が0~31msの場合、GetTickCountからの応答は0または16に丸められることがよくあります。 ありがとうございます...私は問題を理解しています。 私のExpert Advisorは、終了=GetTickCount() です。だから、測るものがないんです。だって、なんで0なんだろう......マイクロ秒単位で計測する必要はないんだけど......。 --- 2013.07.02 17:10 #120 shelandr: また、聞くのではなく、答えたり、-伝えるという感じです。何ら問題ないが、回答はこんな感じです。 1...5678910111213141516171819...39 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
質問の意味がわからない...EAは全てのティックを処理します。ティックは通常、毎分2〜3であり、価格の動きで、毎分200のようなものに増加する - または毎秒4〜5(私は秒に分では間違って変換したとは思わないでください - 別の関係があります)。分と秒のどちらが間違っているかは分かりませんが、その方が正確です。どうしても処理が遅くなり、おそらくティックの受信をブロックする同期トレード 操作を除いて、CPU負荷を視覚的にコントロールすることができます。
EAやスクリプトでは、ターミナルに入ってくるティックをブロックすることはできないことを理解しておいてください。
ブロックしているとは言っていません。ただ、物理的にモデムとネットワークカードのポートが、ギガビットでない限り、すべてを通過することはできません。 インターネットのトラフィックも予測不可能です。
しかし、同期取引 操作はブロックされる...数学を学ぼう。
インジケータは、ブロックするのではなく、流れの中で機能します。しかし、スクリプトやExpert Advisorは遅くなる(MT4のドキュメントにもある)。
チャンネル帯域を広げれば、最大周波数も上がると思うのですが...全てのテロップを受信する時間は多分ないでしょう...。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
MT5 速さにこだわる人へ。
シェランダー 2013.07.02 08:24
自分の取引ロボットを使いたい、まだ取引ロボットができない、取引ロボットに戻れない、ただ、自分の取引ロボットを参考にしたくない、取引ロボットのやり方を勉強しなければならない、相場を変えたくない、などです。
明確にすること。
1.次のティックでエキスパートの開始時刻を記憶する。
2.Expert Advisorが1ティック動作したら、現在時刻から 最初に記憶した時刻を引きます。
6ms以上の差がある場合は、EAが遅くなるのはチャンネルのせいではなく、EAがチャンネルの速度に対応できていないことを意味します。
MT5でそのようなカウンターがあるのですが、0msと表示されています。MT4にはミリ秒はありません。また、ティック間の慣性を測定すると、3000msと表示されることがあります。
また、端末の稼働率を測定する必要があるのですが、それもうまくいっています。サーバーとのやり取りは別のタイミングで行われ、パケットの長さにもよりますが、6msは関係ありません。同じ、トレードを成立させ、ポジション、オーダーなどの情報を別パッケージにしたのか、ティックパケットに追加したのかがわからない(最初に開示しているのだが)。
今よく見たら、Work=16msの時もありました。市場は落ち着いていますが。間隔は約500msecです。
同じ方法で簡単にインターネットカララの速度を確認することができます。
OrderSend();の前の時間を記憶しておき、オーダーチケットを受け取った後の時間と比較する必要があります。
関数 GetTickCount() は、ミリ秒を計測するのに役立ちます。
今、よく見てみると、Work=16msの時もありますね。市場は落ち着いていますが。間隔は約500msです。
トレードはないものの
今度は、取引操作でポジションを決済しようとしたところ、36msと表示されました。
そして、今度はアイドルが64msを示した。こんなにも広がるとは、どういうことだろう。
今、もっとよく見てみると、Work = 16msが抜けていることがあります。市場は落ち着いていますが。間隔は約500msです。
トレードはないものの
今度は、取引操作でポジションを決済しようとしたところ、36msと表示されました。
そして、今度はアイドルが64msを示した。そんなバリエーションに、どんな意味があるのだろう。
GetTickCountによる 時間計測の精度は、16ms以内です。
つまり、32ms以内のタイミングは信用できないのです。実時間が0~31msの場合、GetTickCountの応答は0または16に丸められることが多くなります。
私もそうしています。それに、聞くけど答えるとか、-伝えるとか、そういうことではないんです。
GetTickCountの時間計測の精度は16ms以内です。
つまり、32ms以内の測定は信用できない。実時間が0~31msの場合、GetTickCountからの応答は0または16に丸められることがよくあります。
また、聞くのではなく、答えたり、-伝えるという感じです。
何ら問題ない
が、回答はこんな感じです。