How long does your nanosleep() really sleep? (2004)

by lkurusaon 11/8/2018, 9:56:56 PM with 4 comments
  • by clarryon 11/10/2018, 9:28:49 PM

    This bug is still there in OpenBSD. With the 100Hz tick rate, sleep(10ms) turns effectively into 15 milliseconds, or -- more likely -- 20 milliseconds if the system is lightly loaded and the program doesn't spend much of its timeslice.

    Of course, some programs don't expect this.

    Fun story, me and my little sister played a game online years ago. The Mana World. A game with an OpenBSD port. She teamed up with some guy in game. She also told me that guy had a terrible internet connection & slow PC. So once I found them, I watched this guy lag and move about in slow motion. I asked if he's running OpenBSD. He said he's running OpenBSD. I sent him a little patch and it's like he got a new PC and a new internet connection, just like that.. :-)

  • by loegon 11/10/2018, 8:42:03 PM

    On modern FreeBSD, when I run the article's demo program, by default I see even higher and more variable latency than the author observed in 2004:

        0.017686
    0.031868
    0.055889
    0.008931
    0.014824
    However, when I set the kern.timecounter.alloweddeviation sysctl ("Allowed time interval deviation in percents") to 0 (from the default of 5%), I get very low and consistently low latency:

        0.000036
    0.000031
    0.000030
    0.000037
    0.000036
    0.000040
    There are pros and cons to both defaults.

  • by js2on 11/10/2018, 10:47:30 PM

    Solaris 8 briefly had a kernel bug such that usleep() didn't sleep at all. I don't recall the details, just that after patching the system and rebooting things were behaving very bizarrely. I eventually realised the sleep command was returning instantly and from that tracked it to the system call, and then found a patch for the issue. Google is failing me in digging up any details. It would've been in the 2000-2004 time frame.