2009-05-12 6 views
14

Tôi đang tìm cách tốt nhất để tính toán ETA của một hoạt động (IE: tải xuống tệp) bằng cách sử dụng thông tin tiến trình tuyến tính.Cách tốt nhất để tính toán ETA của một hoạt động là gì?

Cho phép nói rằng tôi có phương pháp sau đó được gọi là:

void ReportProgress(double position, double total) 
{ 
    ... 
} 

Tôi có một vài ý tưởng:

  • tính toán tiến độ trong một khoảng thời gian (như 10s cuối cùng) và sử dụng tốc độ đó làm tốc độ trung bình cho hoạt động
  • lưu giữ một tập hợp các tiến trình x cuối cùng đã được báo cáo, tính tốc độ của mỗi lần tăng và sử dụng mức trung bình
+13

Tuy nhiên bạn chọn không làm theo cách tương tự như quá trình copy file microsoft hiển thị tiến trình. –

+1

Khá giống với câu hỏi này: http: // stackoverflow.com/questions/798800/whats-the-best-way-to-calculate-còn-tải-thời gian –

+0

Cảm ơn rất nhiều, tôi không tìm thấy nó trước đây, tôi nên làm gì bây giờ? (Lần đầu tiên tôi hỏi trên stackoverflow :)) – Maghis

Trả lời

7

Tôi thực sự khinh cả những ý tưởng vì họ đã cả cắn tôi trước với tư cách là nhà phát triển.

Điều đầu tiên không tính đến tình huống hoạt động thực sự nhanh hơn, nó nói rằng có 10 phút để đi và tôi quay lại sau 3 và kết thúc. Thứ hai không tính đến hoạt động chậm hơn - Tôi nghĩ rằng Windows Explorer phải sử dụng phương pháp này vì nó luôn có vẻ chiếm 90% thời gian sao chép 90% các tệp, sau đó 90% thời gian khác sao chép 10% cuối cùng của các tập tin :-).

Từ lâu tôi đã tính toán cả hai số liệu đó và tính trung bình chúng. Các khách hàng không quan tâm (họ không thực sự quan tâm đến hai lựa chọn khác, họ chỉ muốn xem một số tiến trình) nhưng điều đó làm tôi cảm thấy tốt hơn và đó thực sự là tất cả những gì tôi quan tâm vào cuối ngày ;-)

+0

Tôi biết, khách hàng hiếm khi nhận thấy, nhưng với tư cách là một nhà phát triển phần mềm, tôi gần như ám ảnh với những thứ như thế này :). Trung bình chúng là một ý tưởng hay. – Maghis

0

Nó sẽ phụ thuộc vào mức độ phù hợp của thời gian vận hành. Nếu nó nhất quán, nó sẽ là hoàn toàn hợp lý để sử dụng thời gian trung bình của các hoạt động trước đó. Nếu không, bạn tốt hơn hết thời gian hoạt động hiện tại và ngoại suy.

Chỉnh sửa: Nếu hoạt động không phù hợp với các lần chạy trước đó và cũng không nhất quán từ đầu đến cuối, thì bạn có vấn đề nan giải. Dự đoán không thể đoán trước luôn vui vẻ :)

Bạn có thể quyết định trước nếu bạn muốn đánh giá thấp hoặc đánh giá quá cao, và thêm yếu tố fudge vào ước tính. Ví dụ: nếu bạn muốn đánh giá quá cao và 10% đầu tiên mất 6 giây, bạn có thể ngoại suy đến 60 giây sau đó nhân với 1,5 để nhận tổng số ước tính là 90 giây. Khi tỷ lệ phần trăm hoàn thành phát triển, giảm yếu tố fudge cho đến khi ở 100% nó trở thành 1.0.

+0

Cho phép xem xét tải xuống tệp, tốc độ thực có thể thay đổi rất nhiều và tùy thuộc vào các biến tôi không thể kiểm soát. ETA có vẻ hợp lý đối với người dùng cuối. (có lẽ tôi nên làm rõ câu hỏi tốt hơn) – Maghis

5

Something như thế này nên làm như lừa:

void ReportProgress(double position, double total) 
{ 
    static TimeType startTime; 

    if (position == 0) 
    { 
     startTime = GetTime(); 
     return; // to avoid a divide-by-zero error 
    } 

    TimeType elapsedTime = GetTime() - startTime; 
    TimeType estimatedRemaining = elapsedTime * total/position; 
    TimeType estimatedEndTime = GetTime() + estimatedRemaining; 

    // Print the results here 
} 

Ước tính được gần với sự thật như sự tiến bộ tiếp cận 100%

+0

