Subject: Re: [linux-audio-dev] It's time to vote (n. 1)
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Fri May 25 2001 - 12:15:05 EEST
Vincent Touquet wrote:
> Joe Pfeiffer wrote:
>
>> Hm, but the packets get sent in order, don't they ?
>> So when there is a collision, the ethernet card waits to resend the
> packet for
>> which a collision happened, for some random time (exponentially increasing
in
>> case of another collision). But that cannot mean, that a packet that is
after
>> this packet in the queue, gets sent before this very packet is
> succesfully sent,
>> or is it ?
>>
>> Please explain more if I'm wrong.
>>
>> That corresponds to my understanding, though I could easily be wrong.
>> I think the scenario I suggested -- packets could get out of order due
>> to a dropped packet -- is possible, though.
>
> 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 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 ...
>
> 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.
>
> 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 don't think it's as simple as this. IP over ethernet (or elsewhere AFAIK)
is fundamentally (by design) an "unreliable physical layer" protocol (which
IMHO makes it unsuitable for low latency audio - although totally
satisfactory for streaming).
You will be back to the flame war about "how much low latency, and for what
percentage of the time, must we guarantee" in a few mails time ;-))) It
will work some of the time of course - but it will *never* be guaranteed.
The drivers & network stack are perfectly at liberty to drop packet
fragments that have been successfully received - for example, if there are
no mbufs available. I have seen network stacks (not looked at the linux
ones, I admit) that regularly do this.
If you want to network low-latency audio I think you must find a network
solution with a reliable physical layer.
my 0.02 euro ;-)
Iain.
This archive was generated by hypermail 2b28 : Fri May 25 2001 - 14:28:57 EEST