Windows 파일 복사 대화 상자 : 추정이 왜 그렇게 나쁜가?


38

견적

xkcd

Windows 복사 대화 상자 (Windows XP의 경우)는 복사본을 메모리에 먼저 저장하고 대화 상자를 닫은 후에도 여전히 복사 중이므로 시간이 꺼져 있지만 사본을 만드는 데 걸리는 시간의 추정은 왜 메모리 복사가 비활성화되어 있어도 Vista와 Windows 7에서 정확하지 않습니까? 너무 임의적 인 것 같습니다! 전체 복사 절차는 어떻게 작동하며 Windows에서 올바르게 추정 할 수없는 이유는 무엇입니까?



진행률 표시 줄에는 완료 시간 %가 아니라 완료된 파일 수가 표시됩니다.
Factor Mystic


3
또한 제약 조건이 보편적이라고 믿기 때문에 이것은 Windows뿐만 아니라 모든 OS에 적용되어야합니다 .
Clockwork-Muse

1
Mark Russinovich의 블로그 게시물은 다음과 같습니다. blogs.technet.com/b/markrussinovich/archive/2008/02/04/…
surfasb

답변:


29

한마디로, 열악한 알고리즘과 점프 예측은 실제로 구현상의 약점입니다.

TeraCopy 와 같은 다른 도구 가 더 잘 작동합니다. 나는 왜 그들의 구현이 좋지 않은지를 설명 할 가치가 없다고 생각합니다. 그들은 그것을 알아 차리고 개선 할 것입니다.

어려운 점 :

  1. 리소스 변동을 고려해야합니다 (주로 CPU / 네트워크 대역폭 / HDD 속도)
  2. 동작을 예측하여 소요되는 시간을 추정해야합니다 (Windows 파일 복사가 현재 제대로 수행되지 않는 기능).
  3. 시간이 지남에 따라 원래의 추정치로 조정하십시오 (위의 재미있는 그림과는 달리 작은 조정을 의미합니다!)

이를 위해 바이트의 양뿐만 아니라 생성 할 파일의 양이 중요한 역할을합니다. 백만 개의 1KB 파일 또는 천 개의 1MB 파일이있는 경우 전자가 많은 파일을 작성하는 오버 헤드가 있기 때문에 상황이 상당히 다릅니다. 사용 된 파일 시스템에 따라 실제로 데이터를 전송하는 것보다 시간이 더 걸릴 수 있습니다.

이 대화는 나에게 몇 번이나 화가났다.

  • 구형 WinNT 시스템에서 복사 할 작은 파일이 많으면 각 파일의 이름과 멋진 애니메이션이 표시되어 전체 프로세스 속도를 느리게하여 실제로 사용할 수 없게됩니다.

현대 Windows 사본은 그리 나쁘지 않습니다.

  • 전송할 데이터의 양을 계산하려면 먼저 조회를하는 것 (즉, 내가 생각하는 것)이므로 작업을 효과적으로 시작할 때까지 많은 디렉토리를 선택하면 시간이 오래 걸립니다.
  • 일부 내장 시간 초과는 큰 파일을 복사하도록합니다 (시스템에서 약 60GB). 고통은 네트워크를 통해 이미 30GB 이상을 복사 한 후 처음부터 다시 시작해야하기 때문에 대역폭과 시간이 손실된다는 것을 알려주는 것입니다!
  • 한 컴퓨터에서 다른 컴퓨터로 파일을 복사하는 것은 어떤 이유로 느려집니다. (사용 가능한 네트워크 대역폭과 비교할 때 다른 도구를 사용하면 속도가 빠르므로 계산상의 제한이 없습니다.)

매우 흥미로운!
Maxim Zaslavsky

48

Raymond Chen은 이것에 대해 아주 좋은 기사를 한 번 썼습니다. 기본적으로 대화 상자는 추측입니다. :).

http://blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

"복사 대화 상자는 추측 만하기 때문에 미래를 예측할 수는 없지만 시도해보아야합니다. 사본의 시작 부분에 기록이 거의 없을 때 예측이 실제로 나쁠 수 있습니다.

다음과 같은 비유가 있습니다. 누군가가 "100으로 세고, 언제 할 것인지에 대한 지속적인 추정을해야한다"고 말합니다. 그들은 "하나, 둘, 셋 ..."으로 시작합니다. 당신은 그들이 초당 약 하나의 숫자로 가고 있음을 알 수 있습니다. 어, 이제 속도가 느려지고 있습니다. "4 ... ... ... 5 ... ... ..."이제 추정치를 200 초로 변경해야합니다. 이제 속도가 빨라집니다. "6-7-8"추정값을 다시 업데이트해야합니다.

이제 당신의 추정만을 듣고 누군가를 세는 사람은 당신이 당신의 로커를 벗어났다고 생각합니다. 예상치는 100 초에서 200 초에서 50 초로 증가했습니다. 무엇이 문제입니다? 왜 좋은 견적을 줄 수 없습니까?

파일 복사도 마찬가지입니다. 쉘은 파일 수와 바이트 수를 알고 있지만 하드 드라이브 나 네트워크 또는 인터넷이 얼마나 빠른지 알지 못하므로 추측해야합니다. 복사 처리량이 변경되면 새 전송 속도를 고려하여 견적을 변경해야합니다. "


8
그가주는 비유는 한 단어로 요약 할 수 있습니다 : 통계.
surfasb

33

10까지 세려고합니다. 10 1....2....3....4점에 도달하는 데 몇 점이 필요합니까?

5.6.7지금은 어때? 숫자 사이의 모든 과거 점을 고려하여 평균을 계산합니까? 마지막 4 간격 만 사용하고 해당 평균을 사용합니까? 마지막 간격 만 보십니까?

파일 전송과 동일한 문제가 있습니다. 파일 전송 속도는 일정하지 않으며 많은 요인에 따라 속도가 느려지고 속도가 느려집니다. 숫자가 너무 많이 증가하는 이유는 Microsoft가 스펙트럼의 "마지막 간격 만 계산"쪽으로 기울이기 때문입니다.

스펙트럼의 측면에는 아무런 문제가 없습니다.보다 정확한 "초당 초"를 제공합니다 (실시간으로 1 초는 카운터가 1 초씩 내려갑니다). 이로 인해 타이머의 총 ETA가 많이 점프합니다. .

반대편의 좋은 예 는 압축 할 때 7-Zip 입니다. 압축 속도가 처리되는 동안 속도가 떨어지면 ETA가 파일 전송 ETA처럼 급격히 증가하지는 않지만 타이머가 1 초간 틱 다운되기까지 2 ~ 3 초가 걸릴 수 있습니다 (또는 카운트가 시작될 수도 있음) 새로운 속도로 안정화 될 때까지


2
그들이 지수 또는 규칙적인 이동 평균을하지 않은 이유를
깨달았습니다

@Mehrdad 필자는 최신 버전의 Windows에서 ETA 시간이 Windows 7 이상의 7zip과 훨씬 유사하게 작동한다고 생각합니다.
Scott Chamberlain

15

실제로 WAAAAAY 의 Microsoft Raymond Chen의 정식 답변거의 없으며 퍼즐에 몇 가지가 있습니다.

복사 대화 상자가 추측하기 때문입니다. 미래를 예측할 수는 없지만 시도해야합니다. 그리고 사본의 맨 처음에 갈만한 역사가 거의 없을 때 예측이 실제로 나쁠 수 있습니다.

첫째, Windows가 추측하고 있습니다. 파일 수와 크기를 알고 있지만 파일 당 전송 속도는 매우 다양합니다. 크기 또는 드라이브 위치에 따라 다릅니다. 시간이 지남에 따라 현재 및 과거 조건을 기반으로 추측을 조정하므로 실제 조건에서 예상 전송 속도가 정확하지 않습니다.


흥미로운 점은 2004 년 첫 번째 의견은 Vista에서 2006 년까지 소개되지 않은 남은 바이트 수를 보여주는 자세한 파일 복사 정보 드롭 다운을 설명합니다.
Scott Chamberlain

2
예, 채팅중인 사람도이 점을 지적했습니다. 나는 그 대신에 응시하는 화려한 그래프를 그에게 주면서, 완성 시점에 응시하는 사용자의 문제를 해결한다고 말하고 싶은 유혹이있다 :)
Journeyman Geek

@JourneymanGeek "누군가 채팅"보고! 그러나이 사이트는 꽤 권위있는 소스이지만 2004 년부터 시작되었으며 Windows 8에서 현재 사용중인 현재 알고리즘과 크게 구식이며 모호하게 관련되어 있음을 명심해야합니다.
Bob

1
Windows 8 관련 블로그 게시물 은 다음과 같습니다 . "사본을 완성하는 데 남은 시간을 예측하는 것은 거의 불가능합니다. 약간만 개선 될 수있는 낮은 신뢰도 추정값으로 많은 시간을 투자하는 대신 현재의 이상, 우리는 우리가 ... "확신했던 정보 제시에 초점을 맞추고
켈리 토마스

12

여기 설명 에 의해 레이몬드 첸 , 마이크로 소프트의 수석 소프트웨어 디자인 엔지니어 :

복사 대화 상자가 왜 그렇게 끔찍한 견적을 제공합니까?

복사 대화 상자가 추측하기 때문입니다. 미래를 예측할 수는 없지만 시도해야합니다. 그리고 사본의 맨 처음에 갈만한 역사가 거의 없을 때 예측이 실제로 나쁠 수 있습니다.

다음과 같은 비유가 있습니다. 누군가가 "100으로 세고, 언제 할 것인지에 대한 지속적인 추정을해야한다"고 말합니다. 그들은 "하나, 둘, 셋 ..."으로 시작합니다. 당신은 그들이 초당 약 하나의 숫자로 가고 있음을 알 수 있습니다. 어, 이제 속도가 느려지고 있습니다. "4 ... ... ... 5 ... ... ..."이제 추정치를 200 초로 변경해야합니다. 이제 속도가 빨라집니다. "6-7-8"추정값을 다시 업데이트해야합니다.

블로그 게시물 위에 인용 한 몇 가지 흥미로운 의견이 문제의 긴 토론을 가지고 있습니다.

Raymond Chen은 전설적인 인물 인 "Microsoft의 척 노리스 (Chuck Norris)"입니다. 더 신뢰할만한 답변을 얻을 것이라고 생각하지 않습니다. 나는 그가 문제의 코드를 보았을 것이라고 확신한다.


9

명백한 이유는 전송 속도가 시간이 지남에 따라 변하기 때문에 평균도 변하고 예측도 변하기 때문입니다. 기술이 아닌 친구에게 이것을 설명하기 위해, 나는 비행기 여행과 관련된 비유를 사용했습니다. 당신은 대서양을 날아갈 것입니다. 출발 공항에서 택시로 도착하면 도착 예상 시간은 약 2 개월입니다. 지금까지의 평균 속도를 기준으로 도착 공항에서 하선하면 5 초 안에 친구의 집에 도착합니다.

그러나 동일한 디스크 내에서 파일을 복사하거나 두 개의 로컬 디스크간에 파일을 복사하는 것과 같이 예측 가능한 시나리오처럼 보일지라도 실제로 속도가 얼마나 달라질 수 있는지 알아야합니다. Windows 8에서 내가 좋아하는 새로운 기능 중 하나는 "자세한 정보"를 클릭하면 시간에 따른 속도를 그래프로 표시하는 기능입니다. Windows 8 시스템에 액세스 할 수없는 경우 Windows 8 사본 대화 상자의 이미지를 검색 하여 많은 예를보십시오. 대부분은 상당히 평평하지만, 하드 드라이브가 실제로 0으로 떨어질 때 하드 드라이브가 실제로 정상인지 궁금해하는 시점까지 혼란스럽게 울퉁불퉁합니다.

이러한 충돌 중 일부는 파일 크기의 변화로 인해 발생합니다. 필드가 작을수록 더 많은 액세스가 발생하여 읽기 헤드를 움직여 검색해야하는 기계식 하드 드라이브의 경우 속도가 느려집니다. 그러나 일부는 저렴한 드라이브 일 수 있습니다. 플래터의 손상을 방지하기 위해 약간의 접촉으로 멈 춥니 다.

ETA 예측 알고리즘이 더 좋고 나쁘지만 정확한 예측을 위해서는 컴퓨터가 모든 것을 알고 있어야합니다. 알고리즘을 "똑똑한"것으로 만들려는 위험은 예상치 못한 새로운 경우가 더 유쾌하게 잘못 될 수 있다는 것입니다.

Windows 8 복사 대화 상자

Windows 8 복사 대화 상자 2


4

파일 집합을 압축하는 데 걸리는 시간을 알 수있는 유일한 방법은 파일을 압축하는 것입니다. 때로는 Windows의 최선의 추측이 가깝고 때로는 잘못되었습니다. 이미 알고 있듯이 대량의 파일을 복사하는 경우에도 마찬가지입니다.

거의 정확한 정보를 쓸모없는 것으로 표시하는 것은 그리 버그가 아닙니다. 그것을 고치는 가장 좋은 방법은 눈을 감는 것입니다. 무시해. ;-)

아마도 파일을 복사 / 압축하고 완료되면 알람 소리를내는 프로그램이있을 것입니다. 정말 유용 할 것입니다. Windows가 집안 청소를 마칠 때까지 약간의 낮잠이있을 수 있습니다.


