MTRACE(8)

명칭
mtrace - 발신기지로부터 수신측에게로의 멀티 캐스트의 경로를 표시한다

서식
mtrace [-e extrahops] [-g gateway] [-i if_addr] [-l] [-M] [-m max_hops] [-n] [-O] [-p] [-P] [-q nqueries] [-r resp_dest] [-s] [-S stat_int] [-t ttl] [-T] [-U] [-v] [-w waittime] source [receiver] [group]

해설
IP 멀티 캐스트의 트래픽의 배송에 있어서의 문제점을 밝혀내는 것은 곤란한 작업입니다. mtrace 유틸리티는 IGMP 프로토콜의 확장 기능에 의해 액세스 되는, multicast router에 실장된 트레이스 기능을 이용합니다. receiver (으)로부터 source 에의 역경로를 따른 호프 마다 트레이스의 문의를 행해, 경로상의 호프의 주소, 패킷수, 루팅의 에러 상황의 정보를 수집해, 요구자에게 응답을 돌려줍니다.

유일 필수인 인수는 source 의 호스트명 혹은 주소입니다. 디폴트의 receiver (은)는 mtrace 를 실행하고 있는 호스트가 되어, 디폴트의 group (은)는 0.0. 0.0 이 됩니다. 특정의 멀티 캐스트 그룹 에서의 패킷 소실의 통계가 필요하지 않으면, 이것으로 충분합니다. 이하에 해설되고 (이)라고 있는 몇개의 제약을 조건으로서 특정의 group 에서의 몇개의 다른 receiver 를 테스트하기 위해서, 이러한 2 개의 옵션의 인수를 지정할 수가 있습니다. receiver (은)는 uni-cast 주소이며, group (은)는 멀티 캐스트 주소인 것 보다, 이러한 2 개의 인수를 구별할 수가 있습니다. -g 플래그가 지정되면(자), source 주소에는 mtrace 하지만 실행되고 있는 호스트가 디폴트로서 사용되어 receiver 에는 -g 플래그로 지정되는 라우터가 디폴트로서 사용됩니다. 이 경우, 필수의 인수는 없습니다.

주: Solaris 2.4/2. 5 에서는 멀티 캐스트 인터페이스가 디폴트의 인터페이스가 아니면, -i 옵션에 의해 로컬 주소를 세트 하지 않으면 안됩니다.

이하의 옵션을 사용할 수 있습니다:

-e extrahops
    응답이 없는 라우터를 넘어, extrahops 만의 호프수의 트레이스를 시도합니다.

-g gwy
    트레이스의 문의를, 멀티 캐스트가 아니고, uni-cast에 의해 직접 multicast router gwy 에 보냅니다. 이 multicast router는 의도한다 source (으)로부터 receiver 에의 경로상의 마지막 호프의 라우터가 아니면 안됩니다.

    주의 !! 버젼 3.3 으로 3.5 의 mrouted (은)는, 트레이스의 문의가 uni-cast 패킷에 의해 수신되고 한편, mrouted 에 source 에의 경로가 없으면 크래쉬 합니다. 그 때문에 타겟의 mrouted 하지만 3.4 인지, 3.5 보다 새로운 것이 밝혀지지 않으면, -g 옵션을 사용하지 말아 주세요.

-i addr
    addr (을)를 트레이스의 문의를 보낸다 (multi-homed host상의) 로컬 인터페이스 주소, 및 receiver (와)과 응답처의 디폴트 주소로서 사용합니다.

-l  10 초 마다 멀티 캐스트 경로의 패킷 레이트와 소실의 통계를 표시해, 엔들레스 루프 합니다. ( -S stat_int 참조)

-M  시도의 후반은, uni-cast가 아니고, 항상 멀티 캐스트를 사용해 응답을 요구합니다.

-m n
    receiver (으)로부터 source 에 거슬러 올라가 트레이스 되는 최대 호프수를 n 에 세트 합니다. 디폴트는 32 호프 (DVMRP routing protocol에 대해서는 무한) 입니다.

-n  호프 주소를 심볼명 및 숫자는 아니고 숫자로 표시합니다. (경로상에 발견된 각 라우터에 대한다 네임서버에서의 주소-이름 검색을 생략할 수가 있습니다. )

-q n
    모든 호프에 대해서 시도하는 문의의 최대의 회수를 n 에 세트 합니다. 디폴트는 3 입니다.

