headers
E.F.Spijksma | 1 May 2006 10:21
Picon

netconn_write loops

Hi,

This problem has been posted in 2005 but got no response which i can see..
in api_lib.c.
In the function netconn_write the semaphore which is waited on when
tcp_sndbuf( conn->pcb.tcp ) returns 0. There is mention of a patch of which
I expect that it will be integrated in lwip v 1.1.1.
But we still experience the connection loops in netconn_write at that point.

In the api_msg.c in the function do_write, tcp_write is called.
at some point tcp_write returns an error. This isn't always a problem
but sometimes it just keeps returning errors.

Could anyone help me with those 2 problems?

Greetz
Edwin
Permalink | Reply | 501 comments |
headers
Timmy Brolin | 1 May 2006 12:09
Picon
Favicon

Re: [PATCH] fix warning for gcc and possible unaligned access

Leon Woestenberg wrote:

>As Curt mentions, this will surely be sub-optimal, but worst case is
>still doing everything run time, AFAICS.
>
>If we can do better, I would like to hear.
>
>Regards,
>
>Leon.
>  
>
I think the current arrangement is probably the best tradeoff there is.
The two byte padding at the beginning of the ethernet header struct in 
combination with ip_addr2 made sure that the lwip code never accesses a 
datatype on a alignment less than its natural alignment.
When it comes to the packing of structs there is plenty of flexibility. 
People with compilers which insert more padding than actually neccessary 
to reach natural alignment can use packing directives to get around that 
problem. Others can choose to not use the packing directives.
Some compilers may generate sub-optimal code when using packing 
directives, but if the same compilers also inserts more padding than 
required to get natural alignment of nested structs, then I only see a 
few options to get that to work in code: 1: Use packing. 2: Replace 
structs with arrays of U16s. 3: Don't use nested structs.
I doubt option 2 would be much more efficient than option 1, and it 
would make the code unreadable.
Option 3 should work, but I think someone said there is a reason ip_addr 
and ip_addr2 are structs rather than simply U32. I can't remember the 
reason at the moment.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gian Paolo Stoppani | 1 May 2006 22:55
Picon
Favicon

Network performance for Microblaze system with lwip

Hello,
Have somebody some statistics about network performances  (TCP tx, TCP rx, etc.) for Microblaze system with lwip and with or without operating system?
 
Thank you very much
Greatings
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 0 comments |
headers
Christiaan Simons | 2 May 2006 10:01
Picon

Re: netconn_write loops

Edwin wrote:

> This problem has been posted in 2005 but got no response which i can
see..
> in api_lib.c.
> In the function netconn_write the semaphore which is waited on when
> tcp_sndbuf( conn->pcb.tcp ) returns 0. There is mention of a patch of
which
> I expect that it will be integrated in lwip v 1.1.1.

If we're going to fix it, it will be changed in the HEAD version (CVS).

> But we still experience the connection loops in netconn_write at that
point.
>
> In the api_msg.c in the function do_write, tcp_write is called.
> at some point tcp_write returns an error.

Do you remember which error? ERR_MEM is commonly returned by tcp_write(),
this indicates you'll have to back-off for a while so that tcp_output()
actually outputs the queued data.

> This isn't always a problem
> but sometimes it just keeps returning errors.

The correct usage of tcp_write(), tcp_output() etc
are described in the liwp/doc/rawapi.txt

Regards,

Christiaan Simons

Hardware Designer
Axon Digital Design

http://www.axon.tv
Permalink | Reply | 502 comments |
headers
Matthew Yingling | 2 May 2006 16:08

RE: netconn_write loops

In order for tcp_write() and tcp_output() to successfully complete, doesn't
the user code need to call LwIP to check for ACK packets to flush the data
out of the tcp_output queue?

Matthew Yingling

-----Original Message-----
From: lwip-users-bounces+matt=xenotran.com@...
[mailto:lwip-users-bounces+matt=xenotran.com@...]On
Behalf Of
Christiaan Simons
Sent: Tuesday, May 02, 2006 4:02 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] netconn_write loops

Edwin wrote:

> This problem has been posted in 2005 but got no response which i can
see..
> in api_lib.c.
> In the function netconn_write the semaphore which is waited on when
> tcp_sndbuf( conn->pcb.tcp ) returns 0. There is mention of a patch of
which
> I expect that it will be integrated in lwip v 1.1.1.

If we're going to fix it, it will be changed in the HEAD version (CVS).

> But we still experience the connection loops in netconn_write at that
point.
>
> In the api_msg.c in the function do_write, tcp_write is called.
> at some point tcp_write returns an error.

Do you remember which error? ERR_MEM is commonly returned by tcp_write(),
this indicates you'll have to back-off for a while so that tcp_output()
actually outputs the queued data.

> This isn't always a problem
> but sometimes it just keeps returning errors.

The correct usage of tcp_write(), tcp_output() etc
are described in the liwp/doc/rawapi.txt

Regards,

Christiaan Simons

Hardware Designer
Axon Digital Design

http://www.axon.tv

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 1 comment |
headers
Christiaan Simons | 2 May 2006 17:13
Picon