Cơ bản nhưng tốt nhất, có thể bạn đang giả định thời gian hoạt động là rất nhất quán. Trong khi tiến triển thời gian ước tính luôn luôn hội tụ chậm hơn vào "thời gian thực còn lại". IE: trong trường hợp tải xuống, một lượt tải xuống khác có thể kết thúc và tốc độ tải xuống của tôi sẽ tăng gấp đôi, vào thời điểm này, thời gian ước tính sẽ mất rất nhiều để có được chính xác. – Maghis

+0

Hoàn toàn đúng, và đó là sự cố với ước tính. Cũng có thể là việc tải xuống khác sẽ bắt đầu, khiến tốc độ tải xuống của bạn bị cắt giảm một nửa. –

+2

Tôi nghĩ rằng tính toán của bạn cho 'EstimatedRemaining' thực sự cho bạn ước tính _total_ thời gian. Bạn có thể muốn 'TimeType estimatedRemaining = (elapsedTime * (total/position)) - elapsedTime'. – tkocmathla

1

Nếu bạn muốn có ETA thay vì 'thanh tiến trình' thì bạn có thể cung cấp nhiều hơn một hình không?

Tính tốc độ tải xuống trung bình trong một khoảng thời gian nhất định (tùy thuộc vào thời gian tải xuống tổng thể có thể kéo dài, nếu bạn đang xem 10+ phút thì cứ sau 5 giây sẽ ổn) và lưu bản ghi của mức trung bình.

Sau đó, bạn có thể cung cấp hai số liệu, một ước tính trên và dưới.

Nếu bạn tin tưởng rằng mức trung bình sẽ là dấu hiệu tốt về tổng thời gian tải xuống, thì bạn có thể hiển thị phần trăm thứ 40 và thứ 60 - nếu thời gian tải xuống trung bình thay đổi rất nhiều, thì lần thứ 10 và thứ 90 để tốt hơn.

Tôi thà thấy một sân chơi bóng chày '21 -30 phút và nó được chính xác hơn được thông báo 29 phút 35,2 giây và nó được dặm ra, và thay đổi dữ dội từ một bản cập nhật tiếp theo.

4

Tôi nghĩ rằng vấn đề này là khá nhiều không thể giải quyết được, nhưng có thể tạo ra một số ước lượng chính xác với nhiều kiến ​​thức hơn về quy trình đang thực hiện. Và trong những trường hợp có những ẩn số lớn, tốt hơn là thông báo cho người dùng những ẩn số đó để họ có thể xem xét chúng.

Để lấy ví dụ đơn giản tải một loạt các tập tin bạn có hai biến được biết đến:

  • Số file
  • Kích thước của các tập tin

Đối với mỗi tập tin có một đầu vào liên tục (thời gian cần thiết để thiết lập kết nối và thời gian cần để mở một tệp trên hệ thống tệp). Ngoài ra còn có thời gian tải xuống rõ ràng được liên kết với kích thước của tệp. Tạo một hàm có thể diễn tả điều này khi thời gian còn lại về tốc độ tải xuống hiện tại là dễ dàng và chính xác tốc độ downlaod không biến động quá nhiều. Nhưng có vấn đề.

Với mô hình chính xác về hoạt động bạn đang thực hiện, bạn có thể dễ dàng dự đoán thời gian sử dụng sẽ không có ảnh hưởng bên ngoài. Và điều đó hiếm khi có thể.

Tuy nhiên, bạn có thể tìm giải pháp cố gắng hiểu và giải thích những ảnh hưởng bên ngoài này. Người dùng có thể thấy hữu ích khi được cảnh báo khi tốc độ thay đổi đáng kể khi họ có thể điều chỉnh kế hoạch của mình để phù hợp với ETA mới. Nó cũng có thể hữu ích để giải thích những yếu tố ảnh hưởng đến hoạt động hiện tại. ví dụ:

Your download will complete in 6 minutes, if the download speed stays at 50k/s 

Điều này cho phép người dùng đoán một số nếu biết tốc độ có thể thay đổi. Và cuối cùng dẫn đến ít thất vọng hơn.

4

Bram Cohen đã nói về điều này một chút. Ông đã đặt rất nhiều nỗ lực vào các tính toán ETA trong BitTorrent (nhưng trong một bài nói chuyện ông đã đề cập rằng chưa có ai đến với anh ta và nói "hey! Tính toán ETA tuyệt vời trong người đàn ông bittorrent!"). Nó không phải là một vấn đề đơn giản.

Một số liên kết có liên quan:

+0

Cảm ơn rất nhiều về các liên kết, tôi đã không nhận thấy chúng trong lần đầu tiên. Bây giờ tôi trở lại một nhiệm vụ tương tự và tò mò muốn xem lại câu hỏi của tôi. – Maghis

1

Trong Python:

>>> done=0.3; duration=10; "time left: %i" % (duration/done-duration) 
'time left: 23' 
+0

Bạn có thể giải thích những gì bạn đã làm không? –