This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Question about ecos server performance
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