Hi all!
Wondering what difference (as far as realtime behavior is concerned) there is between a POSIX interface resmgr vs a devctl interface resmgr. I like the posix interface for it allows to test the whole resmgr without writing a single line of code. But is the devctl interface better suited to realtime applications?
Thanks!
There is very little different (if any at all ) between a read/write and a devctl (if that is what you are asking) the amount of code involved is very similar. What really kills performance are open, that has to be done in either case.
As a matter of fact the whole resmgr structure adds overhead over send/receive/reply, still I would use it given the extra flexibility. I would only use S/R/R in case of very high transaction rate.
Where does “very high transaction rate” begin? The client app control loop will be as follow: read 6 analog values from /dev/Analog/IN(1 through 6), read 3 position values from /dev/Position/Axe(1-2-3) and finally write 3 analog values to /dev/Analog/Out(1-2-3). Of course, all the fd’s involved are obtained before entering the control loop. The goal is to make the loop run at 1kHz. Does this sound like “high transaction rate” to your experience? Any way to figure out the limits?
Though question because it depends on lots of factor, CPU speed, what other task you need to perform etc. How long each operation takes.
If you do 1000 operation a sec and each operation takes .9 ms, you need to be concerned
In your case that’s 12 operation * 1K so it’s roughly 12000 messages per seconds. let say it takes 50 us just for handling the resmgr stuff, that means 60% of the CPU is used to handle the resmgr+messaging overhead. You need to measure how long a transaction takes. Build a very small resmgr that supports read, have the read callback return a fix string, and measure the time the read() takes in the client. That will tell you about the overhead on your perticular hardware.
There is only one safe way to answer your question and it’s to bench mark it
Thanks, I’ll post my results along with machine description.
Another way to do this would be to have the client register to the resmgr and provide a Event to be generated automaticaly every 1ms. The event could be a pulse along with the read data. Hence the resgrm would poll the hardware every 1ms and deliver the event (which is async) to the client automaticaly.
In addition to /dev/Position/Axe(1-2-3) the resmgr could support /dev/Position/AxeAll when in one read you get the 3 values. Same for Analog In and Out. That would reduce number of messages from 12k per sec to 3k per sec.
You could eliminate the high transaction rate altogether by building the servo code into the driver. And have a much higher level of commands/data flow at the devctrl level.
Personaly I like to make driver as dump as possible, I would not put zmodem in the serial driver.