• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: TCP speed versus busy processes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TCP speed versus busy processes


  • Subject: Re: TCP speed versus busy processes
  • From: "Philip D. Wasson" <email@hidden>
  • Date: Wed, 20 Aug 2003 16:50:43 -0400

On Wednesday, Aug 20, 2003, at 04:15 US/Eastern, Quinn wrote:

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 two CPU-using SETI processes were each using about 70-90% of a CPU. My app was using between 3% and 20% depending, I guess, on when TOP sampled and whether my app was processing data or waiting for it at that moment.

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.

Actually, two instances of the SETI command-line tool are launched by cron for the root user. More accurately, cron runs /bin/sh, passing it a compound command that changes the working directory and then runs setiathome. The sh instances have Nice level 0 and Priority 31; the setiathome instances have Nice 20, as specified in their command-line arguments, and a variable Priority (I've seen 0, 11, and 6 so far); and my app has Nice 0 and Priority 46. (I don't know anything about Priority; the man pages I could find seemed to just talk about the Nice level, and the Darwin Kernel Programming book skirted the issue without telling me what the relationship is between Priority and Nice level.)


----------------------------------------
Philip D. Wasson
email@hidden
_______________________________________________
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.

  • Follow-Ups:
    • Re: TCP speed versus busy processes
      • From: Quinn <email@hidden>
References: 
 >Re: TCP speed versus busy processes (From: Quinn <email@hidden>)

  • Prev by Date: Re: Retrieving Adapter information
  • Next by Date: CFSocket and kCFRunLoopDefaultMode
  • Previous by thread: Re: TCP speed versus busy processes
  • Next by thread: Re: TCP speed versus busy processes
  • Index(es):
    • Date
    • Thread