Mining Latency는 작업 배포나 활성화, 발견한 share 전달, 후보 블록 전파 같은 특정 채굴 단계의 시간 지연입니다. 값에는 측정의 양 끝 사건과 관측 조건이 명시되어야 합니다.
Stratum V2는 작업 배포와 결과 제출을 구분합니다. 작업을 보낸 뒤 수신할 때까지의 시간은 수신 후 ASIC이 실제 전환할 때까지의 시간과 다릅니다. share가 풀로 돌아오는 것은 또 다른 경로입니다. 양 끝 사건을 정의하고 channel_id와 job_id로 기록을 연결합니다. [Stratum V2 — Mining Protocol]
Braiins는 ping을 도달 가능성 검사로 설명합니다. RTT는 왕복 경로를 포함하므로, 방향이 비대칭일 수 있는 상황에서 단순히 반으로 나눈 값은 단방향 지연 측정치가 아닙니다. Ping은 작업 생성, 프록시 대기열, 장치 활성화도 측정하지 않습니다. 같은 트래픽 유형과 종단점을 비교해야 합니다. [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
RFC7679는 단방향 측정에서 시계 동기화와 타임스탬프 위치를 고려하도록 요구합니다. 예를 들어 Tsend = 1000 ms, Trecv = 1040 ms가 40 ms를 뜻하는 것은 시계를 비교할 수 있을 때뿐입니다. 수신 시계의 30 ms 오프셋은 해석을 바꿉니다. 불확실성 추정이 없으면 서버 간 차이는 속도 향상을 입증하지 못합니다. [RFC7679 — One-Way Delay Metric]
Stratum V2에서는 Future Job이 미리 도착하고, job_id가 일치하는 SetNewPrevHash가 이를 활성화할 수 있습니다. 따라서 템플릿 다운로드뿐 아니라 활성화 지연도 측정합니다. 비어 있지 않은 사전 작업에는 새 블록에 이미 포함된 거래가 있을 수 있습니다. 빠른 배포가 충돌 무시나 무효 블록 채굴을 정당화하지는 않습니다. [Stratum V2 — Mining Protocol]
Stratum V2는 일괄 SubmitShares.Success를 허용합니다. 응답 대기에는 의도적인 묶음 처리가 포함될 수 있으므로 순수한 네트워크 시간도, share가 그동안 계속 수락을 기다렸다는 증거도 아닙니다. SubmitShares.Error는 지연된 검증 뒤에 올 수 있습니다. sequence_number를 연결하고 송신, 수신, 검증, 확인 응답을 나눕니다. [Stratum V2 — Mining Protocol]
high-bandwidth 모드의 BIP152는 사전 요청 없이 cmpctblock을 보냅니다. 수신자에게 거래가 부족하면 getblocktxn과 blocktxn이 교환을 추가합니다. 이는 노드 간 블록 전파이지 share 제출 측정이 아닙니다. 전송 데이터 감소가 지연 0을 보장하거나 완전한 검증을 대신하지는 않습니다. [BIP152 — Compact Block Relay]
RFC7679는 시간 한도 Tmax를 정하고 미전달 패킷의 지연을 미정으로 취급합니다. 해당 백분위 계산에서는 이런 값을 무한히 큰 값으로 정렬합니다. 자체 p50/p95에는 방법, 표본 수, 손실을 명시해야 합니다. 모든 타임아웃을 제외하면 결과가 좋아 보일 수 있으며, 빈 표본은 지연 0이 아닙니다. [RFC7679 — One-Way Delay Metric]
경로나 설정을 바꿀 때 장치, 시간 구간, 측정 정의를 비교 가능하게 유지합니다. job_id 활성화, 작업 확인, 거절 이유, 중단을 따로 추적하고 ping RTT 감소를 모든 지연 감소의 증거로 혼동하지 마세요. 이는 비교 방법이지 블록 발견 약속이나 ms 단위의 보편적 안전 기준이 아닙니다. [Stratum V2 — Mining Protocol] [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Stale Rate, Block propagation, Stratum V2, Mining Pool. 다음 항목에서도 이 글을 참조합니다 Stale Rate.