Linuxppc and MPC8255 routing performance

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

[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

[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

[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/

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

[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:


> 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

[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/