Unix 도메인 소켓 : 대기 시간을 일정하게 유지

문제 요약 : AF_UNIX 안정적인 송신, 버스트 수신.Unix 도메인 소켓 : 대기 시간을 일정하게 유지

유닉스 도메인 데이터 그램 소켓을 통해 데이터를받는 응용 프로그램 B가 있습니다. 거기에 데이터를 보내는 피어 응용 프로그램 A가 있습니다. A와 B는 둘 다 지속적으로 실행됩니다 (SCHED_FIFO 임). 내 신청서 A는 접수 시간도 인쇄합니다.

피어 응용 프로그램 B는 다양한 시간 (밀리 초 단위로 변함)으로 데이터를 보낼 수 있습니다. 패킷 전송 지연이 수신 지연과 정확하게 일치해야하는 것이 이상적입니다. 예 :

A sends in time   : 5ms  10ms  15ms  21ms 30ms 36ms 
B should receive in time : 5+x ms 10+x ms 15+x ms 21+x ms ...

여기서 x는 상수 지연입니다.

하지만 실험 때 제가 B에서 관찰하는 것은 :

A sends in time   : 5ms  10ms  15ms  21ms 30ms 36ms 
B received in time   : 5+w ms 10+x ms 15+y ms 21+z ms ...

(w, x, y, z는 서로 다른 지연 상수이다). 그래서 나는 보내는 시간이 주어질 때 수신 시간을 예측할 수 없다.)

일부 버퍼링이 유닉스 도메인 소켓에 포함 되었기 때문에 그렇습니까? 수신 시간이 보내기 시간을 예측할 수 있도록 문제에 대한 해결 방법을 제안하십시오. 1 밀리 초의 정확도가 필요합니다. 사용할 수있는 데이터 그램이없는 경우 (I 바닐라 리눅스 3.0 커널을 사용하고 있습니다)

는

출처

2013-06-27 Lunar Mushrooms

참고 : 하나의 조정할 수있는 매개 변수/proc/sys/net/unix/max_dgram_qlen이 있는데,이 매개 변수는 1로 설정할 수 있습니다.하지만 여전히 문제가 있습니다. 지연 스케줄링 일 수도 있습니다. –

UDP 또는 Unix 도메인 소켓입니까? 둘 다있을 수는 없습니다. 또한 1 밀리 초의 정확도가 필요한 이유는 무엇입니까? 실현 가능하지 않다면 어떨까요? recv()가 차단되었거나 차단되지 않았습니까? –

@John 나는 AF_UNIX와 SOCK_DGRAM을 모두 의미했습니다. –

당신이 차단 RECV()를 사용하는 것처럼, 프로그램은 예정되지 않은 것입니다. 이것은 유스 케이스에 좋지 않다 - 당신은 당신의 프로그램이 뜨거워지기를 원한다. 따라서 recv()를 비 블로킹으로 만들고, 바쁜 대기로 EAGAIN을 처리하십시오. 이것은 하나의 코어의 100 %를 소비하지만 목표를 달성하는 데 도움이 될 것입니다.

출처

2013-06-27 13:24:49

은 후보 아이디어 중 하나입니다. 하지만 내 CPU를 바쁘게 할 수는 없어 .-- ( –

높은 정확도, 낮은 대기 시간을 원하지만 CPU를 계속 사용하지 못하게하려면 행운을 빈다. :) –

Thanks John :-). 하지만 한번 시도해 보도록하겠습니다. –

Unix 도메인 소켓 : 대기 시간을 일정하게 유지

답변

관련 문제