Re: OT: problem with select() and RH 7.3

[James Antill]

Ben Greear <[e-mail]> writes:

> Appologies for an OT post, but I am hoping someone here will
> have an answer.
> 
> It appears that the select() call as found in RH 7.3 waits too
> long before it returns.  I come to this conclusion because I
> was dropping a large number of UDP packets when I allowed the
> select timeout to be > 0.   However, if I force the timeout to
> be zero in all cases, almost no packets are dropped (but the
> packet generator/receiver uses all of the CPU)  My traffic pattern
> is 10Mbps send + 10Mbps receive on 4 ports (of a DFE-570tx 4-port
> NIC, tulip driver), pkt size of 1200 to 1514.
> 
> If I understand select() correctly, it should work equally fast
> with a timeout of zero or 10 minutes, as long as the file descriptors
> are ready to be read from or written to.

 You don't understand select()/poll() correctly.
 If you call select()/poll() with a timeout then every "event" has to
be added to a kernel wait queue, and then removed from the wait queue
when any of those events happen or the timeout occurs.

[snip ... ]

> If anyone has any ideas or suggestions, I'd love to hear them!

 Do a double poll() call, Eg. this code uses socket_poll and timer_q
from http://www.and.org/ ...

static int mypoll(void)
{
  const struct timeval *tv = timer_q_first_timeval();
  int ret = 0;
  int msecs = -1;
  
  if (tv)
  {
    long diff = 0;
    struct timeval now_timeval;
    
    gettimeofday(&now_timeval, NULL);
    
    diff = timer_q_timeval_diff_msecs(tv, &now_timeval);
    
    if (diff > 0)
    {
      if (diff >= INT_MAX)
        msecs = INT_MAX - 1;
      else
        msecs = diff;
    }
    else
      msecs = 0;
  }

  if (!(ret = socket_poll_update_all(0)) && msecs)
    return (socket_poll_update_all(msecs));

  return (ret);
}

-- 
# James Antill -- [e-mail]
:0:
* ^From: .*james@and\.org
/dev/null