MQL5クラウドネットワークのリソースコスト計算式に関する公開討論会 - ページ 4

[Andrew Petras]

Renat:

私たちは、次のようなユーザーカテゴリーに注目しています。

1. 計算を早くしたい方
2. 溜め込んでおいて、後でさっと使えるようにしたい人
3. 自分の（あるいは利用可能な）資源を単純に売ってお金に換え、それを引き出そうという人たち（取引外のユーザー）
   

そして、1年後には、スケジュール機能を使って未使用時間のリソースを販売する第三のユーザー層が優勢になる予感がします。

4.1が必要になるまで3と2の人 - そして1として彼らははるかに少ない使用頻度（自分自身のためにMQL5をマスターするトレーダー）です。

は、もちろん声を出すのは難しい。

TIME    - затраченное время на расчет задачи(пакета задач) в миллисекундах

は、計算上必ず存在しなければならない。

例：24時間汲み取り中だから、時間単位でタダで集金しませんか？

質問：「遅い」（例：遅延（ping）による）は、何らかの形でカットされるのでしょうか？

一方、多くのユーザーは、そもそも計算の大半を占める開発者用サーバーの容量を持っていません。

そのコアの売り手には何が残るのだろうか。

正直なところ、何を基準にすればよいのか、適切な数字が見当たりません。

一方では、少なくともクラウドのコストを知り、MetaQuotesのために企業の収益性から出発しなければならない（可能な限り低い価格設定）。仮に、私が売り手・買い手として、1コアあたり1ドル/日で満足するとします。開発者は10セントで満足するのでしょうか？

ユーザー側では、パソコンのコストから進んで...。まあ、どうでしょう。このスレッドでも、500円や2000円が引き合いに出されています。かなり広い範囲に広がっていますね。

やはり、買い手がいくらで買うのか、その買い手が何人いるのか、というところから始めないといけないのでしょう。

多分一般的にエキスパートアドバイザーの平均価格を取る（複雑さに応じて）、需要に取り組んでプログラマは、推定することができます？ とし、係数を調整します。オプションで、クラウドの総負荷量について。

[削除済み]

radioamator:

PR100台の1時間分のコストをチャートで提示し、MQL5のホームページで公開することを提案します。CPU時間の買い手と売り手は、ウェブサイトを通じて、100PR単位で1時間の売買の入札を 行います。ある期間、例えば過去120日間（ほぼ4分の1）の入札をすべて蓄積し、PRice120の均衡価格を算出する。この均衡価格は、PRの時間100単位の価格となる。 売り手の入札価格がPRice120の価格より低ければ、彼の処理時間は売られ、高ければ売られることはない。バイヤーの場合は、その逆です。

入札を積み上げる期間は、いくつかの選択肢の中から買い手と売り手が個別に選択する。30日、60日など。その価格のトリガー時の均衡価格からの乖離も、買い手と売り手がそれぞれ個別に選択する。

複雑すぎると私は思います。価格は、統計や追加情報に基づいて一元的に設定されるべきである。一般的な統計は開発者しか見ていない、カードを握っているのは彼らなのだ。

そして、定期的に（例えば、四半期に一度）価格を調整することは、需要と供給に基づいて行うことができます。あなたは1セントの価格を設定しますが、クラウドで動作するようにしたいが、はるかに必要以上になる - 彼らの能力を提供する意欲を高めるために価格を上げる必要があるとします。

価格が高すぎると、買い手が（プライベートネットワークなどに）離れてしまうので、価格を下げざるを得なくなるのです。

問題は、どの価格を基準にするかということだ。

[Renat Fatkhullin]

Mischek:
TeamWoxを購入された法人のお客様がいらっしゃいますね。おそらく、あなたの会社の誰かが彼らと関係を持っているのでしょう。アイドル状態のコンピューターパワーの80〜90％のリサイクル／ロードを増やすアイデア」を提示してみたらどうだろう。彼らはすでにあなたの会社に対して信頼を持っており、価格の問題もすぐに判断できる--それは公正で最適なものに近いかもしれない。

もうひとつのアイデアは、さまざまな分散コンピューティング・プロジェクト（SETI@homeやBOINCプラットフォーム上の同様のもの）に何十年も（ほとんど常に無料で）参加してきた熱狂的なコミュニティを巻き込もうとするものです。

