Find the answer to your Linux question:
Results 1 to 6 of 6
I am using recvfrom with UDP and recv with TCP. Using blocking, what is the difference between calling select() 100 times with a 1ms timeout vs calling select() one time ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Apr 2009
    Posts
    3

    Smile Using Select and blocked I/O


    I am using recvfrom with UDP and recv with TCP. Using blocking, what is the difference between calling select() 100 times with a 1ms timeout vs calling select() one time with a 100ms timeout? What exactly does the operating system do during the select? How expensive is it to repeatedly call select? Will other processes be able to run while we are blocking?
    Thanks for any and all help.

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,709
    Quote Originally Posted by mjdubois View Post
    I am using recvfrom with UDP and recv with TCP. Using blocking, what is the difference between calling select() 100 times with a 1ms timeout vs calling select() one time with a 100ms timeout? What exactly does the operating system do during the select? How expensive is it to repeatedly call select? Will other processes be able to run while we are blocking?
    Thanks for any and all help.
    Whether you make one call with a 100ms timeout vs. 100 calls with a 1ms timeout is dependent upon your need for timeliness vs. overhead. If you cannot afford a 100ms delay to get some TCP event notification (other than an signal/interrupt), then you need to set a shorter timeout. Each call to select() results in a kernel call, hence context switch. More calls == more overhead. Which approach you use is a design consideration.

    What does the OS do during the select? Good question, but quite a bit, I think. Eventually it sets a timer and waits for something to happen - the timer expiring, or some event that it is interested in occuring.

    What one process does will not affect another process, unless they are blocking on a system-level semaphore or other resource. If I am blocked waiting for select() to return, you can be running select() and not be blocked. Each process has its own memory, registers, time slice, etc. That's why Linux is a multi-tasking system. It can do many things at seemingly the same time (or actually at the same time in a multi-processor system).
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Apr 2009
    Posts
    3
    Thank you for your quick response. We were using usleep for 1ms originally with non-blocking I/O, but found one call to usleep cost us 20ms (I assume due to the context switching). Would the same be true for the call to select?

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,709
    Quote Originally Posted by mjdubois View Post
    Thank you for your quick response. We were using usleep for 1ms originally with non-blocking I/O, but found one call to usleep cost us 20ms (I assume due to the context switching). Would the same be true for the call to select?
    A call to usleep should not cost 20ms. 20usec (microseconds) would be more appropriate, unless your system is busy and your application was preempted. Remember, Linux is not a real-time system and scheduling is not always "fair". In any case, usleep() is not necessarily accurate and not really what you would want to use. The interval timer facility (setitimer(), getitimer()) would probably work better for most purposes. That's what I've used in the past when programming socket selects.

    As for select() overhead, it would be difficult to say, since I don't know what the internal implementation looks like for either select() or usleep(). FWIW, usleep() probably uses an interval timer under the covers. In any case, 20ms seems VERY long to me. A non-blocking system call should only take a few microseconds (or less) unless the process was not scheduled due to system overhead.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Just Joined!
    Join Date
    Apr 2009
    Posts
    3

    Using select instead of usleep

    You're right; 20 ms does seem to be a long time and I would not have expected this. (By the way, we are using LynxOS). However, when I searched for help on this I found similar posts from other users finding 20 ms also. But because usleep is non-deterministic and waits a minimum of the time specified, we opted to use select instead.

  7. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,709
    Quote Originally Posted by mjdubois View Post
    You're right; 20 ms does seem to be a long time and I would not have expected this. (By the way, we are using LynxOS). However, when I searched for help on this I found similar posts from other users finding 20 ms also. But because usleep is non-deterministic and waits a minimum of the time specified, we opted to use select instead.
    Ok. LynxOS is not Linux, but it does have kernel support for Linux executables and such. It may be that they don't really support usleep(), at least deterministically. Sorry I don't have any LynxOS experience. My real-time system experience was mostly with QNX, which does definitely support deterministic timers.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •