Làm cách nào để ước tính thời gian tải xuống còn lại (chính xác)?

Question

Chắc chắn bạn có thể chia kích thước tệp còn lại cho tốc độ tải xuống hiện tại, nhưng nếu tốc độ tải xuống của bạn dao động (và nó sẽ), điều này không tạo ra kết quả tốt đẹp. Một thuật toán tốt hơn để sản xuất đếm ngược mượt mà là gì?

Answer 1

An exponential moving average là điều tuyệt vời cho việc này. Nó cung cấp một cách để làm trơn trung bình của bạn để mỗi khi bạn thêm một mẫu mới, các mẫu cũ trở nên rất quan trọng đối với mức trung bình tổng thể. Chúng vẫn được xem xét, nhưng tầm quan trọng của chúng giảm xuống theo cấp số nhân - do đó tên. Và vì đó là mức trung bình "di chuyển", bạn chỉ phải giữ một số duy nhất.

Trong bối cảnh đo tốc độ tải về công thức sẽ trông như thế này:

averageSpeed = SMOOTHING_FACTOR * lastSpeed + (1-SMOOTHING_FACTOR) * averageSpeed; 

SMOOTHING_FACTOR là một số giữa 0 và 1. Càng cao con số này, mẫu cũ nhanh hơn sẽ bị loại bỏ. Như bạn có thể thấy trong công thức, khi SMOOTHING_FACTOR là 1 bạn chỉ đơn giản là sử dụng giá trị của quan sát cuối cùng của bạn. Khi SMOOTHING_FACTOR là 0 averageSpeed không bao giờ thay đổi. Vì vậy, bạn muốn một cái gì đó ở giữa, và thường là một giá trị thấp để có được làm mịn phong nha. Tôi đã tìm thấy rằng 0,005 cung cấp một giá trị làm mịn khá tốt cho tốc độ tải xuống trung bình.

lastSpeed là tốc độ tải xuống được đo cuối cùng. Bạn có thể nhận được giá trị này bằng cách chạy một bộ đếm thời gian mỗi giây hoặc lâu hơn để tính toán số byte đã tải xuống kể từ lần cuối cùng bạn chạy nó.

averageSpeed là, rõ ràng là số mà bạn muốn sử dụng để tính toán thời gian ước tính còn lại của mình. Khởi tạo điều này cho phép đo lastSpeed đầu tiên bạn nhận được.

Answer 2

Tôi nghĩ tốt nhất bạn có thể làm là chia kích thước tệp còn lại cho tốc độ tải xuống trung bình (được tải xuống cho đến nay chia cho thời gian bạn tải xuống). Điều này sẽ dao động một chút để bắt đầu nhưng sẽ ổn định hơn và lâu hơn bạn tải xuống.

Answer 3

speed=speedNow*0.5+speedLastHalfMinute*0.3+speedLastMinute*0.2 

Answer 4

Trong phần mở rộng cho câu trả lời của Ben Dolman, bạn cũng có thể tính toán dao động trong thuật toán. Nó sẽ trơn tru hơn, nhưng nó cũng sẽ dự đoán tốc độ avarage.

Something như thế này:

prediction = 50; 
depencySpeed = 200; 
stableFactor = .5; 
smoothFactor = median(0, abs(lastSpeed - averageSpeed), depencySpeed); 
smoothFactor /= (depencySpeed - prediction * (smoothFactor/depencySpeed)); 
smoothFactor = smoothFactor * (1 - stableFactor) + stableFactor; 
averageSpeed = smoothFactor * lastSpeed + (1 - smoothFactor) * averageSpeed; 

Biến động hay không, nó sẽ được cả hai như là ổn định như người kia, với các giá trị phù hợp với dự đoán và depencySpeed; bạn phải chơi với nó một chút tùy thuộc vào tốc độ internet của bạn. Cài đặt này hoàn hảo cho tốc độ avarage 600 kB/s trong khi dao động từ 0 đến 1MB.

Answer 5