-O  router-alert IP 옵션을, 이것이 필요한 요구에 대해도 사용하지 않습니다. Cisco 의 IOS 의 몇개의 버젼에서는 IP 옵션포함의 멀티 캐스트 트레이스 루트를 취급할 수 없기 때문에, 마지막 호프의 라우터가 Cisco 의 것일 때는, -O 플래그가 필요한 일이 있습니다.

-p  외로부터 기동된 트레이스에 의한 멀티 캐스트의 응답을 수동적으로 청취합니다. 이것은 multicast router상에서 동작하고 있는 경우에 가장 자주(잘) 동작합니다.

-P  10 초 간격으로 경로 정보를 수집하면서 엔들레스 루프 해 ( -S stat_int 참조), 경로 정보가 변화하면(자) 그것을 표시합니다. 통계 정보는 표시하지 않습니다.

-r host
    트레이스의 응답을, mtrace 하지만 실행되고 있는 호스트나 이 목적으로 등록되어 있는 다른 멀티 캐스트 주소 (224.0. 1.32)가 아니고, host 에 보냅니다.

-s  멀티 캐스트 경로만을 포함한 짧은 형식의 표시를 행해, 패킷 레이트와 소실 통계는 표시하지 않습니다.

-S n
    통계 정보를 수집하는 간격을 n 초 (디폴트는 10 초)로 변경합니다.

-t ttl
    멀티 캐스트 트레이스의 문의와 응답의 ttl (time-to-live 혹은 호프수)(을)를 세트 합니다. ttl 에 1 을 사용하는 "모든 라우터" 에의 로컬인 문의의 경우를 제외해, 디폴트는 127 입니다.

-T  "터널 통계" 모드입니다. 모든 트래픽에서의 로스 레이트를 표시합니다. 이러한 통계는 매우 오해를 부를 우려가 있는 것입니다.

-U  멀티 캐스트로부터 시도하는 것이 아니라, 항상 uni-cast에 의한 응답을 요구합니다.

-v  장황 모드입니다. 최초의 트레이스의 호프 시간과 통계 정보를 표시합니다. 최초 의 트레이스를 전송 하는데 사용한 경로도 표시합니다.

-w n
    트레이스의 응답의 대기 시간을 n 초 (디폴트는 3 초)에 세트 합니다.

사용법

  어떻게 동작할까 ?
traceroute 유틸리티로 uni-cast의 네트워크 경로를 트레이스 하기 위해서 사용하고 있다 기법은 IP 멀티 캐스트에서는 동작하지 않습니다. 그것은, ICMP 응답이 멀티 캐스트 트래픽에서는 금지되고 있기 (위해)때문입니다. 그 대신에, 트레이스의 기능은 multicast router에 대해 실장되고 있습니다. 이 기법은 송출하는 패킷수를 최소로 하면서, 패킷 레이트나 로스를 계측 할 수 있는 점으로 우수합니다.

멀티 캐스트에서는 역경로 전송이 사용되고 있기 (위해)때문에, 트레이스는 receiver (으)로부터 source 에 역방향으로 실행됩니다. 트레이스의 문의 패킷은 최종 호프의 multicast router ( receiver 주소에서의 말단 라우터)에 보내집니다. 최종 호프의 라우터에서는 트레이스의 응답 패킷을 생성해, 거기에 그 호프에서의 리포트를 담아, uni-cast를 사용해, 지정되었다 source (으)로부터 보내져 오는 패킷에 있어서의, 그 라우터의 전단의 호프이라고 사원 라우터에, 생성한 패킷을 전송 합니다. 경로상의 각 라우터는 그 패킷에 리포트를 추가해 전송 합니다. 트레이스의 응답 패킷이 최초의 호프의 라우터 ( source 의 네트워크에 직결되고 있는 라우터)에 도달하면(자), 그 라우터는 트레이스의 문의에 지정되어 있는 응답의 발송지 주소에 최종적인 형태의 응답을 보냅니다.

경로상의 몇개의 multicast router에 멀티 캐스트의 트레이스 루트 기능이 실장되어 있지 않기도 하고, 정지하고 있는 것이 있으면(자), 응답반 선. 이 문제를 해결하려면 , 응답이 돌려주어지기까지 트레이스 되는 호프 수를 제한하기 위한 최대 호프수필드를, 트레이스의 문의에 포함하게 합니다. 이것에 의해, 부분적인 경로의 트레이스가 가능해집니다.

