Roland Tollenaar wrote: > Hi, > >> Check the /proc output again, there should be also RTnet's stack manager >> at prio 98. Maybe that is too low for your scenario and causes prio >> inversions (note: every incoming Ethernet frame goes through its hands). >> Try lowering the prio of your rt_task1 beneath 98. > > Thanks. This seems to have made a big improvement. I have so far not > once detected the scope to loose lock on the sawtooth when the > index_check in eml is still disabled. Before lowering the priority of my > task (to 97) I could still invoke what I suspect to be a latency spike. > > If the index_check is enabled I now mostly have less problems too. There > is a chance in start-up of the application that there is a latency spike > and then the warning kicks in. Due to the fact that the shift is > permanent, the error is persistent and this then destabilizes the > sawtooth a bit.
Hmm, this doesn't convince me yet. Such skews during startup may as well be triggered by unusual load during runtime (non-RT activity or new RT components). Did you put your system under adequate non-RT load as well while measuring the outputs? > > I will keep the check disabled but for the EML chaps I do think this is > a point of interest. I would be very interested how this index shift > occurs and why it is persistent after occurring once. > > Sorry for the pragmatic qualifications here but in the end its the > stability of the outputs that will determine the behaviour of the > machine so its not a bad way to assess the software. :) A problem isn't solved until it is also understood. > >> If the problem persists (or your _really_ want to understand what >> happens), you could try to put an xntrace_user_freeze(0, 1) before the >> line which emits that EML warning, turn on the I-pipe tracer, set a >> large back_trace_points value (a few thousand), enable verbose mode, and >> grab what /proc/ipipe/trace/frozen reports after the hick-up. See [1] >> for more howtos. > > Done this before so it should not be a problem. Don't think it is In that case, I would even more suggest to collect the data, maybe now about the fragile startup case. > necessary quite yet as the behaviour at the moment looks good. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
