Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

OK, 2.4.0 kernel installed, and a new set of numbers: testkernel ping-pongs/s. @ total CPU util w/SOL_NDELAY sample (2 skts) 2.2.18 100 @ 0.1% 800 @ 1% sample (1 skt) 2.2.18 8000 @ 100% 8000 @ 50% real app2.

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

Chris Wedgwood wrote: > > On Sat, Jan 20, 2001 at 07:35:12PM -0500, Dan Maas wrote: > > Bingo! With this fix, 2.2.18 performance becomes almost identical to 2.4.0 > performance. I assume 2.4.0 disables Nagle by default on local > connections... > > 2.4.x has a smarter nagle algorith

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

Dan Maas wrote: > > What kernel have you been using? I have reproduced your problem on a > standard 2.2.18 kernel (elapsed time ~10sec). However, using a 2.4.0 kernel > with HZ=1000, I see a 100x improvement (elapsed time ~0.1 sec; note that > increasing HZ alone should only give a 10x improvemen

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

Chris Wedgwood wrote: > > You can measure this latency; and it's indeed very low (lmbench gives > 28 usecs on one of my machines). > > If you don't see this I would suspect an application bug -- can you > use strace or some such and confirm this is not the case? OK, two new data points (thanks

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

Dan Maas wrote: > > > OK, if this is the case, how do I alter the scheduling class? > > man sched_setscheduler > > Set SCHED_FIFO or SCHED_RR; you'll need to be root to do this AFAIK. > > I do agree though, Linux's scheduler (for SCHED_OTHER processes) is much > less "ruthless" than, say, the

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

David Schwartz wrote: > > How can you tell when select wakes up the process? What you are seeing has > nothing whatsoever to do with select and simply has to do with the fact that > the kernel does not give the CPU to a process the second that process may > want it. I guess I can't. But

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

Thanks CW and DS for the prompt replies. However, although each addressed the (flawed) example I included, neither addressed the problem described in the text. I wrote: > > If select() is waiting for data to become available on a > > TCP socket FD, and > > data becomes available, it doesn't retur

PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

[1.] select() sleeps for 1 tick even if data available [2.] Full description of the problem/report: If select() is waiting for data to become available on a TCP socket FD, and data becomes available, it doesn't return until the next clock tick. This produces large latencies