Re: 8ms Timer for serial port access
From: Byron A Jeff (byron_at_cc.gatech.edu)
Date: 10/31/03
- Next message: Sybren Stuvel: "Re: Qt newbie question"
- Previous message: Byron A Jeff: "Re: 8ms Timer for serial port access"
- In reply to: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Next in thread: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Reply: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Oct 2003 18:10:33 -0500
In article <87u15q1nme.fld@barrow.com>,
Floyd Davidson <floyd@barrow.com> wrote:
-byron@cc.gatech.edu (Byron A Jeff) wrote:
->In article <BBC5EE32.1D21%jens.schumache@gmx.net>,
->Jens Schumacher <jens.schumache@gmx.net> wrote:
->-Am 29/10/03 17:05 Uhr schrieb "Floyd Davidson" unter <floyd@barrow.com> in
->-87ism7vgx1.fld@barrow.com:
->-
->-> Moreover, if that is the case
->-> then the only sane way to write a serial_check_buffer() function
->-> is to include a minimal sleep, which will cause 10ms of that
->-> timing granularity to be given to other processes!
->
->Correct again. sleep has a grainularity of 10ms. But my question is now
->does read and/or select have the same grainularity? What about usleep or
->nanosleep? If so then I can see why Jens is upset.
-
-Yes. Any sleep function will give up the process's current time
-slice, and that process then will not be rescheduled until at
-least the minimum HZ time interval has passed.
Unless you put it on a real time scheduling queue.
-
-The effect is that any sleep will have a granularity of 10ms.
Under normal circumstances.
-
->I'm interested now, so I guess I'll spend a couple of minutes setting up
->some experiments. I'll be back. OK I'm back with the first test. I have this
->loop:
->
->-------
-> for(i=0;i<10;i++) {
-> delay.tv_sec = 0;
-> delay.tv_usec = 100;
-> select(0,NULL,NULL,NULL,&delay);
-> TIMER_GET(ticks[i]);
-> }
->------------
->TIMER_GET is a macro that simply marks the time with gettimeofday. I have
->another routine that converts into microseconds from a start time. Here are
->the results:
->
->0: 2533
->1: 12367
->2: 22483
->3: 32533
->4: 42552
->5: 52388
->6: 62441
->7: 72364
->8: 82694
->9: 92360
->
->So there is no doubt that even though we told select to delay 100 uS, that
->it took 10 ms for it to get back to us. Bummer.
-
-Yes, but your results (even though they are accurate) are probably not
-valid! :-)
-
-It depends on how you coded TIMER_GET. If you saved the values in
-an array, and analyzed them outside of the for loop shown above,
-they are valid. Otherwise...
The former. Collected in the loop, analyzed after the loop completed.
-
->Here's a quick look at the sleeps [usleep, and nanosleep].
-
- [huge snip of stuff that is interesting an accurate]
-
->-> But that just points out that you don't really need to read the
->-> data every 8 ms. You could read the data every 16 ms or every
->-> 32 ms and be just fine. You just get twice or four times as
->-> much data with each read that way.
->-
->-No I can't the reason comes later...
->
->I do understand. You are correct.
-
-I don't think so... :-)
-
-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.
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.
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.
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.
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.
-
->-> My understanding of what Jens said earlier (and he can correct
->-> me if I'm wrong here, because I might well be) is that he is
->-> graphing the data for display, and he believes that if he
->-> doesn't grab the data as it becomes available there will be
->-> buffer overflows and he will lose the data.
->->
->-...basically right I want to display something on the monitor.
->-The reason why I have to read the data when it arrives is pretty easy.
->-I wrote earlier that I have to detect saccades. I'm doing this with a
->-5 point differentiator. Because I'm doing this online this means that I take
->-the current point and use the 4 data frames I got before. You see here is
->-already a delay of more than 2 frames for the detection.
->
->Right. So as you pointed out from the beginning, it's a soft real time process.
->
->-When I'm reading the data every 32 milliseconds, and the subject starts to
->-make a saccadic eye-movement after 8 ms, the possibility to detect the
->-saccade and to react gets pretty small. This is why it's important to get
->-every frame of data as soon as possible.
->
->Correct. So make the process run on the real time scheduler, Make sure that
->it usleeps when it's waiting, and it'll wake up right on time.
->
->-> However, if this data is being *used* for something that is time
->-> critical, then yes there is a problem. For example, if you need
->-> to read the data, and send feedback to the device *before* it
->-> sends another packet of data... that is a serious real time
->-> constraint that a standard Linux kernel is not going to provide.
->-
->-I don't need to send a feedback, but how I described, I need the data pretty
->-was after the eye-movement occurred.
->
->I hope this helps. I used the real time scheduling queue to get precise timing
->for my PhD results. I'm sure that it'll help you in your application.
-
-Note that his input timing is *not* what determines the data
-quantization intervals. That is predetermined by the device
-connected to the serial port. As a result, how accurate the
-timing of data collection is makes absolutely no difference in
-what the data is. In fact, the data is stored a 4k byte buffer
-by the serial port device driver, and it would clearly be
-possible to grab chunks out of that buffer that are at least up
-to 1 whole second apart, and it would not affect the data
-integrity in the slightest.
-
-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.
BAJ
- Next message: Sybren Stuvel: "Re: Qt newbie question"
- Previous message: Byron A Jeff: "Re: 8ms Timer for serial port access"
- In reply to: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Next in thread: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Reply: Floyd Davidson: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
