| David Schwartz 2008-03-20, 10:13 pm |
| On Mar 20, 4:44 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> What does the scheduler have to do with this?
The scheduler determines when the process runs after it is made ready-
to-run by reception of the first datagram.
> He's not talking about
> process switches, he's talking about context switches between user and
> kernel mode when calling recvfrom().
When you make a call into the kernel, the largest component of the
time it takes will be time spent running other processes (if any are
chosen to run).
> There is overhead when going into and out of the kernel, but in this
> case there's nothing you can do about it. There's no system call for
> getting the datagrams that have been buffered all at once.
You are right, but there are two separate issues. One is how long will
the receive function take if another process is scheduled, another is
how long it will take if not.
It's hard to know exactly what the OP is thinking here. But a modern
CPU can easily do millions of system calls per second. So unless he's
processing a *lot* of packets, the overhead due to switching into
kernel space should be tolerable. I just benchmarked my dual P3-1Ghz
system -- it can do 7,000,000 system calls per second. System call
latency is much less than a microsecond.
I was thinking his main issue was that his program would run every
time a packet was received, thus increasing process churn on his
system resulting in poor performance both for him and everyone else.
If his sole concern was number of system calls, yeah, there's nothing
he can do about that.
DS
|