"Stephen D. Williams" <[EMAIL PROTECTED]> writes:
> James Antill wrote:
> ...
> > >The
> > > time went from 3.7 to 4.4 seconds per 10.
> >
> > Ok here's a quick test that I've done. This passes data between 2
> >
James Antill wrote:
...
> >The
> > time went from 3.7 to 4.4 seconds per 10.
>
> Ok here's a quick test that I've done. This passes data between 2
> processes. Obviously you can't compare this to your code or Michael's,
>
"Stephen D. Williams" [EMAIL PROTECTED] writes:
James Antill wrote:
...
The
time went from 3.7 to 4.4 seconds per 10.
Ok here's a quick test that I've done. This passes data between 2
processes. Obviously you
"Stephen D. Williams" <[EMAIL PROTECTED]> writes:
> James Antill wrote:
> >
> > I seemed to miss the original post, so I can't really comment on the
> > tests. However...
>
> It was a thread in January, but just ran accross it looking for
> something else. See below for results.
Ahh, ok.
James Antill wrote:
>
> "Stephen D. Williams" <[EMAIL PROTECTED]> writes:
>
> > An old thread, but important to get these fundamental performance
> > numbers up there:
> >
> > 2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
> >
> > elapsed time for 10 pingpongs is
> > 3.81327
> >
James Antill wrote:
"Stephen D. Williams" [EMAIL PROTECTED] writes:
An old thread, but important to get these fundamental performance
numbers up there:
2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
elapsed time for 10 pingpongs is
3.81327
10/3.81256
"Stephen D. Williams" [EMAIL PROTECTED] writes:
James Antill wrote:
I seemed to miss the original post, so I can't really comment on the
tests. However...
It was a thread in January, but just ran accross it looking for
something else. See below for results.
Ahh, ok.
Michael
"Stephen D. Williams" <[EMAIL PROTECTED]> writes:
> An old thread, but important to get these fundamental performance
> numbers up there:
>
> 2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
>
> elapsed time for 10 pingpongs is
> 3.81327
>
An old thread, but important to get these fundamental performance
numbers up there:
2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
elapsed time for 10 pingpongs is
3.81327
10/3.81256
~26229.09541095746689888159
1/.379912
An old thread, but important to get these fundamental performance
numbers up there:
2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
elapsed time for 10 pingpongs is
3.81327
10/3.81256
~26229.09541095746689888159
1/.379912
"Stephen D. Williams" [EMAIL PROTECTED] writes:
An old thread, but important to get these fundamental performance
numbers up there:
2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
elapsed time for 10 pingpongs is
3.81327
10/3.81256
> can someone explain what is nagle or pinpoint explanation :)
nagel's algorithm is used to "wait" with sending of small packets until more
data is available, because sending biger packets has less overhead.
greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe
can someone explain what is nagle or pinpoint explanation :)
lynx
On Sun, 21 Jan 2001, 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
can someone explain what is nagle or pinpoint explanation :)
lynx
On Sun, 21 Jan 2001, 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
can someone explain what is nagle or pinpoint explanation :)
nagel's algorithm is used to "wait" with sending of small packets until more
data is available, because sending biger packets has less overhead.
greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe
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 app
> ...and I still don't understand why the identical program, but using one
> socket instead of 2 sockets, IS CPU bound, and gets on the order of
> 10K/sec. on the same HW. Diffs to produce 10K/sec. 1 socket version from
> my previous sample follow...
It's really this simple -- this
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
> It's not the select that waits. It's a delay in the tcp send
> path waiting for more data. Try disabling it:
>
> int f=1;
> setsockopt(s, SOL_TCP, TCP_NODELAY, , sizeof(f));
Bingo! With this fix, 2.2.18 performance becomes almost identical to 2.4.0
performance. I assume 2.4.0 disables Nagle
Michael Lindner wrote:
>[...]
> send(s, ".", 1, 0);
>[...]
> while (select(r+1, , 0, 0, 0) > 0) {
>[...]
>[select returns only after about 1 HZ]
Ever heard of nagle? (If not, there's a long thread about
it on the mailing list *g*)
It's not the select that waits. It's a
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
On Sat, 20 Jan 2001, Martin MaD Douda wrote:
> On Fri, 19 Jan 2001, Michael Lindner wrote:
> > data is generated as a result of data received via a select(),
> > the next delivery occurs a clock tick later, with the machine
> > mostly idle.
>
> The machine is in fact not idle - there is a task
On Fri, 19 Jan 2001, Michael Lindner wrote:
> data is generated as a result of data received via a select(),
> the next delivery occurs a clock tick later, with the machine
> mostly idle.
^^^
The machine is in fact not idle - there is a task running - idle task.
Could the problem be
In article <[EMAIL PROTECTED]> you wrote:
> My problem is that if data is NOT available when select()
> starts, but becomes available immediately afterwards, select()
> doesn't wake up immediately, but sleeps for 1/100 second.
It does not sleep for a 1/100second, it will but the process in the
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 improvement). Perhaps the
scheduler
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 improvement). Perhaps the
scheduler
In article [EMAIL PROTECTED] you wrote:
My problem is that if data is NOT available when select()
starts, but becomes available immediately afterwards, select()
doesn't wake up immediately, but sleeps for 1/100 second.
It does not sleep for a 1/100second, it will but the process in the run
On Fri, 19 Jan 2001, Michael Lindner wrote:
data is generated as a result of data received via a select(),
the next delivery occurs a clock tick later, with the machine
mostly idle.
^^^
The machine is in fact not idle - there is a task running - idle task.
Could the problem be that
On Sat, 20 Jan 2001, Martin MaD Douda wrote:
On Fri, 19 Jan 2001, Michael Lindner wrote:
data is generated as a result of data received via a select(),
the next delivery occurs a clock tick later, with the machine
mostly idle.
The machine is in fact not idle - there is a task running -
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 improvement).
Michael Lindner wrote:
[...]
send(s, ".", 1, 0);
[...]
while (select(r+1, readfds, 0, 0, 0) 0) {
[...]
[select returns only after about 1 HZ]
Ever heard of nagle? (If not, there's a long thread about
it on the mailing list *g*)
It's not the select that waits. It's a
It's not the select that waits. It's a delay in the tcp send
path waiting for more data. Try disabling it:
int f=1;
setsockopt(s, SOL_TCP, TCP_NODELAY, f, sizeof(f));
Bingo! With this fix, 2.2.18 performance becomes almost identical to 2.4.0
performance. I assume 2.4.0 disables Nagle by
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 algorithm.
...and I still don't understand why the identical program, but using one
socket instead of 2 sockets, IS CPU bound, and gets on the order of
10K/sec. on the same HW. Diffs to produce 10K/sec. 1 socket version from
my previous sample follow...
It's really this simple -- this isn't
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 app
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
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
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
> 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,
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
> 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.
If your application has scheduling requirements, you need to communicate
them to the scheduler.
> #include
> #include
>
[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
[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
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.
If your application has scheduling requirements, you need to communicate
them to the scheduler.
#include sys/time.h
#include
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 return
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
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 on
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 NT
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 for
49 matches
Mail list logo