4

나는 그 이유가 Roald의 답변과 연결된 블로그 게시물 의 의견 중 하나에서 잘 설명되어 있다고 생각합니다 .

그것은 끔찍한 추정 알고리즘을 가지고 있습니다. 변명의 여지가 없습니다. 1000 개의 1KB 파일과 10 개의 1MB 파일을 복사해야하는 경우 1KB 파일과 마찬가지로 1MB 파일로 사용 중이라고 생각합니다.

그것이 끔찍한 추정을하는 이유는 그것이 잘 이루어지지 않았기 때문입니다. 분명히 100 % 정확할 수는 없지만 훨씬 더 나을 수 있습니다.


1
파일이 Windows에 얼마나 큰지 알려면 파일을 열어야하며 Windows에서 파일을 열려면 파일을 읽습니다. 그리고 모든 파일을 열어 복사 시간이 얼마나 걸리는지 예상 할 수있는 크기를 확인하는 대신 Windows는 실제로 파일을 복사하는 시간을 사용하기로 결정했습니다. 결국 귀하가 요청한 것입니다.
SecurityMatt

1
@SecurityMatt :이 경우 디렉토리 목록을 가져 오려면 오래 걸립니다. 파일 크기가 디렉토리에 저장되고 파일이 변경 될 때마다 업데이트됩니다. 따라서 디렉토리에 나열된 파일 크기와 전송 속도에 대한 몇 가지 가정을 기반으로 복사 시간을 빠르고 정확하게 추정 할 수있는 방법이 있어야합니다. 정말 똑똑한 OS는 시간이 지남에 따라 평균 전송 속도에주의를 기울여 추정에 사용합니다.
RobH

4

복사 프로세스를 신속하게 수행하기 위해 (복사 관련 작업을 수행하는 대신 예상 시간을 계산하는 데 너무 많은 시간을 소비하지 않음) 탐색기에 내장 된 Windows 복사 유틸리티는 이전 쓰기 작업이 얼마나 빨리 완료되었는지에 대한 정보를 제한적으로 유지합니다. 남은 시간을 계산해야 할 때마다 쓰기 작업에 걸린 평균 시간을 파악한 다음 남은 쓰기 작업 수를 곱합니다.

문제는 쓰기 작업을 수행하는 데 걸리는 시간이 일정하지 않다는 것입니다. 실제로는 크게 다를 수 있습니다. 결과적으로 시간 추정치에 상당한 변화가 발생합니다.


나는 당신이 이것에 대해 옳지 않다고 생각합니다-당신은 단지 2 개의 숫자를 사용하여 쓸만한 평균 쓰기를 유지할 수 있습니다-현재 평균 [ A] 및 그 평균을 얻는 데 사용되는 데이터 포인트 수 [ n]. 그런 다음 업데이트하려면의 경우입니다 (A*n + [New value])/[n+1]. 또한 복사 작업은 거의 항상 CPU 바운드가 아닌 IO 바운드이므로 몇 초마다 간단한 계산은 아무 것도 아닙니다. 반면, 마지막 n쓰기 의 평균을 유지 하려면 n요소 의 배열 / 큐 / 스택이 필요 하므로 어떤 값을 제거해야하는지 알 수 있습니다.
기본

좋은 지적! 왜 도대체 왜 그렇게 도대체? : P
Brian Gradin

나는 그들이 마지막 몇 번의 쓰기만을 고려하여 더 반응적인 평균을내어 영리하려고 노력했으며 너무 적게 선택했습니다. 즉, 나는 소스를 가지고 있지 않으므로 누가 알 수 있습니까?
기본

4

고려해야 할 세 가지 요소가 있습니다.

  1. 전송의 총 크기입니다.
  2. 전송할 파일 수
  3. 미디어의 "바쁨"및 연결 일 수 있습니다.

숫자 1과 3은 전송 시간 계산에 가장 명백한 영향을 미치는 것처럼 보이지만 많은 사람들이 숫자 2를 고려하지 않습니다. 이는 전송 시간에 영향을 줄 수 있으며 수량화하기가 어렵습니다.

기본적으로 파일을 작성할 때마다 파일 시스템은 파일에 대한 메타 데이터를 작성해야합니다. 소유권, 권한, 생성 / 수정 / 액세스 시간 등. 특정 파일 시스템에 따라이 정보는 파일이 작성되는 위치와 매우 '먼'디스크 부분에 기록 될 수 있습니다. 이 파일 시스템 오버 헤드는 단순하게 전송하는 데 시간이 오래 걸리거나 시간 추정치가 크게 변동될 수 있습니다.

