OT: problem with select() and RH 7.3

OT: problem with select() and RH 7.3

[Ben Greear]

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.

I tried various kernels that I am sure have worked in the past,
all with the same results.  The only thing I can think of is that
somehow glibc or whatever implements select is wierd in RH 7.3
(I'm installing RH 7.2 now to test that hypothesis.)

One interesting observation that sheds a bit of doubt on blaming
glibc is that when the timeout is > 0 (ie I'm dropping packets),
the ethernet driver is not receiving as many packets as the
sender is sending.  It also does not have any substantial amount
of errors of any kind.  The ports are connected via a loopback cable,
and all 4 ports exhibit this behaviour.  With a timeout of zero though,
the send & receive counters are virtually identical.

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

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

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

[Alex Riesen]

On Sat, May 11, 2002 at 06:12:52PM -0700, Ben Greear wrote:
> 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.
> 
> I tried various kernels that I am sure have worked in the past,
> all with the same results.  The only thing I can think of is that
> somehow glibc or whatever implements select is wierd in RH 7.3
> (I'm installing RH 7.2 now to test that hypothesis.)

just try to exchange glibc

> One interesting observation that sheds a bit of doubt on blaming
> glibc is that when the timeout is > 0 (ie I'm dropping packets),
> the ethernet driver is not receiving as many packets as the
> sender is sending.  It also does not have any substantial amount
> of errors of any kind.  The ports are connected via a loopback cable,
> and all 4 ports exhibit this behaviour.  With a timeout of zero though,
> the send & receive counters are virtually identical.

...


Although that will not answer your question, just an idea, it will
certanly improve things alot:

if ( select(...) > 0 ) {
    ...
    for ( ;; ) {
	if ( read(fd, buffer, size) != size )
	    break;
	... do something with your packet ...
    }
}

Besides, select(2) cannot be "fast", look at poll(2), async io, or
just operate in blocking mode if your are in that critical timeline.
And lookup kernel archives about poll vs. select benchmarks to find
better explanation.


-alex

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

[James Antill]

Ben Greear <greearb@candelatech.com> 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 -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null