[ECOS] udp problem & network stack questions

[ECOS] udp problem & network stack questions

[aacquaviva]

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

Re: [ECOS] udp problem & network stack questions

[Andrew Lunn]

> 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

RE: [ECOS] udp problem & network stack questions

[aacquaviva]

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

RE: [ECOS] udp problem & network stack questions

[Dan Conti]

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