예 : 하나의 큰 파일을 전송하면 추정치가 안정적으로 유지되지만 크기는 다르지만 총 크기는 동일하지만 수백 개의 파일을 전송하면 시간이 더 오래 걸리고 시간 추정치가 적합 할 수 있습니다.


4

현재 추정 알고리즘에는 세 가지 결함이 있습니다.

대중의 믿음과는 달리 그들은 우리의 손을 내밀기에는 거의 어렵지 않습니다.

대부분의 사람들이 블로그를 작성하고 여기 사람들이 그 가능성을 알지 못하는 이유는 내가 공부와 학교의 폭 때문에 내가 알 수있는 가장 좋은 것입니다. [십억 달러 규모의 회사] 마이크로 소프트 [블로그 작성자보다 더 최근의 교육을받은 졸업생]에게는 겸손하지만 매우 편안한 치료가 가능해야합니다 .

나는 왜 그런지 대략 설명하려고 노력할 것이다.


실패 지점은 다음과 같습니다. 커널 :

1. 커널 범위를 벗어난 상황으로 인해 향후 IO로드를 안정적으로 예측할 수 없음

  • 매우 무한한 P = NP 문제이므로 이에 대해 수행 할 작업이 없습니다.

2. 유용한 수준의 IO 휴리스틱추적하지 않습니다 . 사용률 은 디스크 / 네트워크 읽기 / 쓰기 속도보다 훨씬 넓은 개념 입니다.

  • 가장 기본적인 IO 사용 정보를 추적하는 것 이상으로이 작업을 수행 할 필요가 거의 없습니다.

    • 디스크에서
      • 평균 판독 속도 치수 1a
      • 파일 차원 의 평균 쓰기 속도 2a
    • 에 따라 퀀 타당 * 기준으로
      • 파일의 크기 치수 b
      • 디스크 치수 c 에서의 파일 위치
    • * 3 개 이하의 범주로 정량화 됨. 차원 축소는 우리가 특정 사항을 결정하는 데 도움이되지만 3 개는 아무 것도없는 예측 메커니즘보다 훨씬 효과적 일 것입니다.
      • 파일 크기
        • 매질
        • 무거운
      • 위치 [검색 대기 시간을 알려줍니다]
        • 처음
        • 중간
        • 당신은 요점을 얻습니다
      • 파일 크기와 위치가 중복 / 읽기 / 쓰기 속도와 겹칩니다. 이것은 의도적 인 것입니다.
    • 우리는 디스크가 우리가 바쁜 것이되는 것입니다 가정 할 수 있도록하는 것이왔다 방법 "중"알 필요 치수 D
      • 읽고있는 파일의 양을 계산하여 각각의 가중치로 구성
      • 복사 시작시 시간을 추정하는 데 사용됩니다 ... 이 복사 대화 상자를 제외한 다른 모든 것이 지금처럼 계속되는 경우 향후 예상로드를 기반으로 대화 상자
    • 목적을 위해 녹음 하는 방법은 여기 특허입니다

3. 그들은 추적 , 휴리스틱에 사용하지 않을 것

  • 우리가 대부분의 작업을 수행하는 곳은 거의 이루어지지 않았습니다.
  • 이것은 우리가 사용하기 위해 # 2의 데이터를 넣는 곳입니다.
    • 파일 무게와 위치에 대한 대략적인 통계 분석을 통해 얼마나 많은 호핑을 할 것인지 결정합니다. 무게 + 위치는 우리에게 예측을 제공합니다
    • 현재 디스크로드 무게 및 위치와 결합
    • 우리는 파일의 수의 평균 읽기 / 쓰기 속도가 무슨 생각을 추정하기 F 치수의
    • 모델을 미세 조정하는 것과 비교할 때
    • 진행률 표시 줄과 완료 시간을 정확하게 예측할 수 있습니다.
  • 예측 목적으로 분석 하는 방법 ... 여기 특허가 있습니다

이 모든 점은 우리 모델이 2a = F * (bxc) + d complex

a, b 및 c는 각각 3 가지 상태를 갖습니다. 파일 관리자는 복사하기 전에 파일 (또는 메타 데이터)을 들여다보고 F * (bxc) + d는 값 비싼 계산이 아닙니다. 더 정확한 것을 원하면 더 많은 상태의 조회 테이블을 사용하십시오. 아무 계산도 거의 없습니다.

