> > *Another thing I just found out, and that may have some influence, is that > the ARM clock was set to 300MHz with the "ondemand" governator. I expect > better results setting this to the maximum of 1000MHz.*
*Maybe* - Because on demand will go up to 1Ghz when CPU exceeds ~66% load. For my own usage here, I found that it did not make much difference until I went to a multi process model( in addition to the two processes I have always had ). That is to say, I was reading all values from the CANBus via one executable prior to experimenting with using multiple processes for different data sets. Using fork() with execv() type processes. In the end I'd have to say that multiple processes using fork() and execv() did allow me to do more processing at once. But it also introduced more kernel cleanup, as is noticeable when running atop to monitor process activity. Meaning, that I was able to sample more data in the same amount of time, but because the kernel gets involved a lot more in cleanup, I do miss some samples once in a while . . .Well, actually I'm not 100% sure what is happening behind the scenes but I see kworker processes pop up more frequently. Either way, whatever kworker processes are doing is causing my applications to stall occasionally. For a short period of time. Just as one last note. These processes I create run for the lifetime of the whole application. So . . . It's not like I'm creating too many zombies processes or something . . . Which I learned not to do very early on ;) On Fri, Sep 11, 2015 at 11:59 AM, Carlos Novaes <[email protected]> wrote: > Hi, > > I would not say this is my absolute decision, but in the present state it > seems that the erratic behavior is unlikely to happen. Anyway it is > something that the ARM code must be able to deal with. > It was running for about ten minutes, just a few samples missed (when I > start a file transfer via sshfs), none of then was repeated. It will > perform the control of a walking robot, as a academic experiment, and will > run for about twenty seconds to one minute at each time. Just to record > some data and for demonstration purposes. Of course, there is no control > processing yet, so the final results will be worst. If so, there must be > the case for a complete rewrite. > Another thing I just found out, and that may have some influence, is that > the ARM clock was set to 300MHz with the "ondemand" governator. I expect > better results setting this to the maximum of 1000MHz. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
