고객 중 한 명이 스트리밍 응용 프로그램 (win32)에 문제가 있습니다. UDP (RTP) 패킷은 일정한 간격 (예 : 20ms)으로 애플리케이션에서 전송해야하며 실제로는 매우 가변적 인 델타 (15ms - 25ms - 10ms - 30ms)로 전송됩니다. 이것은 네트워크 카드 나 다른 OS 네트워크 관련 인프라가 우리의 근본 용의자이기 때문에 문제가 발생한 유일한 고객입니다.NIC, NIC 성능 측정에 의한 일관되지 않은 패킷 전달
문제는 (?,? AV를 QOS) 네트워크 구성의 종류는 문제를 초래할 수있다 무엇
이며 어떻게 내가 실제로 "보내기"기능과 패킷이 실제로 전달 된 순간 호출 사이의 시간을 측정 할 수 있습니다 네트워크? 사용할 수있는 도구가 있습니까?
사람들은 실제로 Windows의 타이밍 기능이 실제로 Sleep()이 15 밀리 초 이상의 해상도를 가질 수 있음을 알게되었습니다. 프로그래밍 방식으로 1ms로 설정하지 않는 한 그래서 NIC와는 전혀 관계가 없습니다.
나는 인 것으로 의심됩니다. 네트워크 문제로 인해이 문제가 발생할 수 있습니다.
기본 UDP를 사용하는 QoS (서비스 품질)에 대한 개념이 없습니다 (패킷을 잃어 버릴 수도 있고, 중복 된 패킷이있을 수도 있습니다). 네트워크 카드는 네트워크에 쓸 패킷을 대기열에 넣어야하므로 다른 응용 프로그램의 패킷을 대기열에 넣기 때문에 배달을 보장 할 수 없습니다.
라우터도 우선 순위를 지정할 수 있으며 이러한 패킷의 규칙성에 영향을줍니다.
EDIT : 로컬 NIC를 지적 했으므로 위의 내용을 참조하십시오. 이 상황에서는 라우터가 적용되지 않습니다.
간단히 말해 위 내용이 허용 가능한 것 이외의 다른 것으로 기대할 이유가 전혀 없습니다.
실제 패킷을 생성하는 컴퓨터의 NIC에서이 값을 직접 측정하는 경우 (즉, 모든 네트워크 영향을 할인 할 수있는 경우) 가능한 원인은 컴퓨터 자체의 부하입니다.
컴퓨터에서 실행되는 많은 응용 프로그램, 특히 대화 형 응용 프로그램과 사용자 상호 작용 편향성이 강한 응용 프로그램 (대부분의 스케줄러에서 우선 순위를 갖는 경향이있는 응용 프로그램)이있는 경우 메시지를 만드는 응용 프로그램이 단순히 컴퓨터를 찾는 것일 수 있습니다 필요한 시간 동안 경쟁하기가 어렵습니다.
모든 고객 컴퓨터에 동일한 소프트웨어가로드되어 있어도 실제로 실행중인 응용 프로그램과 수행중인 응용 프로그램에 영향을 미칠 수 있습니다.
문제가 발생한 고객은이 고객뿐입니다. 아무도 완벽한 타이밍에 대해서는 말하지 않지만,이 고객과의 패킷 전송 시간의 변동은 일반적인 관찰 범위를 넘어선 것입니다. – Boris
로컬 NIC 캡처로 인해 라우터 또는 네트워킹 문제가 발생하지 않도록주의하십시오. – Boris