Re: Network stack/ethernet driver issues
Re: Network stack/ethernet driver issues
- Subject: Re: Network stack/ethernet driver issues
- From: Bakul Shah <email@hidden>
- Date: Thu, 10 Apr 2008 08:39:30 -0700
On Thu, 10 Apr 2008 09:45:14 EDT Michael Cashwell <email@hidden> wrote:
> On Apr 9, 2008, at 8:58 PM, William Kucharski wrote:
>
> > email@hidden wrote:
> >
> >> If frequently dropping packets with only 40% of the available
> >> bandwidth being utilized and no load on the machine other than an
> >> application listening for and peeking at the contents of said
> >> packets is considered OK then I will stick to Linux for my low
> >> latency, high bandwidth network applications (and encourage others
> >> to do likewise).
> >
> > UDP can drop as many packets as it wants to, that's why it's UDP.
>
> Incorrect. You are conflating non-retry with low Quality-of-Service.
> They are independent things.
>
> Very often UDP is used for data that are time-sensitive where retrying
> (even if successful) would result in the data arriving late enough as
> to be useless. Using UDP does not mean the data are less important
> than TCP data. It just means that retries are not useful.
>
> In fact, UDP data (consider live video conferencing) is often given a
> HIGHER Quality of Service level specifically because retrying them is
> not an option. If a router along the way is congested it might
> preferentially drop a low-QoS TCP packet (since it's not real-time and
> can be more easily recovered) than a high-QoS UDP one.
>
> The point in rimas' case is that just because the data are UDP does
> not give the Ethernet driver more permission to drop them than if they
> were UDP nor does it mean they are less important.
It is a quality of implementation issue (not service) but in
general if you expect that *no* packet will be dropped,
_expect_ to be disappointed! Even if a single ethernet
switch is in the middle, a burst of traffic from another
sender will force the *switch* to drop your packets.
Similarly if the machine you are sending to runs out of
resources, it will drop packets. Even simpler, a packet will
be dropped if it has a bad ethernet CRC or bad IP checksum
and this can happen for all sorts of reasons. As RFC 768
(User Datagram Protocol) says,
Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control
Protocol (TCP)
Assuming the other person wants a working solution now, the
easiest solution may be to stick a fast enough but hopefully
inexpensive FreeBSD/linux box with two GbE ports in the
middle to convert his UDP stream to a TCP stream and feed it
to a box that can sustain a 50MBps writing speed to its disk
-- which will be the next thing he will discover his MacBook
Pro can't do :-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden