Re: 8ms Timer for serial port access
From: Daniel Hofmann (daniel.usenet_at_gmx.de)
Date: 10/31/03
- Next message: Pete Zaitcev: "Re: SMP processor management"
- Previous message: Floyd Davidson: "Re: 8ms Timer for serial port access"
- In reply to: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Next in thread: Grant Edwards: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 31 Oct 2003 17:53:55 +0100
byron@cc.gatech.edu (Byron A Jeff) writes:
> -Why go to all the bother, when not doing it is easier and the
> -result is the same. If he does that, he collects 120 samples
> -per second and he then provides the display with 72 of them. If
> -he doesn't do that, he still collects 120 samples, but he gives
> -the display all 120 of samples but the display never gets around
> -to displaying more than 72 (the rest are overwritten with new
> -samples before they are ever displayed).
> -
> -There simply is no difference in the end result. He displays
> -only 72 out of 120 samples. And *nothing* is going to change
> -that short of either a different serial device providing the
> -samples or a faster video device displaying them. Worse yet,
> -there is no way to avoid such a problem short of synchronizing
> -the serial device and the display device to each other!
> -
>
> You missed one of his points though, Floyd. He munges 5 sets of samples
> to detect a certain type of eye movement. So even though every sample won't
> affect the display directly, every sample is involved in that type of eye
> movement. So it still all needs to be collected.
Certainly true. But these are - in my eyes - two distinct problems
which have to be solved one by one: a) capturing all data without loss
b) doing it in a time sensible manner.
> Jens also points out that he wants to react to that type of eye movement
> as soon as it is detectable. This also points to collecting the data as
> quickly as possible.
But one must say, that 'as fast as possible' is not really a valid
specification of realtime requirements. Unless these are not defined,
any 'blind' optimization maybe useless. There are three timelines
involved: a) the scheduler, b) the serial input, c) the screen. By
now only a) and b) were discussed. c) seems to me - as far as X is
involved - quite more problematic to control. And it also seems to be
much more important for Jens' problem. It doesn't count when he gets
hand on the data, as long as he can't tell when changes are displayed
(am I right?).
Are there any ideas? Some time ago I took a look at XSync extension,
but didn't understand it well. Any pointers to that subject are
welcome.
Daniel.
- Next message: Pete Zaitcev: "Re: SMP processor management"
- Previous message: Floyd Davidson: "Re: 8ms Timer for serial port access"
- In reply to: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Next in thread: Grant Edwards: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|