* RE: [ECOS] udp problem & network stack questions
@ 2002-06-11 17:20 Dan Conti
0 siblings, 0 replies; 4+ messages in thread
From: Dan Conti @ 2002-06-11 17:20 UTC (permalink / raw)
To: ecos-discuss
As far as the 'eth_recv out of MBUFS' error message, usually it's caused
by leaving a socket open. I.e. you have a socket that is receiving
incoming data, but you're not reading off it, so the data gets buffered
up. The easiest way to get around it is to increase the amount of memory
reserved for MBUFs (this is in the network settings in the config tool).
When i saw this last, i noticed that a single socket could use all the
available memory for MBUFs.
For item number 2, if you have a lot of network traffic you might see a
performance hit once your network is initialized. 50% is a bit much,
especially on a strongarm; i guess i'd be curious as to how much
broadcast/multicast traffic you are getting.
On item number 3 i would assume you are talking about the networking
stacks; i dont have much insight into either, sorry.
-----Original Message-----
From: aacquaviva@deis.unibo.it [mailto:aacquaviva@deis.unibo.it]
Sent: Tuesday, June 11, 2002 5:12 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] udp problem & network stack questions
Hi,
I have some question regarding tcp/ip.
1. I tried to set-up an udp client-server application between my
strongarm
platform and the PC. The server downloads an mpeg compressed stream to
the
client-decoder after a request message. When the server starts to
download,
the client send me the "recv out of MBUFS" error message. What could be
the
reason? How can I trace the work of network threads to debug this
problem?
2. Using a tcp/ip connection (that works) I noticed that the decoding
time
of the mpeg3 decoder doubles if during the decoding the network threads
are
active.
More clearly, the test I've done to understand why the mpeg3 decoder was
not
real-time is the following:
- The client initializes the interfaces (init_all_network_interfaces)
- connects to the server
- starts decoding taking encoded frames from the memory
The decoding time in this case is double with respect to the secoding
time I
get without the first two steps. Is it possible such a performance
decreasing only caused by the presence of network threads?
3. What's the difference in using Free instead of OpenBSD? Is there any
performance hints?
Thanks a lot for your help,
Andrea Acquaviva.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [ECOS] udp problem & network stack questions
@ 2002-06-12 14:45 aacquaviva
0 siblings, 0 replies; 4+ messages in thread
From: aacquaviva @ 2002-06-12 14:45 UTC (permalink / raw)
To: ecos-discuss
Hi,
thank you for the replies.
Increasing the buffer memory solved my udp problem.
Regarding the other question, notice that I use a private network between
server and client so I have not broadcast traffic. That's leave me impressed
about the performance fall.
I tried also to switch the priority by assigning to mpeg3 priority = 3 but I
got no improvements. Any idea about that?
Thanks a lot,
Andrea.
-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Dan Conti
Sent: Tuesday, June 11, 2002 5:20 PM
To: ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] udp problem & network stack questions
As far as the 'eth_recv out of MBUFS' error message, usually it's caused
by leaving a socket open. I.e. you have a socket that is receiving
incoming data, but you're not reading off it, so the data gets buffered
up. The easiest way to get around it is to increase the amount of memory
reserved for MBUFs (this is in the network settings in the config tool).
When i saw this last, i noticed that a single socket could use all the
available memory for MBUFs.
For item number 2, if you have a lot of network traffic you might see a
performance hit once your network is initialized. 50% is a bit much,
especially on a strongarm; i guess i'd be curious as to how much
broadcast/multicast traffic you are getting.
On item number 3 i would assume you are talking about the networking
stacks; i dont have much insight into either, sorry.
-----Original Message-----
From: aacquaviva@deis.unibo.it [mailto:aacquaviva@deis.unibo.it]
Sent: Tuesday, June 11, 2002 5:12 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] udp problem & network stack questions
Hi,
I have some question regarding tcp/ip.
1. I tried to set-up an udp client-server application between my
strongarm
platform and the PC. The server downloads an mpeg compressed stream to
the
client-decoder after a request message. When the server starts to
download,
the client send me the "recv out of MBUFS" error message. What could be
the
reason? How can I trace the work of network threads to debug this
problem?
2. Using a tcp/ip connection (that works) I noticed that the decoding
time
of the mpeg3 decoder doubles if during the decoding the network threads
are
active.
More clearly, the test I've done to understand why the mpeg3 decoder was
not
real-time is the following:
- The client initializes the interfaces (init_all_network_interfaces)
- connects to the server
- starts decoding taking encoded frames from the memory
The decoding time in this case is double with respect to the secoding
time I
get without the first two steps. Is it possible such a performance
decreasing only caused by the presence of network threads?
3. What's the difference in using Free instead of OpenBSD? Is there any
performance hints?
Thanks a lot for your help,
Andrea Acquaviva.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] udp problem & network stack questions
@ 2002-06-11 17:13 aacquaviva
2002-06-12 0:29 ` Andrew Lunn
0 siblings, 1 reply; 4+ messages in thread
From: aacquaviva @ 2002-06-11 17:13 UTC (permalink / raw)
To: ecos-discuss
Hi,
I have some question regarding tcp/ip.
1. I tried to set-up an udp client-server application between my strongarm
platform and the PC. The server downloads an mpeg compressed stream to the
client-decoder after a request message. When the server starts to download,
the client send me the "recv out of MBUFS" error message. What could be the
reason? How can I trace the work of network threads to debug this problem?
2. Using a tcp/ip connection (that works) I noticed that the decoding time
of the mpeg3 decoder doubles if during the decoding the network threads are
active.
More clearly, the test I've done to understand why the mpeg3 decoder was not
real-time is the following:
- The client initializes the interfaces (init_all_network_interfaces)
- connects to the server
- starts decoding taking encoded frames from the memory
The decoding time in this case is double with respect to the secoding time I
get without the first two steps. Is it possible such a performance
decreasing only caused by the presence of network threads?
3. What's the difference in using Free instead of OpenBSD? Is there any
performance hints?
Thanks a lot for your help,
Andrea Acquaviva.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] udp problem & network stack questions
2002-06-11 17:13 aacquaviva
@ 2002-06-12 0:29 ` Andrew Lunn
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Lunn @ 2002-06-12 0:29 UTC (permalink / raw)
To: aacquaviva; +Cc: ecos-discuss
> 2. Using a tcp/ip connection (that works) I noticed that the decoding time
> of the mpeg3 decoder doubles if during the decoding the network threads are
> active.
> More clearly, the test I've done to understand why the mpeg3 decoder was not
> real-time is the following:
>
> - The client initializes the interfaces (init_all_network_interfaces)
> - connects to the server
> - starts decoding taking encoded frames from the memory
>
> The decoding time in this case is double with respect to the secoding time I
> get without the first two steps. Is it possible such a performance
> decreasing only caused by the presence of network threads?
What priority is the network threads compared to the mpeg3 decoder?
TCP is obviously not real time, so there is no point running it at a
higher priority than the decoder.
Andrew
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-06-12 21:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-11 17:20 [ECOS] udp problem & network stack questions Dan Conti
-- strict thread matches above, loose matches on Subject: below --
2002-06-12 14:45 aacquaviva
2002-06-11 17:13 aacquaviva
2002-06-12 0:29 ` Andrew Lunn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).