Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scheduling question

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 15, 2004, at 4:31 AM, Stefan Werner wrote:

Hi,

On Wednesday, Jan 14, 2004, at 22:05 Europe/Berlin, Jim Magee wrote:

There are "helper" threads that process the data within the in-kernel network code somewhat isolating your thread from directly accessing the network hardware in that way. Your realtime thread may even interfere with the responsiveness of these helper threads in ways that might affect your own data. Even if you don't interfere with the processing of the in-kernel data, your response-time characteristics are going to be dominated by the scheduling behavior of these in-kernel threads. There are also situation where the network stack just borrows another user-level thread (that just happened to be in the network stack at the time) to drive completion of your packet handling (inbound and outbound). Obviously, you can't make these all realtime threads, so that too will affect your latency.

Are there other tweaks to enhance the latency of networking? I don't mind a decrease in throughput, I'm in one of the rare cases where bandwidth is not the limit. There are these popular "bandwidth tuner" tweaks where people change the system's TCP buffer size with sysctls, would shrinking the buffers give me any latency improvements or will that result in dropped packets?

If I understand the question, you're talking about receive buffer space.

I'm not positive this answer is right, but I think a larger buffer can be used for a number of things. First, to negotiate the TCP window scaling option in which case the TCP window size can grow an additional 14 bits.

Without SACK (selective acknowledgments) this is probably somewhat useless. If your stack can negotiate a large window size (meaning the other side of the TCP has to have a somewhat similar window scale.. I think the lowest is agreed upon), then selective acknowledgments are important to ensure either side of the connection has to re-send a large amount of data if some is dropped.

The default receive window is 1/2 the size of a full TCP window... you could always try to grow it to full size.

In reality, it's a combination of things that can improve performance.

- -Jeff

- --
http://cerberus.sourcefire.com/~jeff (gpg/pgp key id 6923D3FD)
"I want to know God's thoughts... the rest are details." - Albert Einstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFADEW1Eqr8+Gkj0/0RAvC9AJ90DRHgx8PZ1pCIzHT8/W1vWwBHUwCdH5OM
+wqjZ3eIlVQUfyygnQ97+i8=
=LWtj
-----END PGP SIGNATURE-----
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: scheduling question (From: Stefan Werner <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.