ОС linux, ядро 2.6.34.7

Все данные E1 читаются из одного порта:
cronyx.restart
grep -q "^craw " /proc/modules || insmod /lib/modules/`uname -r`/cronyx/craw.ko
sconfig tau32_0 clock=receive
sconfig tau32_0.e1_0 cas=off
sconfig ce0 ts=1-15,17-31 mode=phony mtu=1200 raw qlen=3
sconfig ce1 ts=16 mode=hdlc mtu=260 raw qlen=3

Проверка на возможность чтения осуществляется с помощью функции select:
fd_set fs;
struct timeval tv;

FD_ZERO(&fs);
FD_SET(port__, &fs);
tv.tv_sec=sec_;
tv.tv_usec=usec_;
return select(port__+1,
read_ ? &fs : NULL,
read_ ? NULL : &fs,
NULL, &tv) == 1;

Данные читаются блоками по 30*160 байт:
30 - количество таймслотов
160 - размер буфера

Чтение осуществляется до попытки прочитать один буфер (т.е. если пришло меньше пытаемся прочитать еще):
int l=cronyx__.readb(r__+r_l__, 30*160-r_l__);

В результате, получается, что в течении одной минуты накапливается задержка порядка 11,5 мс. Причем по истечении первых 100 буферов, задержка накопилась порядка 200мкс, т.е. где-то 2мкс/буфер, а средняя за одну минуту: 3,8мкс, т.е., вроде как, возрастает.

Понятно, что система linux и точность приблизительная. В течении одной минуты произошло 3000 отсчетов, и все они имеют указанный характер (с соответсвующими выплесками в результате латентности, максимальное отклонение составило чуть более 200мкс).

Могу предоставить для изучения файл отсчетов времени.

Собственно сами вопросы: эта задержка может накапливаться в плате или искать ошибку у себя? если в плате, то можно как-то ее избежать?