"Bandwidth" of loopback interface?

"Bandwidth" of loopback interface?

Post by Penguin Novea » Sun, 25 May 2003 06:11:16



I need a very fast IPC channel between two processes.  One draws packets
from the network, and the other analyzes them.  

My first thinking is that I'd like them to be decoupled so I minimize
the chance of packets being dropped by the packet grabber (although that
might be a brain dead decison--see [2] below).

Anyway, I'm wondering two things:  

1) Is there way to check for a bandwidth limit on a loopback (PF_UNIX)
socket?

2) Does using socket based IPC exhaust network packet buffers?  If so,
I'd be exacerbating the very problem I'm trying to avoid by using
socket-based IPC.

Checking Stevens TCP v2 now...

RH 9 Intel, kernel 2.4.  Not married to this OS, though, in case a
different *u*x behaves better for this application.

--
"Power tends to confuse itself with virtue..." - J. William Fulbright

 
 
 

"Bandwidth" of loopback interface?

Post by Fritz » Sun, 25 May 2003 06:28:48



> My first thinking is that I'd like them to be decoupled so I minimize
> the chance of packets being dropped by the packet grabber (although
> that might be a brain dead decison--see [2] below).
> 2) Does using socket based IPC exhaust network packet buffers?  If so,
> I'd be exacerbating the very problem I'm trying to avoid by using
> socket-based IPC.

Do you have to do socket-based IPC?   It depends on the characteristics
of your messaging, but any other form of IPC would be faster than using
the loopback interface.

RFM
--
To reply, translate domain from l33+ 2p33|< to alpha.
                4=a  0=o  3=e  +=t

 
 
 

"Bandwidth" of loopback interface?

Post by Eric Sosma » Sun, 25 May 2003 06:29:08



> I need a very fast IPC channel between two processes.  One draws packets
> from the network, and the other analyzes them.

> My first thinking is that I'd like them to be decoupled so I minimize
> the chance of packets being dropped by the packet grabber (although that
> might be a brain dead decison--see [2] below).

> Anyway, I'm wondering two things:

> 1) Is there way to check for a bandwidth limit on a loopback (PF_UNIX)
> socket?

> 2) Does using socket based IPC exhaust network packet buffers?  If so,
> I'd be exacerbating the very problem I'm trying to avoid by using
> socket-based IPC.

    Why use a network stack at all?  Can't you use a pipe?
Or shared memory?  Either ought to have less baggage than
you'll need to carry all the way down the network stack
and back up again.

--

 
 
 

"Bandwidth" of loopback interface?

Post by Greg Menk » Sun, 25 May 2003 08:01:52



> I need a very fast IPC channel between two processes.  One draws packets
> from the network, and the other analyzes them.  

> My first thinking is that I'd like them to be decoupled so I minimize
> the chance of packets being dropped by the packet grabber (although that
> might be a brain dead decison--see [2] below).

> Anyway, I'm wondering two things:  

> 1) Is there way to check for a bandwidth limit on a loopback (PF_UNIX)
> socket?

> 2) Does using socket based IPC exhaust network packet buffers?  If so,
> I'd be exacerbating the very problem I'm trying to avoid by using
> socket-based IPC.

> Checking Stevens TCP v2 now...

If bandwidth is the issue and you can keep the receiver and analyzer
in the same process, you might find its easier to assign a thread to
each task and use a mutex or semaphore to serialize access to whatever
application level queue you end up employing.  The fewer times you
have to copy the packets around the better.

You can easily test the loopback throughput yourself, just write 2
programs, one that sends udp packets of some useful size just as fast
as it can and the other to receive them.

But wrt the stack, if you get the packets out pretty much as fast as
they come in, then you won't have packets dropped due to buffer
exhaustion.  loopback will be lots faster than an ethernet interface,
but as others have pointed out, its going to be quite slow compared to
other ipc mechanisms.

Gregm

 
 
 

"Bandwidth" of loopback interface?

Post by Penguin Novea » Sun, 25 May 2003 13:49:41




> > I need a very fast IPC channel between two processes.  One draws packets
> > from the network, and the other analyzes them.

