On ש', 2005-12-03 at 03:17 -0500, Rafi Gordon wrote: > Hello, > Thanks for the answer. > > > I suppose it is OS-, device-, and driver-dependent. > > You don't mention the CPU here directly. I assume the CPU and it's clock speed > has also to do with the upper limit of interrupts from which on > interrupts will be dropped. Am I right ? From your answer it seems that the > device driver is the one (sloely?) which decides this upper limit on > the number of interrupts.
no. CPU can always ignore interrupt requests as it wishes. the 'waiting queue' is AFAIK architecture (CPU model + other peripherals) specific > > >if the handler eats all the cycles on handling > the interrupts then the consumers of the device (applications) won't > get the CPU. Therefore the OS may start dropping interrupts (and yes, > losing data) at some point. > > A practical example which had driven me to post this question originally: > I want to know when I should use NAPI (polling) instead of interrupts > in a network > card so that I won't loss interrupts. (and data , as a result). This is why drivers introduce a tunable parameter for the driver IRQ requests threshold. there are NIC's buffers. Extreme example: the NIC controller can throw interrupt request each time there is new data in its rcv buffer or it can be tuned up to do this less frequently, say after a watermark has been reached. if you want this to be efficient and working, you need to know how big NIC's buffers are, and can tune up your OS's tx/rx network queue lengths ( via sysctl and ifconfig ) > > The rate of interrupts the nic receives depends of course on the number > of packets which are sent by the application. and many other tunable things. > > So I assume that on machines with sow CPU the amount of maximum > interrupts the CPU can handle will be lower (linearly ?) than the > amount of maximum interrupts th CPU can handle on machines with > faster CPU. true, unless this is a special CPU that is designed not to miss interrupts: if this is a RT OS, it is designed for this, and the devices are designed not to create too many interrupts. > > Is there a way, except experimenting, in which I can get to know , for > different CPUs > (with different clockspeed) ,when it is better to use NAPI (polling) > instead of interrupts? If you're talking about NIC, then your problem is on receiving data ( you can always retransmit on send ) If you have a modern NIC, It is always better to fill its buffers and then to flush them into OS's buffers, because they are usually faster than the main memory of a regular computer. I don't know of a way to know how frequently IRQ can be handled/sent to/from CPU, except _reading_CPU_manual_ really thoroughly... I actually never had to do this. Is your original question too secret to directly be asked over ML ? -Max. > > -- RG > > > > > > On 01 Dec 2005 13:42:23 +0000, Oleg Goldshmidt <[EMAIL PROTECTED]> wrote: > > Rafi Gordon <[EMAIL PROTECTED]> writes: > > > > > I assume that there is a limit on the maximum number of > > > interruprs a CPU can receive without dropping or losing > > > interrupts and not handling them. > > > > > > Is there a way in which I can determine in Linux what is this > > > limit (apart from bombing the CPU irq lines...) ? > > > > > > Is this a hw detail which is constant regardless > > > of which operating system runs on that processor ? this should be bound by CPU's clock and IRQ queue, but today there are special IRQ handling circuits that work between the device and the CPU. ( hmm... can't remember the name ... ) > > > > I suppose it is OS-, device-, and driver-dependent. It is likely > > limited by the maximal rate at which the device driver is able to > > handle the interrupts: if the handler eats all the cycles on handling > > the interrupts then the consumers of the device (applications) won't > > get the CPU. Therefore the OS may start dropping interrupts (and yes, > > losing data) at some point. > > > > There is a variety of related mechanisms that an OS can employ. > > In some cases the OS may disable interrupts while handling an > > interrupt. In some cases it may set a timer, and if the timer > > expires and the device in question claims it is ready it is an > > indication that an interrupt was missed, and the handler may be > > invoked manually. > > > > See, for instance, Chapter 10 of LDD3, > > > > http://www.oreilly.com/catalog/linuxdrive3/book/ch10.pdf > > > > -- > > Oleg Goldshmidt | [EMAIL PROTECTED] | http://www.goldshmidt.org > > > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > Many hands make light work. -- John Heywood ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
