Hello, I have an application where I do the following: - PXA270 CPU - communicating over serial ports on 40ms intervals - communication scheme is very simple in that the linux system sends a packet every 40ms and expects a response back within the 40ms window - currently using 2.6.27 with CONFIG_PREEMPT If I set the application comm thread to real time priority, the sending works very well. There is very little jitter in the 40ms send timing. However, it seems that the system has trouble receiving the response in a timely fashion. I often observe that it takes at least 10ms for the application to receive the response data after the data has appeared on the rs232 bus. Is the RT patch something that would help speed up the serial receive response time, or is there something else going on that I am missing? The system is fairly busy with graphical processing, but the sending is always right on schedule. It seems that interrupts may be involved with this problem as when sending, the send data is smaller than the FIFO size, and is probably put into the fifo during the write, where with the read, an interrupt needs to fire, etc. Does all the kernel code that handles the serial data automatically run at the calling application's RT priority, or is there additional work required to make everything that touches the data RT? I'm also trying to figure out how well RT will work for CAN communications. Once again we have the same problem -- a RT user space application needs to send and receive data with strict timing. Which, I can make a RT thread in user space run well (toggle a gpio with very little jitter), how does this translate to all the kernel components involved in the socketcan stack (networking, etc) that need to touch the data? Thanks, Cliff -- ======================= Cliff Brake http://bec-systems.com -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
