-1

I'm having a latency issue with select(). Actually I'm not sure if this is a problem with select() or not.

Story is like below.

  1. I'm using select() to detect a socket fd event.
  2. After select() wakes up, I do recv() to get data stream from a socket buffer.
  3. No problem with this and it works very well.

but...there is a latency problem... I have NIC tcpdump timestamp, Application's select() wakes up timestamp. These timestamps have big difference, over "15us".

No big logic in my application, just do select() socket fd and get timestamp with gettimeofday() function right after select() wakes up. I have no idea, why it takes that long to wake select() up.

I tested to make sure if select() is the problem or not. 1. No Select, Just loop to recv() socket fd until I get first data. 2. NIC gets a data stream, and I get tcpdump timestmap 3. recv() gets first data stream. 4. I get timestamp right after first recv() success.

This test shows big difference between NIC timestamp and recv() first timestamp.

Summary... After NIC gets data stream. 1. select() detects socket fd, it takes over 15us I think. 2. NO select() detects socket fd, only recv() loop until first data I get, it takes over 15us too.

Please somebody help me...Is this acceptable number? ( I mean over 15us. ) Or there is an check point I don't know ??

The Server HP, OS redhat 6.2 kernel 2.6

chuff
  • 5,846
  • 1
  • 21
  • 26
user2313523
  • 3
  • 1
  • 1
    Nobody said your process or your thread would get scheduled immediately. There are other process, other threads, other priorities, timeslices, .... Unless you are running in a real-time operating system you can't expect real-time response. – user207421 Jun 03 '13 at 00:50
  • [Select isn't broken](http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html) – Brian Roach Jun 03 '13 at 00:51

1 Answers1

1

This is the scheduling delay in a general-purpose OS. Your only alternative is probably to switch to a real-time OS.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • Thank you for your answer. I understand, and know the response time of select() not like thunder fast. What I wonder is why just select() takes that much time. In this server I have many other biz logics after I get socket stream, and they take about 20us total avg. What I expect is select() response time under avg 5us. Is this may be kernel tuuning issue?? – user2313523 Jun 03 '13 at 03:12
  • @user2313523: It has nothing to do with `select`. It's just scheduling delay. You can probably reduce it somewhat by turning off CPU power management. – David Schwartz Jun 03 '13 at 03:47
  • It's probably the thread context switch. Calling select puts your thread to sleep and its registers and other CPU related state are backed up to memory. Once is activated again, i.e. when your call to select is about to end because there's something to read, the scheduler needs to do all the things and then restore your registers and other CPU state. – yeoman Sep 18 '19 at 21:13
  • And there's lots of threads across e.g. a Linux or FreeBSD system across lots of processes, all competing for CPU time. Dealing with your thread having to become active again in the middle of the usual fray is what makes it take half a computer week, on your system 15us and more, to get that done. – yeoman Sep 18 '19 at 21:16
  • Really low latencies are in most cases achieved by running an extremely simple real time OS and extremely low-level code on extremely slow and simple machines, running at like 20 MHz but without any of the overhead involved. Sometimes the very latency critical parts of an application are simply executed on such a machine and OS – yeoman Sep 18 '19 at 21:20