15

単純すぎるように見える「残り X 分」ダイアログをからかっていますが、どうすれば改善できますか?

事実上、入力は現在までのダウンロード速度のセットであり、これを使用して完了時間を推定する必要があります。おそらく、Y% 信頼区間を使用して「残り 20 ~ 25 分」などの確実性を示します。

これを行うコードは小さなライブラリに入れられ、プロジェクト全体で使用される可能性がありますが、それは本当に難しいのでしょうか? どのようにしますか?以前のダウンロード速度にどの程度の重みを付けますか?

それとも、すでにいくつかのオープン ソース コードが公開されていますか?

編集:要約:

  1. より良いアルゴリズム/フィルターなどにより、推定完了時間を改善します。
  2. 単一の時間 (「1h45-2h30 分」) の代わりに間隔を指定するか、精度を制限します (「約 2 時間」)。
  3. 進捗がいつ停滞したかを示します。ただし、進捗が一貫して停滞し、その後継続する場合は、対処できるはずです。おそらく「約2時間、現在失速中」
4

5 に答える 5

12

より一般的には、転送速度を瞬時に測定する方法を探していると思います。これは通常、短い期間の平均によって得られます。

問題は、一般に、反応するために、周期が通常非常に小さいことであり、これがヨーヨー効果につながります。

非常に単純なスキームを提案します。それをモデル化しましょう。

曲線速度 (y) と時間 (x) を考えてみてください。

  1. Instant Speed は、現在の x (x0) に対して y を読み取るだけです。

  2. 平均速度は、Integral(f(x), x in [x0-T,x0]) / T

  3. 私が提案するスキームは、フィルターを適用して、過去の瞬間を考慮しながら、最後の瞬間により多くの重みを与えることです。

g(x,x0,T) = 2 * (x - x0) + 2T表面 T の単純な三角形として簡単に実装できます。

これで、 を計算できますIntegral(f(x)*g(x,x0,T), x in [x0-T,x0]) / T。両方の関数が常に正であるため、これは機能するはずです。

もちろんg、与えられた間隔で常に正であり、間隔での積分が T である限り、異なる を使用できます (そのため、それ自体の平均は正確に 1 になります)。

この方法の利点は、即時のイベントにより多くの重みを与えるため、より長い時間間隔を考慮した場合でも、かなり反応的であり続けることができることです (平均がより正確になり、しゃっくりの影響を受けにくくなります)。

また、めったに見たことはありませんが、より正確な見積もりを提供すると思われるのは、平均の計算に使用された時間を推定残り時間に関連付けることです。

  • 5ko ファイルをダウンロードすると、瞬時に読み込まれます。見積もりは必要ありません。
  • 15 Mo のファイルをダウンロードすると、およそ 2 分かかるので、5 秒ごとに見積もりをお願いします。
  • 1.5 Go ファイルをダウンロードすると、約 200 分 (同じ速度で) かかります。

そのため、ダウンロードに時間がかかるほど、応答性を低くする必要があり、より平均化することができます。一般に、ウィンドウは合計時間の 2% をカバーできると思います (おそらく、最初のいくつかの見積もりを除いて、人々は即時のフィードバックを歓迎するからです)。また、一度に全体の % で進行状況を示すだけで十分です。タスクが長い場合は、とにかく待つ準備ができていました.

于 2009-12-10T18:51:31.923 に答える
8

ここで状態推定手法を使えば良い結果が得られるのだろうか?カルマンフィルターのようなもの?

基本的に、現在のモデルを見て未来を予測し、時間ステップごとにモデルを変更して、現実世界への変更を反映します。この種の手法は、ラップトップのバッテリーの残り時間を推定するために使用されていると思いますが、これは使用方法やバッテリーの使用年数などによっても異なります。

アルゴリズムの詳細な説明については、http://en.wikipedia.org/wiki/Kalman_filterを参照してください。

フィルターは分散測定値も提供します。これは、推定値の信頼度を示すために使用できます (ただし、他の回答で述べたように、これをエンド ユーザーに表示するのは最善の方法ではない可能性があります)。

これが実際にダウンロード(またはファイルコピー)の見積もりにどこかで使用されているかどうかは誰にもわかりませんか?

于 2009-12-10T16:14:25.033 に答える
4

必要以上の情報を提供してユーザーを混乱させないでください。信頼区間について考えています。スキップしてください。

インターネットのダウンロード時間は大きく変動します。電子レンジはWiFiに干渉します。使用状況は、時間帯、曜日、休日、新しいエキサイティングなゲームのリリースによって異なります。現在、サーバーの負荷が高くなっている可能性があります。ラップトップをカフェに持ち込むと、結果は自宅とは異なります。そのため、ダウンロード速度の将来を予測するために過去のデータに頼ることはおそらくできません。

残り時間を正確に見積もることができない場合は、そのような見積もりを提供してユーザーに嘘をつかないでください。

ダウンロードする必要があるデータの量がわかっている場合は、% 完了した進行状況を提供できます

まったくわからない場合は、「ハートビート」を提供します。これは、残り時間がわからなくても、物事が機能していることをユーザーに示す動く UI の一部です。

于 2009-12-10T15:58:26.483 に答える
2

推定時間自体の改善:直感的には、ネット接続の速度は一時的な平均速度の周りの一連のランダムな値であると推測します-物事は1つの速度で動き、その後突然遅くなるか速くなります。

したがって、1つのオプションは、前の速度のセットに指数関数で重みを付けて、最新の値が最も強い重みを取得するようにすることです。そうすれば、以前の平均速度がさらに過去に移動すると、現在の平均への影響が減少します。

ただし、速度がランダムに変動する場合は、変動が大きすぎないように、指数関数の上部を平坦化する(たとえば、ガウスフィルターを使用する)ことをお勧めします。

つまり、標準偏差(おそらく最後のN分間に制限される)を測定し、それを使用して入力に適用されるガウスフィルターを生成し、標準偏差を使用して引用精度を制限することを考えています。

ただし、標準偏差の計算を最後のN分間にどのように制限しますか?どれくらいの期間使用するかをどうやって知るのですか?

あるいは、安定した速度に到達したかどうかを検出するためのパターン認識の可能性があります。

于 2009-12-14T14:48:39.263 に答える
0

私はこれを自分でオンとオフを検討しました。答えは、現在の (そして将来の) 転送速度を計算するときに保守的になることから始まり、より安定した見積もりを得るために、より長い期間の平均化が含まれます。おそらく、表示される時間をローパスフィルタリングして、2分から2日の間でジャンプしないようにします.

信頼区間は役に立たないと思います。ほとんどの人はそれを解釈することができず、推測であるより多くのものを表示するだけです.

于 2009-12-10T15:59:49.007 に答える