[etherlab-dev] Pre-announcement: unofficial patchset update (Gavin Lambert)

[Graeme Foot]

>
> Mere moments ago, quoth I:
> > On 28 April 2017 11:59, quoth Graeme Foot:
> > > 2) Your 0054 patch successfully moved the slave sdo request processing
> > > from the master fsm's idle state to be called every cycle of the master
> > > thread.
> > > However, I have my Linux environment set to run at 100Hz, so this
> > > thread would only fire once every 10ms.  Each SDO read/write request
> > > would take approx. 30ms to complete.  I didn't want to change Linux to
> > > run at 1000Hz so I
> > > created patch "etherlabmaster-0010-
> > > allow_app_to_process_sdo_requests_from_realtime.patch".
> >
> > Maybe I'm missing something about how the RTAI version works, but all I
> did
> > was to move the logic from inside fsm_master to inside fsm_slave; AFAIK
> > both of these execute on the same thread (either the master IDLE or master
> > OPERATION thread).  This is independent of the application realtime loop
> > either way, so this should not have changed how frequently they run; it
> just
> > allows multiple slave requests to run in parallel rather than forcing them
> to
> > execute sequentially, so it should be a net performance gain.
> >
> > Though it does seem reasonable in your use case to want to run the slave
> > FSMs more often.  I don't see how you could do that safely, though -- you
> > can't run ec_master_exec_slave_fsms outside of the master_sem lock, and
> > your RTAI task might interrupt Linux while it's still holding that lock,
> which will
> > deadlock your RTAI task.
>
> Are you configuring with --enable-hrtimer?  After having a quick look at the
> code, I can see a potential performance degradation from the patch if you
> aren't using it (or did enable it but didn't call
> ec_master_set_send_interval with an appropriate value after activating the
> master).  Perhaps you could try enabling that instead of using your patch
> and see if it helps?
>

Hi,

I don't use ec_master_set_send_interval() or --enable-hrtimer since my masters operational thread has always run at 10ms (100Hz) anyway.  (I probably should so will look at adding that in at some stage.)  My Linux kernel is configured to run at 100Hz and the master thread is not realtime so is scheduled by the Linux scheduler (RTAI).  Because Linux is set to 100Hz, it only runs the masters operation thread once every 10ms.

Prior to your SDO patch, ec_fsm_master_action_process_sdo() was being called by the masters fsm, but from its idle state.  So it would only be called after all other processing and housekeeping was complete and was only being fired approx once every 800ms on my setup with 50 odd slaves.  After the patch ec_master_exec_slave_fsms() is now called every time the masters operational thread fires.  All good except that on my system that is still only once every 10ms.

So my new patch allows ec_master_exec_slave_fsms() to be called from my realtime context.  As you pointed out the master_sem lock would cause a deadlock, so I don't use it.  Because I don't use the lock I have instead added some flags to track whether it is currently safe to make the ec_master_exec_slave_fsms() call.  It's generally just the rescan thats a problem.

I don't know if the patch will be useful for anyone else, but is useful if Linux is configured for 100Hz.  It may also be useful on short cycle time systems, e.g. 100 - 250us cycle times, where you want to process the SDO's faster.  Even if Linux is set to 1000Hz is will only schedule the master operational thread at 1ms.  The master thread may also be delayed if the Linux side gets some heavy CPU usage.


Thanks for thinking about it.  I like getting feedback for my patches as its easy to overlook potential bugs or alternate solutions which can be better.


Graeme.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20170507/f880e529/attachment.html>