> > My first thinking is that I'd like them to be decoupled so I minimize
> > the chance of packets being dropped by the packet grabber (although that
> > might be a brain dead decison--see [2] below).

> > Anyway, I'm wondering two things:

> > 1) Is there way to check for a bandwidth limit on a loopback (PF_UNIX)
> > socket?

> > 2) Does using socket based IPC exhaust network packet buffers?  If so,
> > I'd be exacerbating the very problem I'm trying to avoid by using
> > socket-based IPC.

>     Why use a network stack at all?  Can't you use a pipe?

I thought of that, but aren't they limited to some relatively small
size, though?

Quote:> Or shared memory?  Either ought to have less baggage than
> you'll need to carry all the way down the network stack
> and back up again.

Good point.  Feeling dumb here.  Shared memory or embedding the analysis
into the capture code is probably the way to go.

--
"Power tends to confuse itself with virtue..." - J. William Fulbright

 
 
 

"Bandwidth" of loopback interface?

Post by Penguin Novea » Sun, 25 May 2003 13:54:02




> > My first thinking is that I'd like them to be decoupled so I minimize
> > the chance of packets being dropped by the packet grabber (although
> > that might be a brain dead decison--see [2] below).

> > 2) Does using socket based IPC exhaust network packet buffers?  If so,
> > I'd be exacerbating the very problem I'm trying to avoid by using
> > socket-based IPC.

> Do you have to do socket-based IPC?   It depends on the characteristics
> of your messaging, but any other form of IPC would be faster than using
> the loopback interface.

Don't have to use sockets-based IPC.  It would be about the easiest for
me to implement, and I'd like to have the analysis section done in a few
weeks so the less time on IPC the better.  At least for the first cut.

--
"Power tends to confuse itself with virtue..." - J. William Fulbright

 
 
 

"Bandwidth" of loopback interface?

Post by Penguin Novea » Sun, 25 May 2003 13:57:53




> > I need a very fast IPC channel between two processes.  One draws packets
> > from the network, and the other analyzes them.  

> > My first thinking is that I'd like them to be decoupled so I minimize
> > the chance of packets being dropped by the packet grabber (although that
> > might be a brain dead decison--see [2] below).

> > Anyway, I'm wondering two things:  

> > 1) Is there way to check for a bandwidth limit on a loopback (PF_UNIX)
> > socket?

> > 2) Does using socket based IPC exhaust network packet buffers?  If so,
> > I'd be exacerbating the very problem I'm trying to avoid by using
> > socket-based IPC.

> > Checking Stevens TCP v2 now...

> If bandwidth is the issue and you can keep the receiver and analyzer
> in the same process, you might find its easier to assign a thread to
> each task and use a mutex or semaphore to serialize access to whatever
> application level queue you end up employing.  The fewer times you
> have to copy the packets around the better.

That's a very good point.

Quote:> You can easily test the loopback throughput yourself, just write 2
> programs, one that sends udp packets of some useful size just as fast
> as it can and the other to receive them.

> But wrt the stack, if you get the packets out pretty much as fast as
> they come in, then you won't have packets dropped due to buffer
> exhaustion.  loopback will be lots faster than an ethernet interface,
> but as others have pointed out, its going to be quite slow compared to
> other ipc mechanisms.

Considering everything, I'll probably use shared memory both as an app
buffer space of sorts, and an IPC mechanism.

I appreciate all your suggestions...it's nice to be doing this work
again, but after three years away from it I'm still shaking the rust
off.  You should see me fumbling around with gdb.  It's embarrassing.

--
"Power tends to confuse itself with virtue..." - J. William Fulbright

 
 
 

"Bandwidth" of loopback interface?

Post by Ed L Cashi » Mon, 26 May 2003 02:03:54


...

Quote:> You can easily test the loopback throughput yourself, just write 2
> programs, one that sends udp packets of some useful size just as fast
> as it can and the other to receive them.

netcat is great for this kind of thing.  

--
--Ed L Cashin     PGP public key: http://noserose.net/e/pgp/