OpenBSD에 포팅하는 이상한 취미가 있습니다. 나는 pthreads 문제가 있음을 알고 있지만, 2013 년 5 월에 출시 될 때까지는 업그레이드하지 않을 것입니다. 5.0을 사용하고 있으며 pthreads에 상당히 익숙합니다. 나는 1 튜토리얼을 훑어보고, 그것을 필요로하는 내 프로그램에 추가했다.OpenBSD에서 pthread priority/scheduling
프로젝트는에서 rtl_fm.c입니다. $ 20 동글을 가지고 USB 포트에 연결하고 소프트웨어 정의 라디오로 24 - 1700 MHz를 조정하십시오. 나는 같은 컴퓨터를 OpenBSD, 오래된 데비안 리눅스 및 Windows XP로 부팅하여 비교할 수 있습니다. OpenBSD에서 거의 작동하며 Linux에서 작동합니다. 한 파티션에서 다른 파티션으로 동일한 코드를 복사하고 다른 OS로 재부팅 할 수 있습니다. 제가 일하고있는 버전은 여분의 printfs를 추가했기 때문에 적어도 조금은 진행 상황을 볼 수 있습니다. OpenBSD는 복조 스레드에서 우선 순위가 더 필요합니다. 내 printfs와
리눅스에서 내가
demod_thread_fn: doing sem_wait(&data_ready) rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data_ready was off, posting on demod_thread_fn: past sem_wait demod_thread_fn: calling full_demod full_demod: about to rotate_90 full_demod: after rotate_90 full_demod wrote 384 bytes
설명을 참조, 추가 : demod_thread_fn는 복조 스레드에 할당 된 주요 기능, 그것은 data_ready라는 세마포어에 sem_wait을 수행하여 시작합니다. rtlsdr_callback은 하위 수준 장치 드라이버에서 복조 할 데이터가있을 때 호출됩니다. 여기서는 data_ready 세마포어에 대해 sem_post를 수행합니다. demod_thread_fn은 변경 내용을보고 full_demod를 호출하고 나머지는 정상이며 파일에 데이터를 쓰는 것으로 끝납니다. 데이터의 약 6 개 배치가 그리고 마지막 하나가 복조됩니다 (모든 손실되는)에 올 때까지
demod_thread_fn: doing sem_wait(&data_ready) rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data_ready was off, posting on rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes demod_thread_fn: past sem_wait demod_thread_fn: calling full_demod full_demod: about to rotate_90 full_demod: after rotate_90 full_demod wrote 386 bytesdata_ready에 sem_post가 발견되지 않습니다 은 오픈 BSD에서 나는이를 참조하십시오. 그 결과는 이해할 수 없습니다. printfs가 추가 된 수정 된 코드 is here.
내 질문은 어떻게 그리고/또는 OpenBSD에서 demod 스레드의 우선 순위를 높일 수 있는지입니다. 이것이 OpenBSD의 pthreads 구현의 결함 중 하나입니까? 나는 방금 pthread_attr_setschedpolicy()를 사용하기 시작했으나 sched_get_priority_max()에 대한 맨 페이지의 끝에 "이 구현은 프로세스 스케줄링을 지원하지 않습니다."라고 말합니다. 그게 내가 운이 없다는 뜻인가? 나는 전체 프로세스를 변경하려고하지 않고 스레드 하나만 변경하려고합니다.
앨런
난 당신이 여기에 대답하는 거 야 방법을 잘 모르겠어요, 난 문자 수 제한에 달렸다.
저는 동의하는 경향이 있습니다. 또는 적어도 버퍼는 처리 될 때까지 추가되도록 고정 된 크기가되어서는 안됩니다. 그것은 어떤 이유로 리눅스에서 잘 작동합니다. 이 작업은 초 당 최대 2 메가 샘플을 처리하며, 각 버퍼 풀은 약 16k이며 처리가 완료되면 약 400 바이트의 오디오가됩니다. 나는 그것을 완전히 이해하지 못하지만, 2 MHz 스펙트럼의 모든 대화를 녹음하고 포착하여 나중에 원하는 것을 복조하는 것이 가능합니다. 하지만 리눅스에서는 FM 방송국에서 실시간 오디오를들을 수 있습니다. [email protected]에 다시 등록하여 질문하십시오.
우선 순위를 변경하면서 조금 실험했지만 루트 권한으로도 우선 순위 번호를 올릴 수는 있지만 낮추지는 않습니다. Windows에서도 컴파일되어 실행됩니다. OpenBSD에서 왜 작동하지 않는지 알아낼 수 있다면 주류 코드에 몇 가지 ifdef를 줄 수는 있지만 필자는 OpenBSD를 수용하기 위해 거꾸로 굽히지 않을 것이라고 생각합니다. 그것은 모두 새롭고 매우 빠르게 움직입니다.
우선 순위 - 트위 더링으로 처리해야 할 문제보다 드라이버 인터페이스가 좋지 않은 것처럼 보입니다. 드라이버가 버퍼를 채우고 세마포어에 신호를 보내서 버퍼 처리 스레드를 준비 시키면 실행될 때마다 별도의 버퍼 인스턴스로로드되어야합니다. 그렇지 않으면 데이터를 덮어 쓸 가능성이 높습니다. 우선 순위가 아닌 디자인 수정이 필요합니다. –
나는 동의하는 경향이있다. 또는 최소한 버퍼는 고정 크기가되어서 처리 될 때까지 추가된다. 그것은 어떤 이유로 리눅스에서 잘 작동합니다. 이 작업은 초 당 최대 2 메가 샘플을 처리하며, 각 버퍼 풀은 약 16k이며 처리가 완료되면 약 400 바이트의 오디오가됩니다. 나는 그것을 완전히 이해하지 못하지만, 2 MHz 스펙트럼의 모든 대화를 녹음하고 포착하여 나중에 원하는 것을 복조하는 것이 가능합니다. 하지만 리눅스에서는 FM 방송국에서 실시간 오디오를들을 수 있습니다. [email protected]에 다시 등록하여 질문하십시오. – ab1jx