Subject: Re: [linux-audio-dev] It's time to vote (n. 1)
From: Richard C. Burnett (burnett_AT_tality.com)
Date: Fri May 25 2001 - 20:29:49 EEST
Ok, I think I might be confused, but packet resending I thought was deeper
than TCP/IP, I thought it was apart of the ethernet protocol ( isn't it
802.3 or something like that ) And how it works is if there is a hardware
detected collision the NIC will wait a random amount of time before
resending. It will do this a few times and then after so many it will
just quit.
Now what about full and half duplex, if you had just two systems in full
duplex, what would happen there, you wouldn't have collisions for two
machines I don't think.
Rick
On Fri, 25 May 2001, Joe Pfeiffer wrote:
>
> Of course, you're right. Dropped packets are a problem. In TCP they get resent, so
> they can be out of order. In UDP, I think everything that arrives (*if* it ever
> arrives), arrives in order. Of course, that's part of the reason why TCP causes more
> overhead than UDP (the computer the data gets sent to, has to acknowledge having
> received the packets, and after some time, if there has been no acknowledgement,
> packets get resent etc.). But I think that it is not too bold a statement to say that
> in single segment LANs, you won't have dropped packets.
>
> I think (weak statement here) that you're right about UDP packets
> arriving in order, if at all, in a single-segment network. But I
> wouldn't want to bet on it.
>
> You can certainly have dropped packets in a single segment, if it's a
> busy single segment, or even a slow receiver.
>
> I think that collision resolving is part of the ethernet (physical access layer), so
> UDP packets always get sent without collision _once_. When they get dropped by a router
> who is flooded eg., then the packet dissapears of course... but packets don't dissapear
> because of collisions ...
>
> Collision resolution is part of the physicalor data link layer (I
> forget which); at any rate, you're right that it's handled in the
> NIC. But at some point the NIC will decide a packet just isn't going
> to make it, and gives up on trying to send it. I don't know if the
> sender gets notified about this happening (though I would certainly hope so).
>
> Also note that even when some packets get dropped, you could introduce some redundancy
> into your stream. That has a cost though (less speed) and I don't know if it would be
> feasible.
>
> What exactly is the goal of the sound-across-network? If you're
> trying to do offline editing, the vital thing is to get every bit
> across, and you want something resembling TCP. If you want real-time
> response, you need to just use a fire-and-forget protocol like UDP,
> and have the receiver interpolate if some data doesn't arrive in
> time. There's already enough error correction built in that you can
> pretty much take it for granted that if a packet arrives it's going to
> be right, so about the only way I can see to introduce redundancy
> would be to send redundant packets, which seems like a real bandwidth
> hog.
>
> I think the best way is to use a LAN, which doesn't drop packets ;). I even think that
> I would even buy seperate dedicated NICs :) (then of course, you are sure you have your
> bandwith four your audio and you don't have to fool with QoS stuff).
>
> I think somebody who was serious would do that. But most users would
> be hobbiests like me...
>
> > Even if it does turn out that packets always arrive in order in a
> > single network segment, it would be a bad mistake to assume this in a
> > protocol.
>
> Hm, I might agree.
> Of course, you could build the 'single network segment restriction' into the protocol ?
>
> I estimate 48 hours between initial release and first bug report about
> not being able to work between the CS and Music departments :)
>
> Hmmm... while packets can arrive out of order, I would guess that
> they rarely do under any reasonable circumstances. Maybe something
> like a variable-length incoming packet buffer to stuff the packets
> into as they arrive; if packets don't arrive in time to be played the
> receiver interpolates, if late packets start arriving the system
> introduces a latency to reduce their effect? (I did follow the
> earlier discussion about maximum allowable latencies, and I realize
> that this scheme would quickly get considered unacceptable if the
> network got busy. But it would provide graceful degradation...).
> --
> Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
> Department of Computer Science FAX -- (505) 646-1002
> New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
> SWNMRSEF: http://www.nmsu.edu/~scifair
>
+------------------------+-----------------------+
| T a l i t y | +------+ |
+------------------------+ +----+-+ | |
| Richard Burnett | +-+ | |
| Senior Design Engineer +---+ +----+ |
| burnett_AT_tality.com | | |
| | | |
| Phone: 919.380.3014 | |
| Fax: 919.380.3903 | | |
+------------------------------------------------+
This archive was generated by hypermail 2b28 : Fri May 25 2001 - 22:58:15 EEST