참고 : 여기의 치수는 플래터 용이며 SSD와는 다릅니다. 시작 / 중간 / 끝은 중요하지 않습니다.

지금까지 설명한 것과 이전에 구현 한 것의 주요 차이점은 간단히 말해서 디스크에서 파일 크기 및 파일 분산 / 엔트로피를 관찰하고 디스크 사용의 시간 요소를 정확하게 설명하는 데 사용하는 것입니다.

(특허는 독자의 연습으로 남겨둔다 ...)


@Twisty 내가 끝났어, 지금 어때?
pa11

훨씬 낫다. 사이트를 이용해 주셔서 감사합니다. 커뮤니티에 참여해 주셔서 감사합니다.
나는 말한다 Reinstate Monica

3

시간이 얼마나 걸리는지 예측하려고 할 때 "알 수없는"변수가 많이 있습니다. 예를 들어, 프로그램은 3500 개의 파일이 있고 파일 크기가 3.5GB (3500MB)라는 것을 알고 있지만 각 파일이 1MB라는 것을 의미합니까? 반드시 그런 것은 아닙니다. 4KB 파일이 많고 100MB 파일이 많으며 그 사이에 다른 파일이있을 수 있습니다. 또한 파일이 어디에서 왔으며 어디로 가고 있는지 (예 : 미디어) 고려해야합니다. 가장 큰 병목 현상은 무엇입니까? VPN 터널을 통해 HDD에서 파일을 복사하려고 시도하는 방법은 무엇입니까? 최상의 시나리오를 제시 한 다음 실시간으로 카운터를 조정하십시오. 그렇기 때문에 진행률 표시기가 즉시 변경되는 것을 볼 수 있습니다.


2

수학적으로 올바른 모델은 실제로 순진한 평균화와 외삽 법을 수행하는 것입니다.

transfer speed = data copied / time elapsed
time remaining = data remaining / transfer speed

그 이유는 큰 숫자의 법칙에 따라 로컬 변동이 평균 전송 속도 에서 상쇄되어 가장 안정적인 결과를 얻을 수 있기 때문입니다.

Microsoft 가하는 일은 최신 시간 프레임에서 전송 속도 를 계산하는 입니다. 이는 각 지역 변동이 결과를 크게 변경한다는 것을 의미합니다.


2
모델은 다른 파일 전송을 병렬로 시작하는 것과 같이 장기 실행 방해를 제대로 처리하지 못하며 동일한 양의 데이터가 20 분만 걸리더라도 5 분만 더 걸릴 것이라고 계속 알려줍니다. 가중 이동 평균이 더 정확할 수 있습니다.
다니엘 벡

@DanielBeck : 정확하지 않습니다. 예상 시간이 점차 증가합니다. 문제는 얼마나 빨리 증가 할 것인가입니다. 글쎄, 그것은 경과 시간에 달려 있습니다. 예를 들어 이미 5 시간 동안 복사 한 작업이 긴 작업 인 경우 기대치를 크게 늘리지 않습니다. 그러나 5 시간 동안 15 분 정도의 부정확성이 중요합니까? 요점은 상대 오차 측면에서 최상의 근사치를 제공한다는 것입니다. 또한 모든 시나리오 에서 훨씬 더 잘 작동하는 것을 할 수는 없습니다 .
ybungalobill

2
모델의 문제는 전송 중 전송 속도 변화에 절대적으로 반응하지 않는다는 것입니다. 이는 빠르게 반응하는 Windows 파일 전송 와 같이 견딜 수 없습니다 . : 처음에 10MB / s에서 60GB 전송. 시작시 남은 시간 : 100 분. 54GB를 전송하고 2MB / s로 드롭하십시오. 90 분 후 : 54GB로 남은 예상 시간 : 10 분 54GB로 실시간 남은 시간 : 50 분 115 분 후 : 57GB 남은 예상 시간 : 6 분. 57GB에 실시간 남은 시간 : 25 분 131.67 분 후 : 예상 시간 59GB 남은 시간 : 2.23 분. 59GB에 실시간 남은 시간 : 8.33 분.
Daniel Beck

