Re: Thread Priority?
Re: Thread Priority?
- Subject: Re: Thread Priority?
- From: Terry Lambert <email@hidden>
- Date: Fri, 21 Sep 2007 14:01:36 -0700
On Sep 21, 2007, at 10:26 AM, Basavaraj wrote:
Hi,
I also get this problem. Apple, please suggest some solution to this
problem.
Why reading data on network sometimes take more time than usually.
In my case it is very critical, server drops video and audio packets
if client don't receive in allowed time.
Problem is more prominent in Linux and Mac OS X, but in Windows, it
just works fine.
If we launch or do some operation on some cpu intensive application
or simple X11 apps, then problem is more frequent.
Problem is not because of receiving data. I saw tcp dump on
Ethereal, actual problem is with TCP acknowledgment.
Acknowledgments are not going immediately after receiving packets.
Disabling Naggle algorithm didn't helped.
Please help any one or Apple.
You are aware that TCP ACKs are not sent as a direct result of the
receive interrupt, right?
Data comes into the PHY, the ethernet chip DMAs the data into
preallocated mbufs in physical memory for which there is a
preestablished kernel virtual address space mapping, and then the mbuf
data is put on a ring buffer, and a condition "data available" is
signalled. Then the interrupt is ACKed, and processing at interrupt
level is done.
At that point, you wait for the scheduler to run the receive thread,
which dequeues the data out of the ring buffer and feeds it to
ether_input, which eventually calls ip_input, which in turn calls
tcp_input, which does the TCP protocol processing.
At some point in the protocol processing, TCP decides that the window
is no longer full, and then decies to send an ACK via ip_output.
ip_output queues the data onto the send ring buffer, and signals the
ethernet driver that there is data to put in the DMA area with a
descriptor so that the DMA engine on the chip will take it and send it.
Assuming that the ACK is eventually sent without the data being
retransmitted, it's possible that the receive window won't be
advertised for some time (and the ACK sent) if:
- You have a thread which is higher priority than the thread dequeuing
the data from the receive ring to ether_input; for example, perhaps
someone is running a thread at a higher real time priority than the
thread servicing the queue.
- The receive data buffer in the socket (so_rcv) is full because the
user space program has not emptied it in a while, because the user
space process has not been scheuled to run; for example, perhaps
someone is running a thread at a higher real time priority than the
thread in the process servicing the socket receive queue.
- Some other unforseen latency
=
In general, people who design protocols for transferring data over
network links take latency into account in their designs, and buffer
more data than they will need "if everything goes right", in case it
doesn't. This means that there is data available, and there is no
"skipping" or "freezing", because they have enough data available to
continue processing data even if the network data is refilling those
buffers at a variable rate.
In technical terms, this is called "pool retention time", and it's
part of standard queueing theory. It's the same reason thatt by the
time McDonalds gets you your food on a tray, no matter how busy they
are, there's a place for you to sit down and eat it.
The classic example is a bucket that is being filled from the top at
some average rate which in any given time slice is inconsistent, but
which has a hole in the bottom whic causes it to drain at a constant
rate. The question that is generally posed is "what is the minimum
amount of water I have to put in the bucket before I unplug the hole
in the bottom to ensure that there is a constant stream of water
cominf from the hole?".
Your protocol needs more water in its bucket.
=
It's possible to overcome all of these issues for a network protocol,
of course, but then what you've built is a network protocol processor,
rather than a general purpose computer, and everything that's not
networking loses in any contention for resources between it and the
networking.
I highly recommend:
TCP/IP Illustrated, Volume 2
Gary R. Wright and W. Richard Stevens
Addison-Wesley Professional
ISBN 978-0201633542
and:
Elements of Network Protocol Design
Mohamed G. Gouda
Wiley-Interscience
ISBN 978-0471197447
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden