Re: [ECOS] Question about ecos server performance

[Gary Thomas <gthomas at ecoscentric dot com>]

On Tue, 2002-08-13 at 07:37, NavEcos wrote:
> 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

Then what?  What do you have to do [from the "client" side] to
evoke the crash?

> 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.
> 

I assume that you've only tried this on the PC?

-- 
------------------------------------------------------------
Gary Thomas                  |
eCosCentric, Ltd.            |  
+1 (970) 229-1963            |  eCos & RedBoot experts
gthomas@ecoscentric.com      |
http://www.ecoscentric.com/  |
------------------------------------------------------------


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