각 라우터에 의해 삽입되는 리포트에는, 호프의 주소 뿐만이 아니라, 전송을 위해서(때문에) 필요한 ttl 와 루팅의 에러를 나타내는 몇개의 플래그, 거기에 수신과 송신 인터페이스상 및 지정되었다 group 에 전송 된 패킷수의 합계가 포함됩니다. 시간을 시작되어 2 회 트레이스를 행해 이러한 패킷수의 차분을 취해, 어느 호프로부터의 송신 패킷 수와 그 다음의 호프에서의 수신 패킷수를 비교하는 것으로써, 패킷 레이트와 패킷 소실의 통계를 계산할 수 있어 네트워크에의 과부하에 의한 문제를 절 떼어 놓을 수가 있습니다.

  최종 호프 라우터를 찾아낸다
트레이스의 문의는 source (으)로부터 receiver 에 도달하는 경로상의 마지막 호프인 multicast router에 보내지지 않으면 선. 만약, receiver 가 로컬 서스네트워크상에 있으면 (이것은 subnet mask 에 의해 결정됩니다), 디폴트의 방법에서는 트레이스의 문의 (을)를 ttl 를 1 으로 해 all-routers.mcast.net (224.0. 0.2)에 멀티 캐스트 합니다. receiver 가 서스네트워크상에 없으면, group 에 트레이스의 문의를 멀티 캐스트 합니다. 그것은 receiver 가 그 그룹의 멤버이면, 마지막 호프 라우터도 그룹의 멤버이기 (위해)때문에 입니다. 그 때문에, 의도하고 있는 receiver 가 속하고 있는 그룹을 지정한다 필요가 있습니다. 이 멀티 캐스트는 ttl 를 디폴트의 127 으로 해 보내지고 -t 옵션으로 변경 가능합니다. ) 만약 마지막 호프 라우터를 알고 있으면, -g 옵션을 사용해 직접 지정할 수도 있습니다. 또, 마지막 호프의 라우터가 다른 그룹의 멤버이다고 하는 것을 알고 있어 receiver 가 속 하고 있지 않는 그룹의 트레이스를 행하고 싶은 경우, -g 옵션을 사용해 트레이스의 문의에 다른 멀티 캐스트 주소를 지정할 수도 있습니다.

multi-homed인 호스트나 라우터로부터의 트레이스를 행하는 경우는, 디폴트의 receiver 의 주소는 source 로부터의 경로에서의 의도한 인터페이스 (이)가 아닐지도 모릅니다. 인터페이스를 지정하고 싶은 경우는, receiver 에 의해 명시적으로 지정하지 않으면 안됩니다.

  응답의 유도
-m 옵션에 의해 트레이스 하는 호프수가 명시적으로 지정되어 있는 경우를 제 와, mtrace (은)는 디폴트에서는 우선 역경로 모두에 건넌 트레이스를 시도합니다. 만약 타임 아웃 시간인 3 초 (이것은 -w 옵션으로 변경할 수 있는) 이내에 응답이 없으면,"*" 이 표시되어 프로브 방식을 hop-by-hop 모드로 전환합니다. 트레이스의 문의는 최대 호프수를 1 으로부터 개시해, 응답을 수신하지 않게 된다 인가 모든 경로를 망라할 때까지 호프수를 1 씩 늘려 갑니다. 각 호프에서는, 복수의 프로브 (디폴트에서는 3, -q 옵션으로 변경가능) 하지만 보내집니다. 트레이스의 시도의 전반 (디폴트에서는 2 회)으로는, 응답 주소를 표준의 멀티 캐스트 주소 mtrace.mcast.net (224.0. 1.32)에 세트 해, ttl 를 receiver 까지의 경로상에서 지금까지 있던 최대의 스렛쇼르드 인 32 에 세트 해 행해집니다. 계속하는 각각의 시도에 대해서는 ttl 는 최대 192 까지 32 씩 늘려집니다. 목적의 라우터는 멀티 캐스트 응답을 보내는 것이 할 수 없을 지도 모르기 때문에, 나머지의 시도에서는 mtrace 하지만 동작하고 있는 호스트에 uni-cast를 사용해 응답하는 것을 요구합니다. 또, 멀티 캐스트의 ttl 는 -t 옵션을 사용해 명시적으로 지정할 수가 있어 최초의 멀티 캐스트의 시도는 -U 옵션을 사용해 uni-cast에 강제적으로 변경할 수가 있어 마지막 멀티 캐스트의 시도는 -M 옵션을 사용해 강제적으로 멀티 캐스트로 할 수가 있어 또 -UM (을)를 지정하는 것으로써, mtrace (은)는 처음은 uni-cast로 시도해 다음에 멀티 캐스트를 시도합니다. 각각의 시도로 (은)는 타임 아웃이 될 때까지 응답을 수신할 수 없으면 "*" 이 표시됩니다. 지정되었다 회수의 시도가 실패하면(자), mtrace (은)는 다음의 호프의 라우터에 ( mrinfo 프로그램으로 사용되고 있도록(듯이)) DVMRP_ASK_NEIGHBORS2 요구로 문의 (을)를 시도해 그 라우터의 종류를 조사합니다. mtrace 유틸리티는 응답이 없는 라우터를 넘어 3 호프 (이것은 -e 옵션으로 변경 가능)에, 응답을 돌려주는 능력이 없다고 해도 그 요구의 전송은 할 수 있을 것이다와 상정해, 문의를 시도합니다.

사용예
mtrace 의 출력은 2개의 섹션으로부터 됩니다. 최초의 섹션에서는 호프가 물어 합쳐진 순서, 즉 source (으)로부터 receiver 에의 역순으로 간결하게 리스트 됩니다. 각각의 호프에 대해, 호프 번호 (역경로 인 것을 나타내도록(듯이) 부의 수로 카운트 된다), 멀티 캐스트 routing protocol (DVMRP, MOSPF, PIM 등), 데이터의 전송 (오름새의 화살표로 나타난 리스트에서의 전의 호프에의 전송) 요구의 스렛쇼르드, 문의 하지만 그 호프에 닿을 때까지의 지연의 누적 (클락이 동기 하고 있을 때 마셔 유효) 하지만 1 행으로 표시됩니다. 최초의 섹션의 마지막에는, 문의가 발행함 라고로부터 응답을 수신할 때까지의 간격을 로컬의 시스템 클록으로 계측 했다 왕복 여행 시간과 패킷이 이 경로를 지나 왕래하는데 필요한 ttl 의 합계가 표시됩니다. 이하에 사용법과 그 출력의 예를 나타냅니다.

    oak.isi.edu 80# mtrace -l caraway.lcs.mit.edu 224.2. 0.3
    Mtrace from 18.26. 0.170 to 128.9. 160.100 via group 224.2. 0.3
    Querying full reverse path...
      0  oak.isi.edu (128.9. 160.100)
     -1  cub.isi.edu (128.9. 160.153)  DVMRP  thresh^ 1  3 ms
     -2  la.dart.net (140.173. 128.1)  DVMRP  thresh^ 1  14 ms
     -3  dc.dart.net (140.173. 64.1)  DVMRP  thresh^ 1  50 ms
     -4  bbn.dart.net (140.173. 32.1)  DVMRP  thresh^ 1  63 ms
     -5  mit.dart.net (140.173. 48.2)  DVMRP  thresh^ 1  71 ms
     -6  caraway.lcs.mit.edu (18.26. 0.170)
    Round trip time 124 ms; total ttl of 6 required.

어느 호프가 패킷을 전송 하는데 디폴트의 경로를 사용하고 있는 것을 보 고 하면, [default] 하지만 그 호프의 뒤에 표시됩니다. -v 플래그가 지정되어 있으면, 그 패킷을 전송 하는데 사용된 경로가 [18.26. 0/24] 의 형식에서 표시됩니다.

