Есть плата SK-AT91SAM9G45 с кодеком AC97. Нужно считывать звук (pcm S16_LE) с микрофона и писать звук в аудио-выход (т.е. дуплекс). При использовании частоты 48 кГц все работает нормально. Если указать другую частоту (необходимы другие, меньшие частоты, например, 8 кГц), то возникают проблемы с воспроизведением (playback) звука. Создается впечатление, что на вход звук идет с нужной частотой, а на выход 48 кГц, не зависимо от выставленной частоты.
Такая же проблема возникает, если вместо моей программы использовать «стандартные» arecord и aplay. Т.е. при 48000 Гц все нормально, а при 8000 Гц в stdout пишутся строки underrun!!!
(Пример запуска arecord -r 8000 -f S16_LE | aplay -r 8000 -f S16_LE)
Версия библиотеки alsa 1.0.24.1
Версия ядра 3.2.23
dmesg пишет про аудио
atmel_ac97c atmel_ac97c.0: Atmel AC97 Controller at 0xc4830000, irq = 24

В своей программе я пытаюсь установить частоту 8 кГц через snd_pcm_set_params (например, snd_pcm_set_params(playback, SND_PCM_FORMAT_S16_LE, SND_PCM_ACCESS_RW_INTERLEAVED, 1, 8000, 1, 25000). Функция отрабатывает успешно.
snd_pcm_dump выдает среди прочего
exact rate : 8000 (8000/1)

Функция tcp_mtu_probe в начале своей работы проводит ряд проверок: не используется ли SACK, не восстанавливаемся ли после перегрузки и т.д. Вот соответствующий кусок кода:

/* Not currently probing/verifying,
	 * not in recovery,
	 * have enough cwnd, and
	 * not SACKing (the variable headers throw things off) */
	if (!icsk->icsk_mtup.enabled ||
	    icsk->icsk_mtup.probe_size ||
	    inet_csk(sk)->icsk_ca_state != TCP_CA_Open ||
	    tp->snd_cwnd < 11 ||
	    tp->rx_opt.num_sacks || tp->rx_opt.dsack)
		return -1;

Как устроена ретрансмиссия tcp сегментов в ядре (tcp/ipv4)? Ткните, пожалуйста, в соответствующие функциии.
Т.е. сегмент отправляется, ждем ACK, не дожидаемся и отправляем еще раз. Интересует ожидание и повторная отправка.
Формируется ли при ретрансмиссии заново tcp заголовок? По идее вроде должен (например, наш ACK мог измениться за время ожидания). Какие функции при этом вызываются? те же, что и при первоначальном формировании заголовка?

Есть приложение на С++, которое использует стороннюю библиотеку. Специфика работы библиотеки такова, что в процессе работы может понадобиться большое количество потоков (300-500). При этом библиотека не устанавливает размер стека при создании потока (pthread).
Проблема в том, что в системе, на которой будет работать мое приложение ulimit -s равен 8192, поэтому процесс не может создать более 255 потоков.
Попытки использовать setrlimit в main() бесполезны, т.к. NPTL смотрит RLIMIT_STACK до передачи управления в main при инициализации программы.
Сейчас решаю проблему запуском скрипта (допустим, run.sh) из двух строчек:
ulimit -s 1024
запуск приложения

Может это как-то повлиять на лимиты для других процессов? Есть ли способ программно изменить размер стека по умолчанию для моей программы или какое-нибудь другое решение, более изящное, чем run.sh?

Как измерить в kernel space интервалы времени по возможности наиболее точно?
Интересует реальное время (wall clock).
Необходимо измерять в ядре время между пришедшими TCP пакетами.
Нашел функции getrawmonotonic и getnstimeofday. Подойдут ли они для данной задачи, и в чем между ними разница?
Я так понимаю, что для x86 они по сути обертка вокруг rdtsc. Т.е. мне нужно привязать код к одному ядру процессора (так как tsc могут быть не синхронизированы между ядрами) и надеяться, что тактовая частота ядра будет неизменна во время его работы?
Будет также здорово, если кто-нибудь расскажет (или поделится ссылкой), как реализованы эти функции на не x86 архитектурах.