SMC91111 performance and copyright

[Joel Sherrill]

On Mar 15, 2014 1:39 PM, Peter Dufault <dufault at hda.com> wrote:
>
> I'm including you directly, Daniel, since you've done some recent patches for the SMC91111 driver on the Sparc.  That's the only place I think it's used other than on the Phytec MPC5554.  If anyone else is using it then I'd love to know.
>
> The SMC91111 performance on the Phytec Phycore board is horrible.  I haven't worried about it since I use it to boot, store some log files and accept remote commands (that don't happen that often), but I would like to fully use it and I'm trying to figure out why the performance is so bad.
>
> My initial results using the ttcp benchmark were 133 KB/sec linux->RTEMS and 134 RTEMS->Linux.  I managed to get it quite a bit better using 16 bit transfers instead of 32 bit, and by using wireless instead of wired (obviously it's falling down under loading).
>
> Looking at Wireshark I see that everything runs great for a short amount of time and then there are lots of retransmissions and "out-of-order bytes received".  I don't understand this enough to know what's going on, but I think once traffic is flowing the driver breaks down.  So as long as things are very lightly loaded it works OK, as soon as it is busy it will fall down.  It does work reliably, but very slowly.
>
> I looked what I think are later versions of this driver from eCOS.  They are GPL and also have changes where I think they check for activity in places that the RTEMS driver doesn't, that is, poll for input during output, etc.  I have at least three questions:
>
> - The RTEMS driver has no copyright.  Is this because it pre-dates a copyright from eCOS?
> - Is this driver in active use and works just fine on SPARC?
> - There's a FreeBSD driver for this.  Am I better trying to port that than fix the existing driver?

I don't know your RAM or requirements situation but the new TCP/IP stack may also be an option.

But if staying with the old stack, updating the driver may be an easier option. There is a collection of newer drivers for the current stack with porting glue in rtems-libbsd.

>
> Here's what comes out of the ttcp test.  As I said, I don't know much about this, but all those "out-of-order bytes" are odd.
>
>
> ************ IP Statistics ************
>              total packets received       19050
>   packets rcvd for unreachable dest        1931
>  datagrams delivered to upper level       17119
>     total ip packets generated here        9546
>
> ************ TCP Statistics ************
>                connections accepted           1
>             connections established           1
>       conn. closed (includes drops)           1
>      segs where we tried to get rtt           2
>                  times we succeeded           2
>                   delayed acks sent         109
>                  total packets sent        9540
>               ack-only packets sent        6034
>     window update-only packets sent        3505
>  control (SYN|FIN|RST) packets sent           1
>              total packets received       11636
>        packets received in sequence        5709
>          bytes received in sequence     8260600
>     duplicate-only packets received          38
>       duplicate-only bytes received       53576
>       out-of-order packets received        5885
>         out-of-order bytes received     8516616
>                 rcvd duplicate acks          34
>                    rcvd ack packets           2
>            bytes acked by rcvd acks           2
>  times hdr predict ok for data pkts        5707
>
>
>
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140315/248c51fd/attachment-0001.html>