RE: netconn_write loops

Matthew wrote:

> In order for tcp_write() and tcp_output() to successfully complete,
doesn't
> the user code need to call LwIP to check for ACK packets to flush the
data
> out of the tcp_output queue?

When programming the sockets API you're not
going to check for ACK packets....

The socket layer should call the tcp_write(),
tcp_output() and tcp_timers() to handle egress
TCP segments and TCP ACKs from it's tcpip_thread.

When programming the raw-API you're responsible
for calling tcp_write, tcp_output running
the TCP timers at the required intervals.

Bye,

Christiaan.
Permalink | Reply | 0 comments |
headers
revathy | 3 May 2006 06:43

Regarding Packet Loss in UDP mode - LwIP TCP/IP stack

Hi,
   I am working on ADSP-BF533, board with USB LAN EZ extender card.
In that card we had preloaded LwIP stack.
Currently we wanted to stream the data from ADSP BF533 board to an another
PC.
While doing so, I am facing a packet loss in UDP mode.

This got fixed by giving sleep(100) for every packet.
I don't want this sleep(100), because it creates delay.

We approached Analog Devices Support Team, they suggest to contact
you regarding the stack implementation.
http://savannah.nongnu.org/projects/lwip.

But I don't know how to get information. so, I became the member of this
group.

Can anyone help me out to solve this problem.

Thanking You,
Revathy
Permalink | Reply | 6 comments |
headers
Kieran Mansley | 3 May 2006 10:00

Re: Regarding Packet Loss in UDP mode - LwIP TCP/IP stack

On Wed, 2006-05-03 at 10:13 +0530, revathy wrote:
> Hi,
>    I am working on ADSP-BF533, board with USB LAN EZ extender card.
> In that card we had preloaded LwIP stack.
> Currently we wanted to stream the data from ADSP BF533 board to an another
> PC.
> While doing so, I am facing a packet loss in UDP mode.
> 
> This got fixed by giving sleep(100) for every packet.
> I don't want this sleep(100), because it creates delay.

It sounds as though when trying to send at a high data rate you get
packet loss, but the sleep(100) slows everything down sufficiently that
whatever is dropping packets can keep up.  Note that with UDP packet
loss is not particularly surprising, or necessarily a bug.  I suggest
you track down where the packets are being dropped - this should make
the reason for the loss more obvious, and so make it possible to suggest
a solution.

Kieran
Permalink | Reply | 5 comments |
headers
revathy | 3 May 2006 11:12

RE: Regarding Packet Loss in UDP mode - LwIP TCP/IP stack

Hi Kieran,
		Thanks a lot for trying to attempt my problem.

	Yes, as you said in UDP mode, packet loss is common.
But, I tried with less traffic situation, meaning PC to board alone (static
mode)
and no switch in between (This is by using crossover cable).
	In that case also packet loss is happening, if iam not using the
sleep(100).
what can I do?

Revathy

-----Original Message-----
From: lwip-users-bounces+revathy=sarayusoftech.com@...
[mailto:lwip-users-bounces+revathy=sarayusoftech.com@...]On
Behalf Of Kieran Mansley
Sent: Wednesday, May 03, 2006 1:31 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Regarding Packet Loss in UDP mode - LwIP
TCP/IP stack

On Wed, 2006-05-03 at 10:13 +0530, revathy wrote:
> Hi,
>    I am working on ADSP-BF533, board with USB LAN EZ extender card.
> In that card we had preloaded LwIP stack.
> Currently we wanted to stream the data from ADSP BF533 board to an another
> PC.
> While doing so, I am facing a packet loss in UDP mode.
>
> This got fixed by giving sleep(100) for every packet.
> I don't want this sleep(100), because it creates delay.

It sounds as though when trying to send at a high data rate you get
packet loss, but the sleep(100) slows everything down sufficiently that
whatever is dropping packets can keep up.  Note that with UDP packet
loss is not particularly surprising, or necessarily a bug.  I suggest
you track down where the packets are being dropped - this should make
the reason for the loss more obvious, and so make it possible to suggest
a solution.

Kieran

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

__________ NOD32 1.1427 (20060303) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com
Permalink | Reply | 3 comments |
headers
Kieran Mansley | 3 May 2006 11:18

RE: Regarding Packet Loss in UDP mode - LwIP TCP/IP stack

On Wed, 2006-05-03 at 14:42 +0530, revathy wrote:
> Hi Kieran,
> 		Thanks a lot for trying to attempt my problem.
> 
> 	Yes, as you said in UDP mode, packet loss is common.
> But, I tried with less traffic situation, meaning PC to board alone (static
> mode)
> and no switch in between (This is by using crossover cable).
> 	In that case also packet loss is happening, if iam not using the
> sleep(100).
> what can I do?

Investigate where in the UDP/IP stack the packets are being dropped.
Most probably this is at the receiver, and most probably it's due to
some queue getting full.  I'm not sure where the queues are in the
receiver, but it should be a pretty quick job to look through and add
some sort of instrumentation at each queue whenever a packet is dropped.

Kieran
Permalink | Reply | 2 comments |

Gmane