Tôi đã viết một thuật toán cách đây nhiều năm để dự đoán thời gian còn lại trong hình ảnh đĩa và chương trình phát đa hướng đã sử dụng trung bình di chuyển có đặt lại khi thông lượng hiện tại vượt ra ngoài phạm vi được xác định trước. Nó sẽ giữ cho mọi thứ suôn sẻ trừ khi một cái gì đó quyết liệt xảy ra, sau đó nó sẽ điều chỉnh một cách nhanh chóng và sau đó quay trở lại một trung bình di chuyển một lần nữa. Xem ví dụ biểu đồ ở đây:

Dòng màu xanh dày ở chỗ ví dụ biểu đồ là sản lượng thực tế theo thời gian. Chú ý thông lượng thấp trong nửa đầu của quá trình chuyển giao và sau đó nó tăng lên đáng kể trong nửa thứ hai. Đường màu cam là mức trung bình tổng thể. Lưu ý rằng nó không bao giờ điều chỉnh đủ xa để đưa ra dự đoán chính xác về thời gian cần thiết để hoàn thành. Đường màu xám là đường di chuyển trung bình (tức làtrung bình của N điểm dữ liệu cuối cùng - trong biểu đồ N là 5, nhưng trên thực tế, N có thể cần phải lớn hơn để đủ mịn). Nó phục hồi nhanh hơn, nhưng vẫn mất một lúc để điều chỉnh. Nó sẽ mất nhiều thời gian N càng lớn. Vì vậy, nếu dữ liệu của bạn khá ồn ào, thì N sẽ phải lớn hơn và thời gian khôi phục sẽ lâu hơn.

Dòng màu xanh lá cây là thuật toán tôi đã sử dụng. Nó giống như một đường trung bình di chuyển, nhưng khi dữ liệu di chuyển ra ngoài phạm vi được xác định trước (được chỉ định bởi các đường kẻ màu xanh và vàng nhạt), nó sẽ đặt lại trung bình di chuyển và nhảy lên ngay lập tức. Dải ô được xác định trước cũng có thể dựa trên độ lệch chuẩn để nó có thể điều chỉnh cách dữ liệu bị nhiễu tự động. Tôi chỉ cần ném các giá trị này vào Excel để vẽ sơ đồ chúng cho câu trả lời này vì vậy nó không hoàn hảo, nhưng bạn có được ý tưởng.

Dữ liệu có thể được giả tạo để làm cho thuật toán này không thể là một yếu tố dự báo tốt về thời gian còn lại. Điểm mấu chốt là bạn cần phải có một ý tưởng chung về cách bạn mong đợi dữ liệu hoạt động và chọn một thuật toán cho phù hợp. Thuật toán của tôi hoạt động tốt cho các tập dữ liệu tôi đã thấy, vì vậy chúng tôi tiếp tục sử dụng nó.

Một mẹo quan trọng khác là các nhà phát triển thường bỏ qua các lần thiết lập và teardown trong các thanh tiến trình và tính toán ước tính thời gian của họ. Điều này dẫn đến thanh tiến trình 99% hoặc 100% vĩnh cửu chỉ ở đó trong một thời gian dài (trong khi bộ nhớ cache đang bị xóa hoặc các công việc dọn dẹp khác đang diễn ra) hoặc ước tính ban đầu khi quét các thư mục hoặc công việc thiết lập khác xảy ra, tích lũy thời gian nhưng không tích luỹ bất kỳ tiến bộ phần trăm nào, điều này sẽ đẩy mọi thứ ra. Bạn có thể chạy một số thử nghiệm bao gồm các thiết lập và thời gian teardown và đi lên với một ước tính bao lâu những lần trung bình hoặc dựa trên kích thước của công việc và thêm thời gian đó vào thanh tiến trình. Ví dụ, 5% đầu tiên của công việc là thiết lập công việc và 10% cuối cùng là công việc teardown và sau đó 85% ở giữa là tải xuống hoặc bất kỳ quá trình lặp lại theo dõi của bạn là gì. Điều này cũng có thể giúp ích rất nhiều.