Re: Linuxppc and MPC8255 routing performance

Re: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

Hi, Ken

On Monday 12 November 2001 18:28, Ken Applebaum wrote:
> ricardo,
>
> does your board have both banks of memory populated?
>

If you mean 'both banks" as a memory bank at the local bus and another at the
60x bus, the answer is yes, our prototype hardware has them, for hardware
debugging purposes. But I didn't enable the use of the local memory bank in
Linux so far, because we didn't originally intend to use it in our final
product...

Nevertheless, I'm aware that using local bus memory for I/O data flowing
between CPM and CPU may improve performance in some Linux applications, so I
would like to experiment with this. Unfortunatelly, I'm very new to Linux, so
I don't know how to configure it for using local memory. If you have any
ideas...

Thanks.

~Ricardo

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Dan Malek]

Ricardo Scop wrote:


> Nevertheless, I'm aware that using local bus memory for I/O data flowing
> between CPM and CPU may improve performance in some Linux applications, so I
> would like to experiment with this.

You don't need this as a solution to your performance troubles.  I have
been experimenting with using this space for socket buffers, but unless
you have something else on the bus consuming the cycles, I haven't seen
any benefit.  It could be very useful for custom network applications,
but there isn't anything Linux will do.  Some systems just toss this space
into the general free memory pool, just remember you can't access it over
the 60x bus.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

On Tuesday 13 November 2001 20:02, Dan Malek wrote:

> Ricardo Scop wrote:
> > Nevertheless, I'm aware that using local bus memory for I/O data flowing
> > between CPM and CPU may improve performance in some Linux applications,
> > so I would like to experiment with this.
>
> You don't need this as a solution to your performance troubles.  I have
> been experimenting with using this space for socket buffers, but unless
> you have something else on the bus consuming the cycles, I haven't seen
> any benefit.  It could be very useful for custom network applications,

Gee, sorry... I meant _network_ applications, indeed. And, thank you for your
advice.

As for our performance troubles, there have been some improvements; we were
making some mistakes regarding both FCC and PHY programming. After fixing
those, we're able to achieve more than 50 Mbits/s in a _real_ FTP transfer,
which is more than enough for our router application.  We are still
conducting more performance tests with netperf, and will publish the resuts
when available.

Thanks,

~Ricardo

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Dan Malek]

Ricardo Scop wrote:


> As for our performance troubles, there have been some improvements; we were
> making some mistakes regarding both FCC and PHY programming.


FYI, a major telecommuniation company paid for independent laboratory
certifcation of this driver (and Linux) under a variety of performance
and error conditions.  After a couple of iterations, it passed the
certification testing and I believe all of the modifications are in
this driver (at least it was my intention to ensure they are public).
I don't remember which PHY was used for the testing, but please don't
attack this as a "can't possibly work" problem and start hacking it up.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re[2]: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

Dan,

Tuesday, November 13, 2001, 3:21:38 PM, you wrote:

DM> Ricardo Scop wrote:


>> As for our performance troubles, there have been some improvements; we were
>> making some mistakes regarding both FCC and PHY programming.


DM> FYI, a major telecommuniation company paid for independent laboratory
DM> certifcation of this driver (and Linux) under a variety of performance
DM> and error conditions.  After a couple of iterations, it passed the
DM> certification testing and I believe all of the modifications are in
DM> this driver (at least it was my intention to ensure they are public).

I'm really glad to know about that. FYI, we never had any doubts about
linuxppc implementation quality, or we wouldn't use it in the first
place.

DM> I don't remember which PHY was used for the testing, but please don't
DM> attack this as a "can't possibly work" problem and start hacking it up.

Oh, we don't! The 'mistakes' I referred were made by _myself_, in two
places:
       - LXT970A PHY in PPCBoot (our hardware MDIO interface don't
       conform to Linux MDIO driver, so I hacked PPCBoot to program
       the chip to megotiate full-duplex, but I did it wrong in our
       earlier tests);

       - in arch/ppc/8260io/fcc_enet.c: the driver we have, pulled
       from linuxppc_2_4 mvista cvs mirror some two weeks ago,
       programs the FCC to half-duplex mode, by default; so, I tryed to
       hack it to full-duplex for our tests and, again, made a
       mistake, which is now fixed).

