Re: 8ms Timer for serial port access
From: Byron A Jeff (byron_at_cc.gatech.edu)
Date: 10/31/03
- Next message: mat bike: "Re: extracting debug info from a binary"
- Previous message: matthieu imbert: "Re: extracting debug info from a binary"
- In reply to: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Next in thread: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Reply: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Reply: Daniel Hofmann: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 31 Oct 2003 07:39:50 -0500
In article <87fzha1c5m.fld@barrow.com>,
Floyd Davidson <floyd@barrow.com> wrote:
-byron@cc.gatech.edu (Byron A Jeff) wrote:
->-Whether the data is collected in real time, or not, just isn't
->-going to change what happens later. Whether that is 32ms later
->-or 32 days later makes no difference if the data is being fed to
->-a display device that updates the screen every 14ms instead of
->-less than every 8 ms. And, regardless of whether it did or not,
->-no human can actually *see* data on the screen being changed
->-that fast!
->
->I get your point, to a point. 14 ms is the Just Noticable difference of the
->update of the display. However by not collecting and analyzing data as it comes
->in, there is an additional latency that is added, latency that will add some
->data slip as it beats against the 14ms video update. In short, Jens needs to
->collect every 8ms to ensure that when that 14ms video update occurs, it
->updates with the latest collected information.
-
-Not if he wants his data to display every change, which is what he
-stated his goal was. (Regardless of the fact that no human will
-be able to notice that change...)
-
-However, if what you are stating above is in fact what he wants,
-which is to make sure the latest data is shown when that 14 ms
-interval on the video update comes around... then he doesn't
-need to be concerned with real time data input at all, and he
-doesn't need to be concerned about dropping a data packet, or
-about the latency jitter between packets. In that case he can
-just do a loop on his read(), and send whatever he gets to the
-video. He will end up overwriting what is there if jitter gives
-him first a too long interval and then a too short interval.
-
->So I believe that he still has the application correct: collect the data from
->the serial port as close to real time as you can and update the display as
->quickly as possible. Even though the display is the slower process, I can see
->no good reason to keep it updated with as up to date information as can be
->collected.
-
-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.
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.
->Let's make a concrete example so we can all get on the same page (time is
->measured in milliseconds):
->
->24 byte packet is ready from the serial port at time X. The video display
->updates at time X+1, and the normal 10ms read/select/usleep timeout occurs
->at X+2. The question is it critical to collect the data from the serial port
->and update the video before time X+1? Jens seems to think so, and only because
->it is easy to do (by running in a real time scheduling queue) I would agree.
-
-Doing so is more complex than not doing so, and there is
-absolutely no benefit, or even difference, in the results.
I've already shown that it isn't any more complex once you put the process
on the real time scheduling queue. It'll wake up right at time X.
-
->Even though the next packet, which comes in at time X+8 won't see an update
->until the next time the video updates (X+15), it's better the collect it
->immediately instead of waiting until X+12, the 10ms timeout, because there will
->be times where the collection and the video update can occur before the 10ms
->timeout comes along.
-
-That will still happen anyway. He simply *cannot* display 120
-individual samples per second with a system that updates the
-display 72 times per second. Whether the frame slip occurs at
-X+1 or at X+9 makes no difference.
I understand that. But given the equal choice to collect sooner or later,
it's probably better to collect sooner.
-
->OTOH if it were difficult to get processes to wake up in a timely fashion,
->an assumption which started this thread, then I'd be inclined to agree with
->Floyd, it probably doesn't matter if you video is at most one frame behind
->the current data.
->
->So in the end, it seems like it's much ado about nothing.
-
-In fact, if video output is all this is doing, this entire
-thread has *only* been ado about nothing. At 20 frames per
-second nobody would be able to see a change, so what is the
-concern about real time collection of data at 120 frames per
-second if 48 arbitrary frames are dropped and never displayed,
Because those 48 frames are still used in eye movement detection even though
they are not displayed.
-plus when the display frame rate is more than 3 times as fast as
-a human eye can follow anyway?
-
-Basically he is munging his data by being concerned about real
-time data acquisition. What he should be doing is just using
-standard methods for downloading the data and then spending his
-creative efforts at processing that data to compress it by
-dropping only redundant information rather than allowing data to
-disappear arbitrarily.
I'm still not clear if the data is redundant or not.
-
-...
-
->-Displaying the data is a whole different bag of worms though,
->-and nothing relating to data input is going to affect that.
->
->Not the data integrity, but the syncronization of the data input to the screen
->update. Jens wants these two bound together. I agree with you that it doesn't
->matter since the screen is slower than both the input stream and the standard
->kernel quantization. But there is a soft real time relationship between the
->two.
-
-He wants them bound together because he mistakenly believes that
-it affects data integrity. He not only stated that, but there
-would be no other reasonable reason for doing so. The problem is
-that binding them has the opposite effect, and causes a loss of
-data integrity.
-
-The "soft real time relations" might be interesting, but it's
-nothing but a red herring that keeps his attention on the wrong
-aspect.
In short: get it to work first, then figure out what if any optimizations are
required.
BAJ
- Next message: mat bike: "Re: extracting debug info from a binary"
- Previous message: matthieu imbert: "Re: extracting debug info from a binary"
- In reply to: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Next in thread: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Reply: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Reply: Daniel Hofmann: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
