Re: select() timeout

[Jukka Marin <jmarin%embedtronics.fi@localhost>]

On Fri, Feb 03, 2012 at 05:22:20PM +0100, Johnny Billquist wrote:
> On 2012-02-03 13.08, Jukka Marin wrote:
> >So, are short timeouts reliable with select()?
> 
> What do you mean by "realiable"?
> 
> I'd say they are probably not in any way ideal for doing time keeping. 
> The time that you will wait is sortof heuristic.
> The specified time is said to be a "max", but the time might get rounded 
> to the next clock tick. You might also get more delay since scheduling 
> might actually means it takes even more time before you actually 
> execute. And select does not report back how long you actually slept. 
> There is a whole bunch of issues that can become relevant if you 
> actually start having hard constraints on the timing. Unix systems in 
> general are not realtime. And depending on how you want to use the 
> timeouts, you might have to think a little to actually get things right.

And Christos said:

> You should be using pollts() instead. 

Well, I changed my code to use poll() and I'm still getting way too long
timeouts, probably because the millisecond values are rounded up to next
clock tick (10 ms).

What I'm doing is talking to modbus devices over an RS485 bus. First I
transmit a command to a device and then wait for a reply.  When waiting for
the first byte of reply, I set poll() timeout to 50 ms and when waiting
for the consecutive bytes, I have tried setting timeout to 2 ... 10 ms
with little or no effect on speed.  (The end of message is detected when
receive times out because the lowest level function does not know how many
bytes to expect.)

The protocol works just fine, but the timeout detection is too slow which
means I waste lots of time before sending out the next command to another
device.  The command transmission takes 4.6 ms, then the device waits for
2.6 ms before sending a reply which takes another 4.6 ms.  I can't affect
these times.  But, after the reply message ends, the NetBSD code wastes
18.2 ms before sending out the next command, so most of the time the RS485
sits idle.  Only one transaction is done in exactly 30 ms, so it seems
the timeout is definately rounded up to a 10 ms boundary - maybe even more.

The code between the commands is pretty simple and system load is close
to zero (CPU is 100% idle), so the delays are not caused by my code or
scheduling.

I guess I should try forcing the timer tick to 1ooo Hz, maybe I can cut
off the extra delay that way.  (I'm running a generic 5.1 kernel on Soekris
net5501.)

  Jukka