As I said, all _my_ mistakes. Linux FCC driver works perfectly well!

Thanks again.

~Ricardo


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

eth1 FEC on RPX-CLLF info

[sruel]

Hello Wolfgang,

I'm trying to activate the FEC on my RPX-CLLF board. Everything seems ok
when I do a ifconfig -a, but the FEC eth1 interface seems dead. I wonder
if the base address of the FEC is really 0xe00?

Here is my eth1 config:
ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:10:EC:00:2C:93
          inet addr:172.16.200.10  Bcast:172.16.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:719 errors:0 dropped:0 overruns:0 frame:14
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Base address:0x3c00

eth1      Link encap:Ethernet  HWaddr 00:10:EC:80:2C:93
          inet addr:148.33.216.245  Bcast:148.33.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Base address:0xe00

lo        Link encap:Local Loopback
          LOOPBACK  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

Here is the boot screen dump. The eth1 FEC MAC address is correctly read.
...
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: CPM ENET Version 0.2 on SCC1, 00:10:ec:00:2c:93
eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:10:ec:80:2c:93
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
loop: loaded (max 8 devices)
RPX Lite or CLLF flash device: 1000000 at ff000000
 Amd/Fujitsu Extended Query Table v1.2 at 0x0040
number of CFI chips: 1
...

Would you have any idea of the problem?

By the way, in the file fec.c from kernel 2.4.4 (2001-07-23), it is
mentionned that the FEC PHY for the RPX-CLLF board is a QS6612. I have
an RPX-CLLF board, and it uses an LXT971.

Thank!


Sebastien Ruel, System Engineer.
Oerlikon Contraves
Quebec, Canada


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: eth1 FEC on RPX-CLLF info

[Wolfgang Denk]

Dear Sebastien,

in message <3BFA8DB6.1050405@oerlikon.ca> you wrote:
>
> Hello Wolfgang,

I'm not exactly sure whom you're addressing:  the  email  addess  was
Dan's  but  the  name  is mine, and it seems you are referring to the
kernel version on our FTP server, so I jump in ...

> I'm trying to activate the FEC on my RPX-CLLF board. Everything seems ok
> when I do a ifconfig -a, but the FEC eth1 interface seems dead. I wonder
> if the base address of the FEC is really 0xe00?

What do you think  it  means?  Here,  it's  the  offset  of  the  FEC
parameter RAM in the IMMR memory map. And yes, 0xE00 is correct.

> Here is the boot screen dump. The eth1 FEC MAC address is correctly read.
> ...
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> eth0: CPM ENET Version 0.2 on SCC1, 00:10:ec:00:2c:93
> eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:10:ec:80:2c:93

Looks good to me...

> eth1      Link encap:Ethernet  HWaddr 00:10:EC:80:2C:93
>           inet addr:148.33.216.245  Bcast:148.33.255.255  Mask:255.255.255.0

Are you sure about those settings? To me  it  seems  Bcast  and  Mask
don't match...

> Would you have any idea of the problem?

What happens when you enable the MDIO option?

> By the way, in the file fec.c from kernel 2.4.4 (2001-07-23), it is
> mentionned that the FEC PHY for the RPX-CLLF board is a QS6612. I have
> an RPX-CLLF board, and it uses an LXT971.

Did you enable the LXT971 code, then? Sorry, I don't  have  any  CLLF
boards here, so I cannot test this myself.

Just tested it (again) on a TQM860L-P.50; works fine for me.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Above all else -- sky.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Linuxppc and MPC8255 routing performance

[Ricardo Scop]

Hello,