@DanielBeck : 전체 전송은 150 분 동안 지속되므로 전송 시작시 최대 상대 오류는 50 %이며 더 잘 수행 할 수 없습니다. 54GB에서는 총 14 % 할인됩니다. (150 분이 걸리면 20 분이 중요한 이유는 무엇입니까?) 실제로 매우 좋은 추정치입니다. 이 문제를 개선 할 수있는 방법이있다 하지 당신이해야 윈도우의 어떤 크기를 알 수 없기 때문에 이동 평균 가중치 (이 작업은 파일을 복사 같은 분 정도 걸릴 것으로 예상 않습니다
ybungalobill

또는 10 분의 10MB / s 및 10 분의 0MB / s를 얻는 p2p 파일 공유 프로토콜을 통한 시간). 이를 개선하는 방법은 크기가 아닌 시간에 따라 평균 가중치를 취하는 것입니다.
ybungalobill 18시 54 분

1
There is some way to refine or correct this kind of "bug"?

Roald van Doorn이 말했듯이 기본적으로 추측입니다. 물론, 이것이 더 나은 추측이 될 수 없다는 것을 의미하지는 않습니다. 이를 계산하는 데 사용할 수있는 휴리스틱이 많이 있습니다.

  1. 가장 비용이 많이 드는 가장 좋은 방법은 이전 '사본'의 이력을 유지하고 인공 지능 알고리즘을 사용하여 추측을 계산하는 것입니다.
  2. 시간이 얼마나 걸리는지에 대한 연구를 바탕으로 공식을 만들 수 있습니다. 파일 시스템, 파일 수, 파일 크기, 디스크 검색 시간, 디스크 대량 읽기 / 쓰기 속도, 디스크의 파일 위치 (조각화), 현재 디스크 사용률 등을 고려할 수 있습니다.
  3. 둘의 혼합. 즉. 일부 벤치 마크를 수행하여 특정 연산에 걸리는 시간을 확인한 다음 간단한 수식의 기록으로 사용하십시오.

분명히이 중 어느 것도 쉽게 구현할 수 없습니다. 파일 사본 만 언급했습니다. 모든 종류의 전송에 대해 유사한 작업을 수행해야합니다.
스스로 물어봐야 할 질문-마이크로 소프트가 더 나은 견적을 제공하는 데 시간을 투자하겠습니까, 아니면 파일을 더 빨리 전송하도록 하시겠습니까?

그러나 7-zip으로 무언가를 압축하면 창보다 추측하는 것이 훨씬 낫다는 것을 알 수 있습니다. 나는 그것이 다소 복잡한 추측을하고있는 것을 의심합니다.


1

요컨대, 계산은 현재 전송 속도를 기반으로합니다 .

예를 들어, Windows에서 많은 양의 작은 파일을 복사해야하기 때문에 전송 속도가 떨어지면 큰 파일의 경우 예상 시간이 선형으로 증가 하고 그 반대도 마찬가지 입니다.

파일 크기, CPU 사용량, 전송 오류 등과 같은 많은 요소에 의존하기 때문에 전체 전송 프로세스 에서 전송 속도 를 예측 하는 것은 거의 불가능합니다 .


1

MSDN 블로그 게시물에는 파일 관리 기본 사항 개선 : 복사, 이동, 이름 바꾸기 및 삭제 에 대한 흥미로운 답변 이 있습니다. 왜 어려운지에 관해서 :

예를 들어, 복사 작업 기간 동안 사용할 수있는 네트워크 대역폭의 양과 같이 예측할 수없고 제어 할 수없는 변수가 많기 때문에 복사를 완료하는 데 남은 시간을 예측하는 것은 거의 불가능합니다. 안티 바이러스 소프트웨어가 가동되어 파일 검색을 시작합니까? 다른 응용 프로그램이 하드 드라이브에 액세스해야합니까? 사용자가 다른 복사 작업을 시작합니까?

그들이 어떻게 개선하고 있는지

현재보다 약간 개선 된 낮은 신뢰도 추정값을 얻기 위해 많은 시간을 투자하는 대신, 우리는 우리가 확신하고있는 정보를 유용하고 설득력있게 제시하는 데 집중했습니다. 이를 통해 가장 신뢰할 수있는 정보가 제공되므로보다 정확한 결정을 내릴 수 있습니다.

즉, 주어진 견적 만 향상시키고 진행률 표시 줄을 그대로 유지하려면 Slashdot 주석 에서 제안 된 작업을 수행 할 수 있습니다 .

파일 시스템의 각 저장 장치에 대한 예상 속도 표를 유지하십시오. 파일 시스템 정보를 읽는 데 걸리는 시간을 기록하십시오. 장치를 장착 할 때 장치 유형에 적합한 경우 속도를 측정하여 중간과 끝을 찾으십시오. 여러 위치에서 읽기 및 쓰기 속도에 대한 대략적인 곡선을 얻고 향후 추정에 사용하십시오. 향후 읽기 및 쓰기 작업을 위해서는 위치와 속도를 기록하고 그에 따라 곡선을 조정하십시오.