2 번째의 섹션에서는 전송의 경로가 그림에 의해 표시됩니다. 데이터의 흐름 (은)는 아래로 향한 화살표로 나타내져 문의의 경로는 오름새의 화살표로 나타내집니다. 각 호프에서는, 라우터의 입력 주소와 출력 주소가 차이가 나면, 그러한 주소가, 그 호프 패킷을 전송 하는데 필요한 ttl 의 초기치와 양단의 라우터의 클락이 동기 하고 있으면(자) 상정했을 경우의 호프에 걸쳤다 전반 늦는것과 동시에 표시됩니다. 이 섹션의 오른쪽 반은 2 조의 통계 정보인가 들 구성됩니다. 최초의 컬럼에게는 각 호프에서의 모든 트래픽에 대해 의 평균의 패킷 레이트가 표시됩니다. 나머지의 컬럼에서는 소실한 패킷 의 수, 송신한 패킷의 수, 소실한 퍼센티지, 거기에 평균 패킷 레이트가 각 호프에 대해 표시됩니다. 이러한 통계 정보는 위에서 해설했어 게트레이스간의 차이와 호프간의 차이로부터 계산됩니다. 최초의 그룹에서는, 어느 호프에서의 인터페이스에 있어서의 전유출 트래픽과 다음의 호프에서의 전유입 트래픽의 통계 정보가 표시됩니다. 2 번째의 그룹에서는, 지정되었다 source (으)로부터 지정되었다 group 에의 전송 트래픽에만 붙은 통계 정보가 표시됩니다. 통계의 최초의 그룹은 -T 옵션을 사용해 소실 레이트를 포함하게 할 수도 있습니다. 그러나, 이러한 숫자는 대폭적인 오차를 포함할 가능성이 있어, 이것들을 적절히 해석하기 위해서는 라우터에 대한 상세한 지식이 요구되겠지요.

이러한 통계 정보는 각각의 호프에 대해 1 행이나 2　행으로 표시됩니다. 옵션이 아무것도 지정되어 있지 않으면 이 출력중의 2 번째의 섹션은 최초 의 트레이스로부터 대략 10 초 후에 1 번만 표시됩니다. 각 호프에 대해 1 행에 그 10 초간에서의 통계 정보를 표시합니다. 만약 -l 옵션이 지정되어 있으면(자), 2 번째의 섹션은 10 초 마다 융통반이야 , 각 호프에 대해 2 행이 표시됩니다. 최초의 행에서는 지금까지의 10 초간 에 있어서의 통계가 표시되어 2 번째의 행으로 최초의 트레이스로부터의 누적의 통계 정보 하지만 표시됩니다. 아래의 예에서는 이것은 101 초간에서의 통계가 되고 있습니다. -s 옵션이 지정되는지, 멀티 캐스트 그룹이 지정되어 있으면(자), 와 의 출력에서의 2 번째의 섹션은 생략 됩니다.

    Waiting to accumulate statistics... Results after 101 seconds:
      Source       Response Dest    Overall   Packet Statistics For Traffic From
    18.26. 0.170    128.9. 160.100    Packet    18.26. 0.170 To 224.2. 0.3
         |       __/ rtt  125 ms     Rate     Lost/Sent = Pct  Rate
         v      /    hop   65 ms    -------   ---------------------
    18.26. 0.144
    140.173. 48.2   mit.dart.net
         |     ^     ttl    1         0 pps      0/2  = --%  0 pps
         v     |     hop    8 ms      0 pps      0/18 =  0%  0 pps
    140.173. 48.1
    140.173. 32.1   bbn.dart.net
         |     ^     ttl    2         0 pps      0/2  = --%  0 pps
         v     |     hop   12 ms      0 pps      0/18 =  0%  0 pps
    140.173. 32.2
    140.173. 64.1   dc.dart.net
         |     ^     ttl    3        27 pps      0/2  = --%  0 pps
         v     |     hop   34 ms     26 pps      0/18 =  0%  0 pps
    140.173. 64.2
    140.173. 128.1  la.dart.net
         |     ^     ttl    4        83 pps      0/2  = --%  0 pps
         v     |     hop   11 ms     79 pps      0/18 =  0%  0 pps
    140.173. 128.2
    128.9. 160.153  cub.isi.edu
         |      \__  ttl    5        83 pps      ? /2         0 pps
         v         \ hop   -8 ms     79 pps      ? /18        0 pps
    128.9. 160.100  128.9. 160.100
      Receiver     Query Source

패킷의 카운트수는 트레이스의 문의가 전반함과 함께 변화 째, 통계 정보중에는 작은 오차 (1 이나 2 의 차이)가 포함되는 일이 있습니다. 그러나, 이러한 오차는 누적되어서는 안되기 때문에, 누적 통계행에서는 트레이스가 10 초 마다 실행될 때마다 정밀도가 더하지 않으면 안됩니다. 큰 오차의 요인으로서는 2 개 있어, 이 모두 마이너스의 로스로서 나타납니다.