I'm using Linux for PPC in a proprietary MPC8255-based hardware as an
embedded router system. I've been trying both Denx's kernel (as of
2001-07-23) and linuxppc_2_4 (last week's version), and everything
goes smoothly (thanks to all contributing guys...).

I have some performance numbers which I'd like to share and confront,
if possible. Core clock is 132 MHZ, and bus clock 33 Mhz.
Our hardware does not have a secondary (L2) cache (and I
wonder if it should...):

       - FTP transfer ratio through the router - 0.5 to 1.5 Mbytes/s;
       - # of packets per second (best case): 2000

All tests were accomplished using two fast ethernet interfaces.
Best performances where obtained with data cache disabled (yes, we
had to hack linuxppc_2_4 for that...).

Does that sound ok, compared to other 8260 systems? (8255 is almost
identical to 8260)

Any numbers or other feedbacks will be highly appreciated!

Best regards,

Scop, Ricardo                          mailto:scop@vanet.com.br


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Dan Malek]

Ricardo Scop wrote:


> Does that sound ok, compared to other 8260 systems?

No, not even close.  Something must be wrong with your memory
interface or system.  The data cache enabled should be significantly
faster, and on an 8260 you can run all three fast ethernets at full
speed.  Using FTP as a benchmark isn't usually the best choice.  You
should be running carefully controlled network benchmark applications.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

On Thursday 08 November 2001 22:41, Dan Malek wrote:

> No, not even close.  Something must be wrong with your memory
> interface or system.

OK, I'll check it out,. thanks.

>  The data cache enabled should be significantly
> faster, and on an 8260 you can run all three fast ethernets at full
> speed.

Even without secondary (L2) cache?

>  Using FTP as a benchmark isn't usually the best choice.  You
> should be running carefully controlled network benchmark applications.

Err.. any suggestions, on those?

Thank you, so far!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Val Henson]

On Thu, Nov 08, 2001 at 06:02:14PM +0300, Ricardo Scop wrote:
>
> >  Using FTP as a benchmark isn't usually the best choice.  You
> > should be running carefully controlled network benchmark applications.
>
> Err.. any suggestions, on those?
>
> Thank you, so far!

Netperf is most common:

http://www.netperf.org/

I prefer netpipe:

http://www.scl.ameslab.gov/netpipe/

Either will do the job.  Write yourself some scripts to do the tests
and also to graph the results automatically.  Just looking at the
numbers as they scroll by won't give you much information on
performance improvement.

-VAL

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Dan Malek]

Ricardo Scop wrote:


> Even without secondary (L2) cache?

Yes.  Depending upon the application, using the "backside" memory
for exclusive CPM use could be helpful.

> Err.. any suggestions, on those?

netperf comes to mind.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

On Friday 09 November 2001 00:45, Dan Malek wrote:
> > Even without secondary (L2) cache?
>
> Yes.  Depending upon the application, using the "backside" memory
> for exclusive CPM use could be helpful.
>

By "backside" memory you mean ... the internal data cache, perhaps?

And, how can this be done?

[sorry for the silly questions, but I'm new to both Linux and MPC8255 memory
stuff :-( ; any pointer to documentation will be very welcome, too]

Thanks again...

~ Ricardo

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Dan Malek]

Ricardo Scop wrote:


> By "backside" memory you mean ... the internal data cache, perhaps?

No, bad use of words on my part.  The 8260 has a local bus that can only
be accessed from the CPU core and CPM (it's not on the 60x bus).  Maybe
the 8255 doesn't have this feature, I don't remember.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linuxppc and MPC8255 routing performance

[Jerry Van Baren]

At 11:34 AM 11/9/01 -0500, Dan Malek wrote:

>Ricardo Scop wrote:
>
>
>>By "backside" memory you mean ... the internal data cache, perhaps?
>
>No, bad use of words on my part.  The 8260 has a local bus that can only
>be accessed from the CPU core and CPM (it's not on the 60x bus).  Maybe
>the 8255 doesn't have this feature, I don't remember.
>
>
>         -- Dan

The 8255 uses the 8260 "local bus" connections for the PCI bus.

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/