Optimizations for applications requiring limited functionality.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Optimizations for applications requiring limited functionality.

Roger Cover
Greetings,

I have completed my upgrade to version 1.2.0 (from 0.6.3). The
reliability of my system is much improved. The developers have done a
good job increasing the robustness of the library.

Now that I have version 1.2.0 running, I have noticed a decrease in
performance (about 40%). Part of the decrease I initially noticed was
because my old lwipopts.h file used an old (and no longer correct)
method to turned statistics collection off. I am using the "raw" API and
I only need ARP, ICMP echo, TCP/IP, and UDP. The major performance issue
is only in UDP.

This brings me to my question: I already found how to turn off the
statistics and "raw" packet code. What else can I turn off in lwipopts.h
to remove things I don't need? Version 1.2.0 has a lot of features that
0.6.3 did not have, and any help jump-starting my performance
improvement quest will be greatly appreciated.

Regards,
Roger W. Cover
Spectral Instruments, Inc.
420 N. Bonita Ave.
Tucson, AZ 85745
Voice: 520-884-8821 ext. 144
FAX: 520-884-8803


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Optimizations for applications requiring limitedfunctionality.

Goldschmidt Simon

> Now that I have version 1.2.0 running, I have noticed a
> decrease in performance (about 40%). Part of the decrease I

Can you measure CPU load of 0.6.3 compared to 1.2.0? E.g. does lwIP
consume more
CPU cycles or is there some kind of slow-down due to lwIP waiting for
something?

Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Optimizations for applications requiring limited functionality.

Roger Cover
Greetings Simon,

I have not looked very far into what lwIP is doing internally. I know
that the function ip_output_if() is where my CPU is spending over 80% of
its time during my UDP transfers. I am using a Gigabit MAC/PHY, so
lwIP's transmission speed is no where near what the hardware can
sustain. There should not be any waiting for the hardware.

In fact, the Xilinx driver I have, from the reference design I started
with, does not even check to see if the MAC's FIFO is full. It just
blindly sends data to the MAC presuming the FIFO will be emptied faster
than it can be filled. This presumption is justified if the PHY has
negotiated a Gigabit connection. In my test setup, it has.

Is there something in particular you would like me to look into?

Regards,
Roger
-----Original Message-----
From: lwip-users-bounces+rcover=[hidden email]
[mailto:lwip-users-bounces+rcover=[hidden email]] On Behalf Of
Goldschmidt Simon
Sent: Tuesday, April 17, 2007 6:09 AM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] Optimizations for applications
requiringlimitedfunctionality.


> Now that I have version 1.2.0 running, I have noticed a
> decrease in performance (about 40%). Part of the decrease I

Can you measure CPU load of 0.6.3 compared to 1.2.0? E.g. does lwIP
consume more
CPU cycles or is there some kind of slow-down due to lwIP waiting for
something?

Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Optimizations for applications requiring limitedfunctionality.

Goldschmidt Simon


> I have not looked very far into what lwIP is doing
> internally. I know that the function ip_output_if() is where
> my CPU is spending over 80% of its time during my UDP
> transfers. I am using a Gigabit MAC/PHY, so lwIP's
> transmission speed is no where near what the hardware can
> sustain. There should not be any waiting for the hardware.

OK, I seem to have overread the fact that you are using UDP, I was
thinking of TCP.
However, spending 80% of the time in ip_output_if() seems a little
strange to me,
since there is nothing in that function which could be consuming cycles
(no loop,
just a checksum calculation over 20 bytes).

How did you measure the 80% and are you sure that netif->output() and
nested
calls don't count into the time of ip_output_if()? I'd imagine the
cycles are
going into your network driver instead of ip_output_if()...

> In fact, the Xilinx driver I have, from the reference design
> I started with, does not even check to see if the MAC's FIFO
> is full. It just blindly sends data to the MAC presuming the
> FIFO will be emptied faster than it can be filled. This
> presumption is justified if the PHY has negotiated a Gigabit
> connection. In my test setup, it has.
>
> Is there something in particular you would like me to look into?

Hm, checking if the 80% are including netif->output() or not. Oh, did
you check
you aren't running out of memory? Aside from that, I'm afraid I don't
think I
can help much.


Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Optimizations for applications requiringlimitedfunctionality.

Roger Cover
Greetings Simon,

The 80% includes the netif->output() call. My system uses both UDP and
TCP. I have probed the UDP code more, so I know a bit more about it. The
measured performance change is about the same for UDP and TCP. As I
mentioned earlier, I am using the same driver code with minor API
alterations for both versions of lwIP. I would not expect the driver's
behavior to have changed.

My system is not running out of memory. I have been watching that very
carefully.

Regards,
Roger
-----Original Message-----
From: lwip-users-bounces+rcover=[hidden email]
[mailto:lwip-users-bounces+rcover=[hidden email]] On Behalf Of
Goldschmidt Simon
Sent: Tuesday, April 17, 2007 8:51 AM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] Optimizations for applications
requiringlimitedfunctionality.



> I have not looked very far into what lwIP is doing
> internally. I know that the function ip_output_if() is where
> my CPU is spending over 80% of its time during my UDP
> transfers. I am using a Gigabit MAC/PHY, so lwIP's
> transmission speed is no where near what the hardware can
> sustain. There should not be any waiting for the hardware.

OK, I seem to have overread the fact that you are using UDP, I was
thinking of TCP.
However, spending 80% of the time in ip_output_if() seems a little
strange to me,
since there is nothing in that function which could be consuming cycles
(no loop,
just a checksum calculation over 20 bytes).

How did you measure the 80% and are you sure that netif->output() and
nested
calls don't count into the time of ip_output_if()? I'd imagine the
cycles are
going into your network driver instead of ip_output_if()...

> In fact, the Xilinx driver I have, from the reference design
> I started with, does not even check to see if the MAC's FIFO
> is full. It just blindly sends data to the MAC presuming the
> FIFO will be emptied faster than it can be filled. This
> presumption is justified if the PHY has negotiated a Gigabit
> connection. In my test setup, it has.
>
> Is there something in particular you would like me to look into?

Hm, checking if the 80% are including netif->output() or not. Oh, did
you check
you aren't running out of memory? Aside from that, I'm afraid I don't
think I
can help much.


Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users