어느 노드에의 입력 카운트가 다른 노드가 아탓치 되고 있는 멀티 액세스 네트워크로부터의 것이면, 입력 카운트는 아탓치 되고 있는 모든 노드 (으)로부터의 출력 카운트의 총화가 됩니다 (혹은 가깝게 됩니다)가, 트레이스 해 (이)라고 있는 경로상의 그 전의 호프로부터의 출력 카운트는 그 단순한 일부분이 되어 (이)가 됩니다.

SunOS 및 그 외의 시스템에 있어서의 DVMRP 멀티 캐스트 전송 소프트웨어의 릴리스 3.3 에서는, 라우터에 대해 생성된 멀티 캐스트 패킷 (은)는 인터페이스에 입력되어 있지 않은 경우에 대해도, 입력된 것으로 해 (이)라고 카운트 됩니다. 이것은 위의 예에 대해 볼 수 있는 마이너스의 로스 됩니다.

이러한 마이너스의 로스는 플러스의 로스를 숨겨 버리는 것이 있는 것에 주의해 주세요.

이 예에서는 또, 1 개(살) 마이너스의 호프의 시간이 표시되고 있습니다. 이것은 단지 그 호프간에서의 시스템 클록이 동기 하고 있지 않는 것을 나타내고 있습니다. 이 예에서는 또, 보내진 패킷의 수가 10 보다 적을 때로는, 퍼센티지의 값은 통계적으로 유효하지 않기 때문에, 로스의 퍼센티지가 2 개의 데쉬 (으)로서 표시되는 일도 가리키고 있습니다.

2 번째의 예에서는 로컬이 아닌 receiver 에의 트레이스를 나타냅니다. 물음합 조생은 -g 옵션에 의해 최종 호프의 라우터에 보내집니다. 이 예에서는, 전역경로 의 트레이스가, 멀티 캐스트 트레이스 루트 기능이 실장되어 있지 않다 낡은 버젼의 mrouted 하지만 동작하고 있는 노드가 있기 위해서(때문에) 응답 없음의 결과가 되고 있어 그 때문에 mtrace (은)는 hop-by-hop 모드에 바뀌고 있습니다. “Output pruned” 의 에러 코드는 그룹 224.2. 143.24 에의 트래픽이 전송되어 있지 않은 것을 나타내고 있습니다.

    oak.isi.edu 108# mtrace -g 140.173. 48.2 204.62. 246.73 \
                               butter.lcs.mit.edu 224.2. 143.24
    Mtrace from 204.62. 246.73 to 18.26. 0.151 via group 224.2. 143.24
    Querying full reverse path... * switching to hop-by-hop:
      0  butter.lcs.mit.edu (18.26. 0.151)
     -1  jam.lcs.mit.edu (18.26. 0.144)  DVMRP  thresh^ 1  33 ms  Output pruned
     -2  bbn.dart.net (140.173. 48.1)  DVMRP  thresh^ 1  36 ms
     -3  dc.dart.net (140.173. 32.2)  DVMRP  thresh^ 1  44 ms
     -4  darpa.dart.net (140.173. 240.2)  DVMRP  thresh^ 16  47 ms
     -5  * * * noc.hpc.org (192.187. 8.2) [mrouted 2.2] didn't respond
    Round trip time 95 ms

저자
-nosplit Ajit Thyagarajan 에 의해 쓰여진 최초의 prototype를 베이스로 해, Steve Casner 에 의해 실장되었습니다. 멀티 캐스트 트레이스 루트의 메카니즘은 Steve Casner, Steve Deering, Dino Farinacci, Deb Agrawal 의 도움을 얻어, Van Jacobson 에 의해 설계되어 Ajit Thyagarajan (와)과 Bill Fenner 에 의해 mrouted 에 실장되었습니다. 옵션의 구문과 mtrace 의 출력 형식은, Van Jacobson 에 의해 쓰여진 uni-cast의 traceroute (을)를 모델로 하고 있습니다.

관련 항목
map-mbone(8), mrinfo(8), mrouted(8), traceroute(8)

버그
수동 모드에서의 통계 수집은, 능동적으로 데이터를 수집하고 있을 때와 항상 같다 출력은 되지 않습니다.