I have a custom USB driver running in isochronous mode that timestamps
itself during it's operation to get statistical information. We have
succeeded in minimizing this number to the point that we can run it all
day under fairly high load, and it never miss a millisecond (it
communicates once a millisecond). However, if the user presses caps
lock, num lock, or scroll lock (everything else is ok), it ALWAYS misses
7-8 milliseconds. We are used to stripping down our computers to the
bare essential hardware/software, but this just seems bizarre, and after
extensive googling, I haven't seen anyone else complain about these
keystrokes interfering with gettimeofday() or causing excessive
latency. Any information would be appreciated.
Dan
On Mon, Feb 10, 2003 at 03:05:22PM -0500, Dan Parks wrote:
> ... However, if the user presses caps
> lock, num lock, or scroll lock (everything else is ok), it ALWAYS misses
> 7-8 milliseconds.
You didnt mention a kernel version, and details very much depend on it.
But you may look into LED setting, and e.g. whether interrupts are
disabled during LED setting.
On Monday 10 February 2003 05:16 pm, Andries Brouwer wrote:
> On Mon, Feb 10, 2003 at 03:05:22PM -0500, Dan Parks wrote:
> > ... However, if the user presses caps
> > lock, num lock, or scroll lock (everything else is ok), it ALWAYS misses
> > 7-8 milliseconds.
>
> You didnt mention a kernel version, and details very much depend on it.
> But you may look into LED setting, and e.g. whether interrupts are
> disabled during LED setting.
linux 2.4.19 - preempt - low latency O(1)
Yes, interrupts are disabled, and the code is sprinkled with loops and mdelay
calls while interrupts are disabled. I'm roughly and probably inaccurately
estimating that in the worst case the pc_keyb driver could call mdelay about
25000 times before giving up with interrupts disabled. What's the best way to
avoid the slow behaviour of the led lights if we don't care about numlock,
capslock, or scroll lock?
Anton
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/