작업이 시작되면 각 장치의 입력 및 출력 곡선을 확인하십시오. 목표 위치에 대한 예상 속도를 찾으십시오. 추정에 더 낮은 속도를 사용해야합니다.


1

총 파일 수는 PC에서 파일을 복사하는 데 가장 많은 시간이 걸리는 요소라는 점을 추가하고 싶었습니다. 나는 항상 어린 학생으로 기억할 수 있는데, 내용이없는 1 개의 파일로 시작하여 복사 한 다음 2 개의 파일을 선택하고 다시 복사하는 등의 방식으로 내 컴퓨팅 클래스에서 PC의 고장을 의도적으로 유도 할 수 있습니다. 파일이 약 1024 개가 지난 후에는 파일 헤더에 대한 정보 저장이 복사되지 않은 경우에도 무엇이든하기 위해 많은 시간이 걸렸습니다. 새로운 OS, 지수 파일 복사본에서도 직접 시도하면 어떤 일이 발생하는지 볼 수 있습니다. 생각할 거리.


흥미롭지 만 질문에 대한 답은 아닙니다. 답변 하기 전에 답변 방법을 읽으십시오 .
사용자 99572은 괜찮습니다

0

USB HDD에서 메인 드라이브로 200GB를 복사했습니다. 약 130000 개의 파일이있었습니다

처음 4-5 분 후 나는 다음을 관찰했다.

  • 가장 작은 파일의 경우 속도는 약 600KB / s로 초당 약 100 개의 파일입니다.
  • 그리고 큰 파일의 경우 70MB / s와 같습니다.

처음에 창은 1 시간에서 5 시간 이상으로 추정을 변경 한 다음 다시 1 시간으로 변경했습니다. 결국 95 %에서와 마찬가지로 여전히 10 분에서 10 시간으로 추정값을 변경하고있었습니다. 따라서 정확도가 높아지는 대신 정확도가 떨어졌습니다.

간단한 수학 쇼 :

초당 100 개 파일에서 130,000 파일 = 22

200,000 에서 MB 70 초 당 = MB (47)

22 분-몇 킬로바이트 크기의 파일을 복사하는 탐색 시간이 줄었습니다. 47 분-검색 시간이없는 경우 실제 데이터를 전송하는 데 필요한 시간입니다.

22 분 + 47 분의 합은 가능한 최대 시간입니다.

그래서 분명히 추정치는 사이 어딘가에 있어야합니다 4769 분 거리에 있습니다.

대화 상자에서 약 90 %로 표시되는 내용 : "작은 파일을 1MB / s로 복사하고 있으며 20GB 이상의 데이터가 있으며 완료하는 데 5:30 시간이 걸립니다.

몇 초 후 : "70MB / s에서 큰 파일을 복사하는 데 완료하는 데 4 분이 걸립니다.

실제로 동일한 대화 상자에서 사람이 보는 것 : 120,000 개의 파일과 180GB가 이미 40 분 동안 복사되었습니다. 나머지 10000 개 파일과 20GB는 약 5 분이 걸립니다.

이 대화 상자는 초당 더 정확한 계산을 수행 할 수있는 충분한 정보를 제공합니다. 작은 파일이 복사되는 속도를 알고 있습니다. 큰 파일이 어느 속도로 복사되는지 알고 있습니다. 또한 파일 수와 남은 바이트 수를 알고 있습니다.

상한과 하한을 설정해야만 정확한 가정을 할 수 있습니다.

대화 상자는 큰 파일이 작은 파일보다 앞에있는 경우에만보다 정확한 데이터를 표시합니다. 이 경우 40 분에 시작하고 30 분 후에 작은 파일을 복사하기 시작하고 "20 분 더 필요합니다"라고 표시됩니다.

그러나 처음에 작은 파일과 큰 파일이 끝날 때. 대화 상자는 실제로 작은 파일을 전송하는 "초당 파일 수"에 신경 쓰지 않습니다. 작은 파일 수는 무한대로 계산되며 영원히 작을 것입니다.


이것은 실제로 질문에 대답하지 않습니다.
DavidPostill

주의 깊게 읽으면 실제로 대답합니다. 그들은 두 가지 유형의 나쁜 평가이며, 예제 기반 리버스 엔지니어링 관점에서 왜 발생하는지 설명했습니다.
Xizario
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.