This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about ecos server performance


On Tuesday 13 August 2002 07:04, Gary Thomas wrote:
> On Tue, 2002-08-13 at 08:03, NavEcos wrote:
> > [SNIP]
> >
> > > > The bug is as follows:
> > > >
> > > > 1) The server (eCos app) starts,
> > > > 2) Connect to the server with telnet, port 4000
> > >
> > > Then what?  What do you have to do [from the "client" side] to
> > > evoke the crash?
> >
> > Connect.  That's all.  My crash happens in less than 3000 bytes
> > of transferred data, always.
> >
> > If you want, I can send you my entire environment but before I
> > do that I'll update CVS.  Maybe it was a bad day when I downloaded?
>
> No, I was able to duplicate this.  I just asked before trying it as
> I didn't want to waste time if there was more that was necessary.
>
> The problem is obvious and, indeed, the program tells you exactly why.
> It's reporting "too many mbufs to tx", which comes from the logical
> network layer which tries to pack up a packet to be sent and give it
> to the physical driver.  However, in this case, the data structure which
> represents the packet has [perhaps] hundreds of little tiny pieces in
> it.  The method used by the physical layer can't handle that
> [currently].  I'll have to think a bit about how to fix this.

Well, the documentation states that running out of mbufs will not
crash the TCP/IP layer.  Why does it?  I suspected that it was
because there were a bunch of tiny pieces but I didn't debug it.  I
did see the error message, of course, and assumed they may be linked.
I probably should have mentioned that.

Maybe incorporating a counting semaphore to cause threads allocating
mbufs to block would do it?  I am not sure how much overhead there
would be in doing that, but it would nicely block the threads when there
were no more mbufs.

> I would say that this is a aberrant program though and just happened to
> run into this limitation.

Well, I agree, it's an atypical example but it's still a serious problem
when you can crash it for whatever reason.  The code is legal.

I don't care about performance for such a program, what and I do not
think ANYBODY would writing awful code like that.  But what concerns
me is that the stack crashes.  There are instances in which you may
get a bunch of small packets being sent.

For example, say you have a profiler that sends out the PC at the
time of an interrupt at regular intervals.  If you get the interval
just right, you'll crash the box.  You may do this as a low priority
thread too that sends all available data.  In a quiet system, it will
end up sending 4 bytes almost always.

Thank you,
-Rich

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]