Experimental Physics and
Industrial Control System

 >> I [...] somehow got around it by setting ReadTimeOut and
 >> PollPeriod to half of the input rate:
 >> rdInputCont{
 >>     ReadTimeout = 10;
 >>     PollPeriod = 10;
 >>     in "%#s";
 >> }

Interesting. PollPeriod defines how often "I/O intr" records poll for
input if no other records read input. It defaults to ReadTimeout btw.

So if poll period is too long, some input may pile up and only gets
consumed when the next record reads input or flushes input before
writing. The default ReadTimeout and thus PollPeriod is 100 ms. Thus in
your case up to 6 input messages may be pending in this time. More if
processing the messages takes considerable time. That does not look too
much to me. So I still wonder why the input queue never gets empty.

Having a PollPeriod about half the expected input rate is definitely a
good idea, because it reduces latency (at the cost of CPU usage of
course). Otherwise you will see input in bursts.