Re: [ECOS] Question about ecos server performance

[NavEcos <ecos at navosha dot com>]

On Tuesday 13 August 2002 06:10, Gary Thomas wrote:
> On Tue, 2002-08-13 at 02:55, NavEcos wrote:
> > On Tuesday 13 August 2002 00:41, Andrew Lunn wrote:
> > > On Mon, Aug 12, 2002 at 01:54:38PM -0700, NavEcos wrote:
> > > > I have a customer that is interested in running eCos as an embedded
> > > > server.  He asked me how well eCos would handle up to1000
> > > > simultaneous IP (both TCP and UDP) connections and I couldn't
> > > > answer his question.
> > > >
> > > > Does anybody have similar experience?  For example a webserver or
> > > > a file server being under high stress with eCos at the core?
> > >
> > > To me eCos seems a strange choice. Something that can support 1000
> > > connections, is probably going to have a lot of memory and a fast
> > > processor. A linux based system sounds more appropriate. I would talk
> > > to your customer and find out more about the application.
> >
> > They are building it around an XScale.  I know it sounds strange to
> > have so many connections, but it makes sense for what he's doing.
> > The other option is embedded Linux which I'm researching.
> >
> > > The stacks are unix stacks, so should handle these number of
> > > connections. You will have to fiddle with the configuration a bit. Few
> > > embedded system need more than 32 sockets etc and each on takes
> > > memory. The default configuration will not support 1000. Select only
> > > supports 256 sockets, but that is a compile time option. The total
> > > number of file descriptors will also need expanding, but that again is
> > > a configuration option. I expect there are others which you won't find
> > > till you try it.
> >
> > I'll check the configtool for the options.  He may want to use another
> > TCP/IP stack (proprietary) too.  I am just talking to him at this point.
> >
> > > With some work, it should run. We run our devices at high CPU load
> > > without a problem, so that should also not be a problem either.
> >
> > Really?
> >
> > I have run into a problem when running a server on eCos.  I make
> > an application that does nothing but spit out data as fast as it can
> > and the box crashes.  My target is i386, the tip of tree, both net
> > stacks, using configtool 1.3 and 2.11.
> >
> > If can send you my code, would you mind checking to see what
> > happens on your side?  I can send you my .cfg file as well.   The
> > stack is being corrupted in the server task.
>
> This sounds like an application error.  However, it would be
> sensible to give it a look-see, if it can be boiled down to
> a reasonable size.  We (me personally) are always interested
> in making sure that eCos is rock-solid.

I am pretty sure it's not.  The stack is being corrupted.  I tried
a 50 KB stack, but realized that not even 4 KB is used.

> If it's more than a few Kb, don't send it to the list though.
> That's just overhead that most won't want to see.  The best
> way would be to file a BugZilla bug and send it as an attachment.
> See http://bugzilla.redhat.com/bugzilla

Tried bugzilla, and gave up when Konqueror puked on it.  I
need to upgrade my redhat installation.  I will submit by bugzilla
next time (if there is one ;)

I posted it here:  http://navosha.dynu.com/server.tgz

You probably don't need the Makefile, but you can at least
see my compiler flags.

The bug is as follows:

1) The server (eCos app) starts,
2) Connect to the server with telnet, port 4000
3) The server crashes.

The server's stack is being corrupted.  It fails with an illegal
instruction, the PC ends up at 0x0000 0004 (or around there, very
low memory) and GDB cannot (of course) trace the stack.

It seems to happen when I run out of MBufs.

I am using the tip of tree eCos, ecosconfig 2.11 and also
2.3.  I also used both net and new_net with similar results.
"new_net" allows gdb to continue to run, "net" disconnects
the GDB debugger entirely.

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