Hi Greg and Alberto, Greg wrote: >If the network engine is still busy (that is it is flagging >another interrupt), then exiting the the fec interrupt routine >will result in immediate raising of another CPU interrupt, >and re-entry back into the fec interrupt handler. So a while loop >is merely saving the interrupt exit/entry overhead here. > >A higher hardware priority interrupt event may get in first >(though strictly speaking we don't rely on any specific hardware >priority encoding in uClinux).
hmmm... You're right. Actually if there were other pending interrupts with higher priority then the CPU already would run them. I wrongly thought that other pending interrupts could slip in to be executed, but, of course, FEC pending interrupts would be re-run again. >What performance tests did you carry out? >I'd like to see real numbers on total throughput under >heavy load to see see how much better/worse this is. I tested both drivers with the same conditions. The test was to retrieve a dummy file of 65536 bytes from the board via Boa server every 2 seconds, from 3 different machines simultaneously (i.e. every 2 seconds 3 synchronized machines attacked the board to retrieve the file). The reason of choosing a 2 second period is due to the time it takes to download the image (plus a margin). On the other hand, other 2 machines sent broadcast ARP requests continuosly. Meanwhile a test user program was generating a fixed frequency pulsed signal on RTS signal of UART1 (using a tricked mcfuart driver that enabled RTS pin to perform ioctl from userland - note: current mcfuart driver supports ioctl for switching RTS on/off but actually does not enable corresponding GPIO for M5282 during driver initialization). This signal was measured with the oscilloscope. When no network traffic was generated, the mean measured period was 10 ms (which is the desired period). Once traffic was generated, the worst measured period was 50 ms in both solutions. Actually results were too similar in both solutions, so it is hard to point out a final conclusion. However, as I said in the beginning of this mail, you're right in the sense that it is more logical to process all events at a time to avoid leaving-entering the interrupt continuously. Maybe someone could perform more accurate tests. Finally, regarding to Juan Alberto: Juan Alberto wrote: >I agree about the TX and RX interrupt overlap. I'm sending the full patch >that I use to solve the problem avoiding setting IRQF_DISABLED. It has been >generated from 20071001 patch. It has common fixes whith Claude´s patch and >some additional code modifications, like four different interrupt routines, >that I think may be usefull to generate a patch in next system versions. The Nice code, I'll try it. I also agree in Greg's idea to create several interrupt handlers to process the interrupts. I'm gonna dump test results as soon as possible. Best regards, Claude
_______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
