Author Topic: Accuracy problem with usleep  (Read 4167 times)

master higgins

  • Guest
Accuracy problem with usleep
« on: February 06, 2012, 05:42:07 pm »
Hi, I've been trying to use the usleep function from <unistd.h>, but for some reason, it doesn't work like it should. It seems it sleeps way more than the time specified. For instance, if I put a usleep(10000) I expect it to wait 10000 microseconds (or 10 milliseconds) to resume execution. Then I tested with usleep(1) to make it sleep for 1 microsecond, but it took the same as the usleep(10000) call. I can understand there's a granularity in the time measures, so I tested with usleep(100) and usleep(1000) but for some reason it doesn't give different results.

The context in which this was tested was in the SpeedThrottle function in drivers/dingoo/dingo-throttle.cpp of the fceu emulator. I tried replacing the dingoo_timer_delay invocation with usleep but even if I use usleep(1) hardcoded the game goes too slow.

I can't see how there isn't another way to sleep in dingux other than busy waiting:

Code: [Select]
/**drivers/dingoo/minimal/minimal.cpp*/
void dingoo_timer_delay(clock_t milliseconds)
{
clock_t now=dingoo_timer_read();
while (dingoo_timer_read()-now<(milliseconds*1000));
}

I also tried with the select function from unistd.h but to no avail (the game gets sluggish):
Code: [Select]
void dingoo_timer_delay(clock_t milliseconds)
{
fd_set rfds;
FD_ZERO(&rfds);
FD_SET(0, &rfds);
struct timeval tv;
tv.tv_sec = 0;
tv.tv_usec = 1000*milliseconds;
select(1, &rfds, NULL, NULL, &tv);
}

The weird thing is that using usleep or select, the fps raises to about 100fps, but the game is slow despite the high fps value (I don't know is usleep or select are properly implemented, that is, not making a busy wait).

I hope we can solve this problem. The main reason I'm modifying this part of code is to improve the frame limiter section (throttling option) which is not accurate (The sound gets distorted while playing from time to time).

Greets! ;)

master higgins

  • Guest
Re: Accuracy problem with usleep
« Reply #1 on: February 06, 2012, 05:58:45 pm »
I've just tested with SDL_Delay and It does the same thing.  :'(

Anyone has tested usleep with success in any application?

Greets! ;)

pcercuei

  • ***
  • Posts: 1397
    • GitHub
Re: Accuracy problem with usleep
« Reply #2 on: February 06, 2012, 09:43:13 pm »
That's not a problem actually, it's a limitation. The kernel is not real-time, you won't be able to go under 10ms.

master higgins

  • Guest
Re: Accuracy problem with usleep
« Reply #3 on: February 07, 2012, 12:57:13 am »
Thanks for your help. I really appreciate the information you gave me so I can guide my efforts in another direction.

Best regards. ;)

master higgins

  • Guest
Re: Accuracy problem with usleep
« Reply #4 on: February 08, 2012, 09:01:54 pm »
Hi again. I've been searching information about which kernels support RTC (real time clock) and I realised that the kernel installed in my Dingoo Digital A320 is already RTC (I found information about that here in the 12th reply and downloaded the kernel image here). My Dingoo has a ILI9338 LCD.

The first link says in the 12th post (which is a thread here in this board) that the Kernel Image has the RTC feature which was added by Boukichi. I don't know if all these statements I'm making are true or not. If they're true, why is it that having an RTC kernel image doesn't fix the usleep problem?

I hope someone can enlighten me again...

Thanks for your patience! ;)

pcercuei

  • ***
  • Posts: 1397
    • GitHub
Re: Accuracy problem with usleep
« Reply #5 on: February 08, 2012, 09:13:13 pm »
Totally unrelated, sorry.

The Real Time Clock is a hardware part that allows you to read the date.

A real-time kernel is a version of Linux (or any other OS) that is able to respond to requests in real-time, that is where the processing delay is guaranteed to be lower than a pre-determinated level. Examples of real-time Linux kernels are RTLinux and Xenomai.

master higgins

  • Guest
Re: Accuracy problem with usleep
« Reply #6 on: February 09, 2012, 12:14:00 am »
Oh!, I see. Thanks for clarifying! ;)

Greets!  :)