On Mar 15, 2014 1:39 PM, Peter Dufault <dufa...@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@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Reply via email to