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