Network performance of the PlayStation 2 with SONY software

Thanks.

Thanks, but I was wondering why you wrote that polling is faster than using the interrupt.
If we use the interrupt, then there would be no time wasted as well.

If it is because one interrupt per frame will result in overhead, our system does not have that problem. After the first interrupt assertion, the SMAP driver will continuously handle incoming frames, as long as the FIFO level is above zero.

LOL. But the selling point of PS2NETBOX is the convenience, isn't it?

BTW beware that the SMSTCPIP stack likely still has some bug that I have not identified. From 2011, I noted that sometimes this stack will slow down and become unresponsive. But it only happens under specific conditions.
Some design issues were rectified, but not all from this list apply: https://github.com/ps2dev/ps2sdk/blob/master/common/tcpip/lwip-2.0.0/CHANGES-PS2.txt

I suspected the custom message-box system, but I forgot why.

There may be further performance gain if we back-port the new TCPIP core locking feature from v2.0.0. No context switches.

 

Because we do not busy polling , but use a timer to weak up a thread periodically. So we can minimize thread context switch overhead .
Interrupt method maybe need more thread switch .
If you have a look at my pseudo code , you will find we will need little cpu to do it .
we just check some flag , then start dma transfer .Almost cpu time we use is busy waiting end of dma transfer. Considering IOP dma speed is almost 100MB/s .
we will use 16% IOP cpu to transfer at 8MB/s.

The first point is speed, the second is convenience.
If you really change something of OPL include my ideas , I will be very glad that .
If someone say I steal OPL , I can say : NO .
If you are hesitated on changing OPL 's code , we keep this as public secret, let someone else add it .

 

I still don't think it should though...

But thanks for explaining your thoughts!

I am quite bad with math, so it is nice to see how the cycles can be spent. Thank you for your explanation.

In theory, the code for transferring frames is very lightweight. I remember spending a lot of time trying to shorten it where possible. I guess it is a sign that I should do some benchmarking... someday.

Okay, but wasn't that for a different reason? I thought that you wrote that PS2NETBOX does not use SMB?
If that is correct, then isn't it correct to say that it offers better speed because of the design?

I do not have write access to OPL's repository anymore, since I stopped work on it in 2015. If you prefer to, you can make a pull request yourself.

Those who steal OPL are those who rename it, hide the logo and who charge for it. As long as you do not do that, it is not stealing.

 

Yes，PS2Netbox does not use SMB .
But through carefully redesign , eg rewrite the critical transfer code ( mix smap ,smb,cdvdman togther),the speed can be increased. This is not easy to do . And maybe need a moded samba server

eg: memory copy speed.
memory read speed (eg: sum a buffer)
Thread switching time
I think this is the main factor of speed of ethernet transferring .

I think hardware-software highly coupled is the main reason for better speed.

 

I think starting with ps3netsrv is probably a better idea. It does the same thing for streaming games and bluray discs to ps3.