On Fri, 25 May 2001, Dan Hollis wrote:
> On Fri, 25 May 2001, Steve Harris wrote:
> > On Fri, May 25, 2001 at 03:07:08AM -0700, Dan Hollis wrote:
> > > On Fri, 25 May 2001, Steve Harris wrote:
> > > > On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote:
> > > > > If you want to network low
Actually, thinking about what I do in real life (to whatever extent a
professor is involved with real life :) ) -- mobile robots -- it seems
like there's a real need for a network protocol doing low latency,
timestamped data over unreliable transports. Audio is an example
application, so is robot
> What about using UDP instead of TCP/IP? I don't know a whole lot about
> networking, but I do know that jMax uses UDP for interprocess
> communication, and I know some people who have experimented with audio
> over UDP for real-time work.
jMax actually includes a UDP audio device. It's the
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 bef
On Fri, 25 May 2001, Steve Harris wrote:
> Sorry, I thought ATM refered to the fibre too. There *are* a lot of people
> throwing out ATM kit, because Newbridge's ATM customers have found
> themselves with unsupported hardware, and the company that bought
> Newbridge (can't remember who) is virtual
On Fri, May 25, 2001 at 10:51:24AM -0700, Dan Hollis wrote:
> > That said, for single point-to-point streams it might be OK, I might
> > borrow some of the ATM hardware when it gets checked and test it. There
> > must be loads of businesses throwing it out around now, but its kinda
> > large, you
On Fri, 25 May 2001, Steve Harris wrote:
> On Fri, May 25, 2001 at 03:07:08AM -0700, Dan Hollis wrote:
> > On Fri, 25 May 2001, Steve Harris wrote:
> > > On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote:
> > > > If you want to network low-latency audio I think you must find a network
>
>[cut]
>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 inter
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
resendin
On Fri, 25 May 2001, Joe Pfeiffer wrote:
>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 p
Hear, hear. Ethernet just isn't designed to send low latency streams.
Agree completely. But a project with a ``you must use Myrinet''
requirement isn't going to see much use. Better to build a protocol
that will work really, really well with a reliable physical layer, and
will degrade grace
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
On Fri, May 25, 2001 at 09:04:06AM -0400, rob wrote:
>
> http://oss.sgi.com/projects/stp/
>
> they apparently use irix and gigE to get < 10us latency. (although it
> is unclear what that number really means).
Isn't that <10us latency over GSN? I couldn't see any latency figures for
gig etherne
On Fri, May 25, 2001 at 03:07:08AM -0700, Dan Hollis wrote:
> On Fri, 25 May 2001, Steve Harris wrote:
> > On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote:
> > > If you want to network low-latency audio I think you must find a network
> > > solution with a reliable physical layer.
> >
recently i added another stack that did streamed stuff over ethernet for
this sort of thing. it seems to be workable. i also found this which
seemed promising:
http://oss.sgi.com/projects/stp/
they apparently use irix and gigE to get < 10us latency. (although it
is unclear what that number r
On Fri, 25 May 2001, Steve Harris wrote:
> On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote:
> > If you want to network low-latency audio I think you must find a network
> > solution with a reliable physical layer.
> Hear, hear. Ethernet just isn't designed to send low latency streams.
On Fri, May 25, 2001 at 09:03:53AM -0700, Vincent Touquet 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 reaso
On Thu, May 24, 2001 at 01:03:51PM -0400, David G Matthews wrote:
> What about using UDP instead of TCP/IP? I don't know a whole lot about
> networking, but I do know that jMax uses UDP for interprocess
> communication, and I know some people who have experimented with audio
> over UDP for real-t
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 anoth
On Fri, May 25, 2001 at 10:15:05AM +0100, Iain Sandoe wrote:
> 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
On Fri, May 25, 2001 at 09:29:37AM +0200, Adriaan Pelzer wrote:
> Sounds good...
>
> Only danger with UDP is when you have a bottleneck somewhere (receiving side
> slower than sending side) you might drop packets.
> Don't think it will be a problem with audio though...
>
> I've played with the l
On Thu, May 24, 2001 at 04:52:26PM -0400, Taybin Rutkin wrote:
> On Thu, 24 May 2001, Darwin Marcus Johnson wrote:
>
> > > Collisions. The packets back off (exponentially I think) so they can get
> > > shuffled easily.
> > >
> > > There is more going on over ethernet than you think.
> > >
> > cou
Sounds good...
Only danger with UDP is when you have a bottleneck somewhere (receiving side
slower than sending side) you might drop packets.
Don't think it will be a problem with audio though...
I've played with the libnet libraries (allow you to build raw packets) but I
think what we need here
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 me
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 af
On Thu, 24 May 2001, Darwin Marcus Johnson wrote:
> > Collisions. The packets back off (exponentially I think) so they can get
> > shuffled easily.
> >
> > There is more going on over ethernet than you think.
> >
> could this be avoided using two interfaces, and no hub?
It seems to me that the p
Steve Harris wrote:
> > my understanding is that when packets get routed via different
> > paths, they might become shuffled, but not on a static route.
>
> Collisions. The packets back off (exponentially I think) so they can get
> shuffled easily.
> There is more going on over ethernet than you
The protocol they use in Disneyland is a protocol over ethernet developed by
Peak Audio (TM).
Homepage: http://www.peakaudio.com/CobraNet
Some place where you can hear their stuff:
http://www.peakaudio.com/CobraNet/Installations
Note that indeed using TCP on a local LAN is an overkill for this st
> -Original Message-
> From: David G Matthews [mailto:[EMAIL PROTECTED]]
>
> What about using UDP instead of TCP/IP? I don't know a whole
udp instead of tcp. both udp and tcp are part of tcp/ip (along with ip,
icmp, ...)
erik
> lot about
> networking, but I do know that jMa
Jorn Nettingsmeier
Steve Harris wrote:
> Also remeber you have to reassemble the packets in the right order as the
> ordering is not guaranteed.
forgive my ignorance wrt networks, but what can change the original
order of packets in a point-to-point link ?
my understanding
On Thursday 24 May 2001 13:21, Steve Harris wrote:
> On Thu, May 24, 2001 at 06:03:30PM +0200, Jörn Nettingsmeier wrote:
> > > Also remeber you have to reassemble the packets in the right order as
> > > the ordering is not guaranteed.
> >
> > forgive my ignorance wrt networks, but what can change
What about using UDP instead of TCP/IP? I don't know a whole lot about
networking, but I do know that jMax uses UDP for interprocess
communication, and I know some people who have experimented with audio
over UDP for real-time work. AFAIK it's a little less reliable than
TCP/IP, but gives lower
On Thu, May 24, 2001 at 06:03:30PM +0200, Jörn Nettingsmeier wrote:
> > Also remeber you have to reassemble the packets in the right order as the
> > ordering is not guaranteed.
>
> forgive my ignorance wrt networks, but what can change the original
> order of packets in a point-to-point link ?
>
Steve Harris wrote:
>
> On Thu, May 24, 2001 at 01:53:56PM +0200, Jörn Nettingsmeier wrote:
> > > Over ethernet it seem to be only the first packet that is slow, probably
> > > depends on the make of switch though. Unswitched private networks should
> > > be fine. But as Paul said these times are
On Thu, May 24, 2001 at 08:22:43AM -0600, Joe Pfeiffer wrote:
> (delurking momentarily)
>
> I also get round-trip latencies much better than 4 msec -- I rarely
> see anything over 1 msec on my 10BaseT system at home, and typically
> much better than that. Here's a short log:
ping doesn't really
On 2001-05-24 13:53 +0200, Jörn Nettingsmeier wrote:
> even if larger switched networks are unusable, it would still be a
> nice option to be able to connect two audio boxen via a dedicated
> 100mb ether network to use their combined power for audio
> applications.
> at 20 US$ per card and 10$ fo
Steve wrote:
>
> On Wed, May 23, 2001 at 07:25:37PM -0400, Paul Davis wrote:
> > >> I'm just wondering, since I'm getting a .7 ms roundtrip time when
> > >> pinging my other Linux system here, which is connected to this one
> > >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number
>
On Thu, May 24, 2001 at 01:53:56PM +0200, Jörn Nettingsmeier wrote:
> > Over ethernet it seem to be only the first packet that is slow, probably
> > depends on the make of switch though. Unswitched private networks should
> > be fine. But as Paul said these times are too slow to be useful.
>
> ar
Steve Harris wrote:
>
> On Wed, May 23, 2001 at 07:25:37PM -0400, Paul Davis wrote:
> > >> I'm just wondering, since I'm getting a .7 ms roundtrip time when
> > >> pinging my other Linux system here, which is connected to this one
> > >> by 100 Mbps ethernet through a 100 Mbps switch. Is that nu
Paul Davis wrote:
>
> >> I'm just wondering, since I'm getting a .7 ms roundtrip time when
> >> pinging my other Linux system here, which is connected to this one
> >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number
> >> for real? Because it seems almost too good.
> >
> >I get 15
On Wed, May 23, 2001 at 05:31:59PM -0700, Dan Hollis wrote:
> Worst case latency was 4.973msec and average was 1.195msec. Thats round
> trip mind you.
>
> This is all super-cheap-ass hardware, too. The PCI 100bt cards are $15/ea
> and the 24 port full duplex switch was $400.
>
> I seem to recall
On Wed, May 23, 2001 at 07:25:37PM -0400, Paul Davis wrote:
> >> I'm just wondering, since I'm getting a .7 ms roundtrip time when
> >> pinging my other Linux system here, which is connected to this one
> >> by 100 Mbps ethernet through a 100 Mbps switch. Is that number
> >> for real? Because it
On Wed, 23 May 2001, Paul Davis wrote:
> >I get 150-250usec (yes, microseconds) roundtrip through 100mbps switch.
> is this on a previously quiescent connection (TCP or UDP) ? my
> impression is that once things get rolling round trip times are pretty
> good, but that moving a packet or two when t
> I'm just wondering, since I'm getting a .7 ms roundtrip time when
> pinging my other Linux system here, which is connected to this one
> by 100 Mbps ethernet through a 100 Mbps switch. Is that number
> for real? Because it seems almost too good.
Yes it is -- see the Stanford-Berkeley RTT's in
>> I'm just wondering, since I'm getting a .7 ms roundtrip time when
>> pinging my other Linux system here, which is connected to this one
>> by 100 Mbps ethernet through a 100 Mbps switch. Is that number
>> for real? Because it seems almost too good.
>
>I get 150-250usec (yes, microseconds) rou
On Wed, 23 May 2001, Jay Ts wrote:
> I'm just wondering, since I'm getting a .7 ms roundtrip time when
> pinging my other Linux system here, which is connected to this one
> by 100 Mbps ethernet through a 100 Mbps switch. Is that number
> for real? Because it seems almost too good.
I get 150-25
>
> > Now this is what we call an imagination! I hope not to imply a
> > daydream, though. Buy this man a drink!
>
> No one can accuse me of setting other people's goals too low :)
Since we are having fun dreaming, I've been wondering about
how much latency is in 100 Mbps or 1 Gbps networking
> Now this is what we call an imagination! I hope not to imply a
> daydream, though. Buy this man a drink!
No one can accuse me of setting other people's goals too low :)
Tom
48 matches
Mail list logo
