click perform effects with respect to RAM

[Brecht Vermeulen]

Hi Will,

okay, I see, some other ideas (I can be totally wrong but I'm sure that
Eddie will correct me if I am).

(for the record, we have only experience with the Etherpro 1000 SX
(fibre) versions)

> > can you maybe try with a full-blown router (make-ip-conf.pl) to see what
> > it says ? (you seem to split on subnets so this should work also I
> > think)
> 
> I gave this a quick and dirty shot, but it seems to be complaining.
> This is less than idle because it really shouldn't be thinking about
> ARP responses and things like that.  I just want a dumb box that
> passes packets quickly.  I'll mess more later and get back to you if
> nothing else works.
> 

well, you could also use EtherEncap instead of the ARPQuerier elements
and drop the ARPResponders. (the idea was that we had once a specific
configuration and if we moved a counter element after a
(self-developped) element instead of before the performance was
different, I never found the exact reason for this)

> >
> > How big are the packets you are generating ? and what do you use to
> > generate packets ? (sorry if it was already mentioned in the thread)
> > Have you tried to generate less packets and see when the output matches
> > the input ?
> >
> 
> This is a live data stream so packets are unpredictable in every way you
> can imagine.  It's not really possible for us to modulate the size of the
> stream.

How do you know the exact number of the packets generated ? 

Can you maybe use another machine to generate packets with click (e.g.
with fastudpsrc or so) ? (we use a Smartbits for this, so I'm not
experienced with these). This would give you control about the packet
size and rates.

> 
> > Maybe you can add a 'ThreadMonitor' element in your configuration to
> > have a look at the scheduling ?
> >
> 
> Doesn't seem to be something I can do.  click-install gives me this:
> 
> click.conf:5: While configuring `ThreadMonitor at 2 :: ThreadMonitor':
>   ThreadMonitor requires multithreading
> 
> Router could not be initialized!
> 
> Perhaps the fact that I can't even ThreadMonitor indicates the problem?
> Could my lack of multithreading be the issue?  Hrmm
> 

Well, if the machine is single-CPU, you cannot use multithreading click.
So this is not the reason, I didn't know that ThreadMonitor didn't work
with single-threaded click. (it gives CPU cycles per scheduled click
element and I thought maybe learning something more about which elements
do most of the work)

> > Which kernel do you use ?
> >
> 
> I'm using 2.4.18.  It's got SMP compiled in even though my box is single
> process, dunno if that matters.
> 

I don't know about the SMP compiled in. (but you had to compile a new
kernel with the click patch, can you compile a kernel without SMP to be
sure ?)

Regarding the 2.4.x kernels: we had a performance problem with 2.4.9
kernel (http://www.pdos.lcs.mit.edu/click/ml/click/msg00977.html) which
I thought was a well-known issue in the 2.4.x kernels, but I thought it
was solved already, I'm not sure. We still use 2.2.19.

> > Do you mean that the two ports are simply connected to each other ?
> > If not, what exactly are they connected to ?
> >
> 
> Yes, they are connected to one another.  There is no device between.  Any
> packets transmitted on will then be received by the other via the
> PollDevice elements that are in place.  Could this be a problem?  This
> effectively makes click see every packet twice.  I might try to find some
> hardware I can hook up downstream so that this won't happen.
> 

have you tried to just not configure the 3rd interface in linux. I think
the MAC addresses of the packets arriving will not match the interface
itself, so normally it will not put any load on the machine (if the
third interface is not in promiscuous mode), but if click has to poll
the interface and transfer some packets, it puts load of course.
Maybe if the 3rd interface isn't configured in linux it will be better ?
(e.g. not generate any interrupts ?)
(this is with the simple Poll->counter->queue->todevice configuration of
course)

BTW, in that simple configuration, does PollDevice/packets handler and
todevice/packets differ ? Does the queue show a lot of drops ?

Of course, connecting it to a card in another PC will give certainty.

> Tx_Dropped                       177186736

never had these before.

> Rx_FIFO_Errors                   1835326
> Rx_Missed_Errors                 1835326

I think these are caused by the PC not reading the packets fast enough
from the NICs, but not sure.

regards,
Brecht