資源にお金を払うインセンティブは十分にあるのです。

[削除済み]

Renat:

MetaQuotes-Demoサーバー上でいくつかの合成ツールを動かし、売り手の数、買い手の数、価格を監視することができます。価格の計算・調整式は公開され、すべてが透明化されます。

基準価格を明示的に変更したり、計算式を調整したりする必要がある場合は、公開討論で対応します。

良いアイデアですね。そうなるとCPU時間の取引を認めざるを得なくなり、証券会社各社は嫉妬のあまり死んでしまうでしょう...。:)

レナート

もうひとつのアイデアは、何十年にもわたってさまざまな分散コンピューティング・プロジェクト（SETI@homeや BOINCプラットフォーム上の同様のもの）に（ほとんど常に無料で）参加してきた熱狂的なコミュニティを巻き込もうとすることです。

チャートで火星人を捕まえることができるのだろうか？:)

[Renat Fatkhullin]

Silent:

質問：（レイテンシー（ping）などによる）「遅い」ものは、何らかの方法でカットされるのでしょうか、それとも優先順位／性能で入ってくるのでしょうか？

それらをクラウドサーバー上で識別し、それに応じて「性能と時間」を調整する。主にチート対策です。

一方、多くのユーザーは、そもそも計算の大半を占める開発者用サーバーの容量を持っていません。

そのコアの売り手には何が残るのだろうか。

私たちは資源を売るつもりはなく、世界中に巨大な流通網を構築することを目標としています。

もちろん、少なくとも初期段階では、一部のリソースは無償で配布する予定です。

一方では、少なくともクラウドのコストを知り、MetaQuotesのエンタープライズ採算（可能な限りの最小限の価格設定）からスタートすべきです。仮に、私が売り手・買い手として、1コアあたり1ドル/日で満足するとしましょう。開発者は10セントで満足するのでしょうか？

私たちはあくまで分散型ネットワークのオペレーターであり、目指すのは何万、何十万という計算エージェントのクラウド化です。

地理的に分散したクラウドサーバーのリストを見てください。負荷が高まればもっと増えるでしょう。

やはり、お客さんがいくら払ってくれるのか、お客さんが何人いるのかを考えるべきかもしれません。

1 Unit Price = Base Price * Func( Sellers, Buyers, Time)の単純な変形版。

その結果、需給状況に応じて1時間ごとに自動的に価格が調整されることになります。

[Andrew Petras]

そして、すでにあるクラウドサービスの基本的な「病院平均」のコストを参考にすることができます。

[Renat Fatkhullin]

Silent:
そして、すでにあるクラウドサービスの基本的な「病院平均」コストをベースにすることもできます。

はい、それも考えていました。しかし、そこでは、ディスク、メモリ、CPUを含むコンピュータ全体と、残りのセキュリティとバックアップのインフラが価格に含まれています。

[Andrew Petras]

Renat:

分かりやすい説明ありがとうございます、より理解できました。

[Andrew Petras]

Renat:
はい、それも考えていました。しかし、そこでは、ディスク、メモリ、CPUを含むコンピュータ全体と、残りのセキュリティやバックアップのインフラが料金に含まれているのです。

本来は、ユーザーのパソコンのコストから来るものと同じですが...。

[Roman Chernyaev]

Renat:

わずかな金額のために誰も指一本動かそうとしない（しかも入札はすべて手作業）ので、あまりにも複雑な仕組みになっている。ほぼ自動で動作することが求められます。

トレードという意味ではないんですけどね。CPU時間の買い手は、100PR単位でN時間分を自分で買いたいと考えています。彼は何らかの方法で、私イワン・イワノフがN時間分買いたいのでMセント払いますとサーバーに伝えなければなりません。バイヤーは、その価格は、いくつかの価格、ベース、120日間の平衡または何か他のものに比べて高いか等しい場合、購入する私の個人的なキャビネットに順序を置くと、買い手はプロセッサの時間を購入する。ポイントは、サイトを通じて出されるプロセッサタイムの購入／売却のオファーは、サーバーへの購入／売却の命令であると同時に、価格を決定するための統計データでもあるということです。価格表はあくまで参考です。