Hi again, I take 'there are still some quirks in the system' as 'I don't know' .... as I said I will set up a box and check the latencies, there have been a lot of work on RT-Preempt, and I would say that the MP problem is solved and most work now is for device drivers and filesystems, ( locking in the filesystems are a bugger ), also ioctls are fixed. With the spinlocks for MP systems we actually have the situation where MP might be beneficial for a RT workload, and it should be possible to use cgoroups for 'quality of service' ie. reserving system capacity for the non realtime parts of EMC on a multitasking system.
There should not be any worse latencies than the sum of the hardware latency, and the cost of interrupt handling and a context switch, at least when all of the ongoing RT-Preempt work is done. If we compare this with RT-Linux / RTAI / Xenomai ... the main difference is the context switch associated with the interrupt, and on a 200 MHz Pentium the context switch time for a task with its memory locked in RAM ( and stack ) is less than 10 us, from modern hardware I do expect it to be slightly smaller. So in time I 'think' we should se jitter comparable to RTAI/RT-Linux and a worst case time which gets really close. For now I think the best procedure is to measure the jitter and worst case. Anyhow, I am not really interested in relative merits since RTAI will always get lower jitter/latency hanging off an interrupt, I want to increase the availability of EMC to a large number of people ( me and the voices in my head ). So I think RT-Preempt is good enough for some cases, and will get to the point where it's god for all cases later, right now there is indeed some things to look out for but IMHO it should at least theoreticly be able to get a lot better. I looked some more, and it seems if there were a rtapi-preempt , it could be used for 'NON realtime' systems instead of the stub that is now used, thus it could be run on a vanilla kernel. ( for demo/testing purposes ) SO thanks for all the help and warnings, I think I should go and have a look at the code and see if I can get it running on RT-Preempt, wether it's good enough remains to be seen. / regards, Lars Segerlund. 2010/9/16 Jon Elson <[email protected]>: > Michael Büsch wrote: >> I got it below 20 microseconds when I last tested it with the patches I >> posted. >> However, there were still some quirks as in certain actions in the >> system >> induced huge latency spikes. However, if one doesn't do those >> activities, >> > 20 us is not bad, but would likely not be acceptable for many stepgen users. > It might be OK for servo cards, however. But, can you TRUST that those > big latency spikes will NEVER happen when using the system for CNC control? > That is a real worry. > > Jon > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
