Re: TCP speed versus busy processes
Re: TCP speed versus busy processes
- Subject: Re: TCP speed versus busy processes
- From: Quinn <email@hidden>
- Date: Wed, 20 Aug 2003 09:15:44 +0100
At 18:45 -0400 18/8/03, Philip D. Wasson wrote:
Now, I would think that with my client at nice level 0 and SETI at
nice 19, SETI really should have the CPU taken away from it as soon
as e.g my recv operation is complete, so it shouldn't slow my client
down much. But it does. Is that just due to scheduling overhead and
there's nothing I can do about it?
That's weird. You're right in that a low-priority CPU-bound process
should be immediately suspended upon network activity in a higher
priority I/O-bound process. The first thing I'd do is run "top" and
check that the CPU is all going to SETI. The next thing I'd do is
run the following command line
% ps -j -ww -U `whoami` -M | bbedit
and look at the priority of each thread you're running. Normal
priority for a GUI thread is in the 40s. Normal priority for a
non-GUI thread is 31. Make sure that your network threads have
higher priorities than your SETI threads.
Hmmm, that raises the question of whether SETI is a GUI application?
If so, it starts off with higher priority than all non-GUI
applications. "nice" may not have enough power to lower the priority
of SETI sufficiently. Certainly worth investigating. Let me know
what you see and I'll pontificate some more (-:
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.