Mining Latency

풀은 페트르의 작업을 준비해 채굴 소프트웨어로 보냅니다. 소프트웨어는 중간 전달자인 프록시를 거쳐 채굴 전용 칩인 ASIC에 메시지를 넘길 수도 있습니다. 중요한 것은 컴퓨터에 메시지가 도착한 시점이 아니라 실제로 새 작업으로 전환한 시점입니다. 장비는 이후 풀에 작업을 증명하는 부분 계산 결과인 shares를 제출합니다. 채굴 기기의 통신 프로토콜인 Stratum V2의 channel_id와 job_id는 메시지를 올바른 채널과 작업에 연결합니다. 이 대응이 없으면 한 작업의 시작과 다른 작업의 끝을 함께 측정할 수 있습니다. [1]

페트르는 Braiins의 진단 안내에 따라 ping을 실행합니다. 서버가 응답하는지, 요청이 갔다가 답이 돌아오는 데 얼마나 걸리는지 확인하는 것입니다. 이 왕복 시간이 RTT, 즉 round-trip time입니다. 유용한 첫 단계지만 두 방향의 경로나 대기열은 다를 수 있습니다. 따라서 단순히 둘로 나눈 값은 편도 지연의 측정값이 아닙니다. Ping은 풀이 작업을 준비하거나 ASIC이 계산을 시작하는 시간도 보여 주지 않습니다. 좋은 수치와 느린 작업 전환은 함께 나타날 수 있습니다. [2] [3]

여기서 든 예에서는 송신자가 Tsend = 1000 ms, 수신자가 Trecv = 1040 ms를 기록합니다. 차이는 40 ms이지만 수신자 시계가 30 ms 앞서 있을 수 있습니다. 그렇다면 단순한 뺄셈은 실제 전송 시간이 아닙니다. ms는 밀리초, 즉 천분의 일 초를 뜻합니다. 네트워크 측정 표준인 RFC7679가 시계 동기화의 불확실성과 타임스탬프를 찍는 위치를 고려하는 이유입니다. 이런 정보가 없으면 서버 간 차이가 속도 개선을 입증하지 못합니다. 시계 설정이 다른 것뿐일 수도 있습니다. [3]

새 블록 뒤에 작업 전체를 기다리지 않도록 Stratum V2는 Future Job을 미리 보낼 수 있게 합니다. 이는 미래의 체인 연결에 대비한 작업이지 즉시 시작하라는 명령이 아닙니다. SetNewPrevHash가 올바른 이전 블록 참조와 일치하는 job_id로 활성화합니다. 준비한 작업에 거래가 포함돼 있다면 새 블록이 같은 거래를 이미 포함하는 등의 이유로 일부 거래를 다시 사용할 수 없게 될 수 있습니다. 지연을 줄이려는 목적이 이런 충돌을 무시할 근거는 아닙니다. 잘못된 작업을 빨리 시작하는 것은 유용한 시간 절약이 아닙니다. [1]

페트르는 share가 나간 것을 보지만 확인은 나중에 받습니다. Stratum V2의 SubmitShares.Success는 받아들인 여러 shares를 한 번에 요약할 수 있습니다. 의도적으로 묶어서 메시지 양을 줄이는 것입니다. 따라서 기다린 시간 전체를 전송 지연으로 보거나 풀이 그동안 결과를 몰랐다고 단정할 수 없습니다. SubmitShares.Error도 추가 검증 뒤에 올 수 있습니다. sequence_number는 응답과 제출 결과를 연결하는 데 도움이 됩니다. 문제를 찾을 때는 수신, 검사, 통지를 구분해야 합니다. [1]

채굴은 누군가 블록을 공개했다는 사실도 빨리 알아야 합니다. 이는 장비와 풀의 연결과는 다른 단계입니다. BIP152는 노드 사이에 보내는 데이터를 줄입니다. high-bandwidth 모드에서는 노드가 블록의 압축된 설명인 cmpctblock을 바로 보낼 수 있습니다. 수신자는 자체 데이터로 대부분의 거래를 채우고, 빠진 거래를 getblocktxn으로 요청해 blocktxn으로 받습니다. 이 과정에서 추가 교환이 필요할 수 있습니다. 데이터가 적다고 대기가 사라지는 것은 아니며, 블록의 모든 규칙을 확인하는 완전한 검증도 대신하지 못합니다. [4]

페트르는 평소 동작뿐 아니라 가끔 멈칫하는 순간도 알고 싶습니다. p50/p95는 백분위수로, 하나의 평균 대신 측정 시간 분포의 서로 다른 부분을 보여 줍니다. 시간을 짧은 순서대로 나열하면 p50은 대략 가운데, p95는 느린 쪽 끝에 가까운 값입니다. 약 50%의 값이 첫 번째 경곗값보다 작고, 95%가 두 번째 경곗값보다 작습니다. 이를 통해 평소의 대기와 긴 지연을 구분할 수 있습니다. 다만 도착하지 않은 메시지를 어떻게 처리했는지 밝혀야 합니다. RFC7679는 대기 한계 Tmax를 사용하며, 이를 넘은 경우는 보통의 빠른 측정값이 아닙니다. 이 규격의 백분위수 계산에서는 정의되지 않은 지연을 무한대로 놓고 정렬합니다. 이를 알리지 않고 빼면 보고서만 좋아집니다. 빈 표본도 지연이 영이라는 뜻이 아니라 판단할 데이터가 없다는 뜻입니다. [3]

페트르는 같은 단계를 비슷한 부하에서 같은 길이의 기간 동안 비교합니다. ms 단위의 측정마다 타임스탬프 위치, 시계의 불확실성, 해당 job_id를 기록하고 ping과 RTT는 별도로 둡니다. 빠른 평균에 불안정성이 가려지지 않도록 중단과 거절된 결과도 더합니다. 그러면 다른 서버나 네트워크, 장비 설정이 도움이 될지 조사할 수 있습니다. 목적은 오래된 작업에 쓰는 시간을 줄이는 것이지 블록 발견을 약속하는 것이 아닙니다. 낮은 지연은 채굴의 무작위성이나 유효성 규칙을 바꾸지 않습니다. [1] [2] [3]