PoyrazDereli
Forum Noob
FASTNET – a low-copy PS2 network receive path
FASTNET started as an effort to build a faster and more direct alternative to the PlayStation 2's slow and restrictive network paths. It developed into a custom route for transferring Ethernet/IPv4/UDP traffic from a PC into EE memory.
The measurements show roughly 92.3 Mbps of payload throughput, using about 92% of the PS2's 100BASE-TX receive capacity.
EENET receive path
Sony's standard receive path passes each frame through the complete EENET stack:
The IOP-side ent_smap.irx handles the SMAP descriptors, FIFO access, frame validation, interrupts and hardware-facing Ethernet work.
After reception, each frame is copied into an IOP packet buffer and passed to ent_devm.irx. It then crosses SIF and continues through the EE-side SMAP adapter, EENET, IP, UDP and the socket layer.
This provides a general-purpose socket interface, but each frame carries the cost of packet buffering, queueing, protocol processing and multiple handoffs.
The SMAP RX ring contains 64 descriptors, with the driver's initialization, indexing and ownership logic built around that fixed layout.
FASTNET receive path
FASTNET keeps Sony's DEV9 and SMAP hardware handling, but replaces the normal receive handoff:
The receive patch is applied to the IOP-side ent_smap.irx after the original descriptor, frame-length and MAC checks.
It changes the destination of the existing SMAP FIFO copy and redirects completed frames before the normal ent_devm.irx handoff.
Frames are written directly into larger IOP aggregation chunks instead of separate network packet buffers. Several frame records are then transferred together to the EE.
Protocol classification is performed after the frames reach the EE ring. ARP and FASTNET UDP traffic are handled directly, while unrelated traffic is discarded.
The EE-side SMAP adapter remains in use for interface state and the existing transmission path, including FASTNET replies.
EENET and FASTNET comparison
IOP buffering
EENET: A separate packet buffer and handoff for each received frame.
FASTNET: Multiple frame records stored in larger aggregation chunks.
IOP-to-EE transfer
EENET: Each frame follows the normal ent_devm.irx and SIF delivery path.
FASTNET: Several frames are transferred together with SIF DMA.
EE processing
EENET: Ethernet input, IP, UDP, socket buffering and application delivery.
FASTNET: Dedicated ring, direct protocol validation and direct dispatch.
Hardware handling
Both paths retain Sony's DEV9 services, SMAP descriptor management, FIFO handling, interrupts and hardware error processing.
IOP aggregation
FASTNET uses eight 32 KB chunks:
Each stored record contains:
A chunk is queued when:
* The next frame does not fit
* It reaches the 24 KB transfer threshold
* No new frame arrives for about 1 ms
The frame is copied directly from the SMAP FIFO into its final location inside the active chunk. No intermediate packet allocation or second IOP-side copy is required.
This changes the transfer unit from one frame to a group of frames, reducing SIF requests, completion callbacks and synchronization overhead.
SIF DMA and EE ring
Two DMA transfers can be active at the same time.
Each transfer uses one payload descriptor, or two when the EE ring wraps, followed by a commit descriptor:
The SIF DMA queue contains 32 descriptor entries.
The updated EE write position is transferred after the payload:
The EE processes only committed records, preventing incomplete data from being exposed to the consumer.
After processing the records, the EE reports its read position so the ring space and IOP chunks can be reused.
Measurements
The implementation was tested on retail PS2 hardware in both count mode and EE copy mode.
Each stage transferred:
The 3–10 MB/s sweep completed with:
Copy mode performs an actual EE-side payload copy rather than only counting received packets.
A fine sweep from 10.0 to 12.0 MB/s was then performed in 0.1 MB/s steps.
The receive rate stopped increasing at approximately 11.0 MB/s, corresponding to roughly 92.3 Mbps of FASTNET payload throughput.
The first packet loss appeared at a requested rate of 11.4 MB/s.
FASTNET combines Sony's existing DEV9 and SMAP hardware path with a focused receive patch in ent_smap.irx, direct SMAP FIFO copies, IOP aggregation and ordered SIF DMA publication into EE memory.
The project is developed and built with Sony's SCE SDK. The reverse engineering, architecture and validation were checked against SCE SDK documentation, Sony libraries and retail PS2 hardware.
Vibe coding was used to accelerate parts of the implementation.
The source code will be released at a later date. I have been working on this project for nearly three months, and doing this without access to a PS2 development kit has been genuinely exhausting. I hope you can understand and be patient. The motivation I had at the beginning is now close to being completely drained.
FASTNET started as an effort to build a faster and more direct alternative to the PlayStation 2's slow and restrictive network paths. It developed into a custom route for transferring Ethernet/IPv4/UDP traffic from a PC into EE memory.
The measurements show roughly 92.3 Mbps of payload throughput, using about 92% of the PS2's 100BASE-TX receive capacity.
EENET receive path
Sony's standard receive path passes each frame through the complete EENET stack:
Code:
SMAP hardware
-> IOP ent_smap.irx
using dev9.irx services
-> IOP packet buffer
-> ent_devm.irx
-> SIF
-> EE-side ent_smap adapter
-> EENET
-> IP / UDP
-> socket receive buffer
-> applicationThe IOP-side ent_smap.irx handles the SMAP descriptors, FIFO access, frame validation, interrupts and hardware-facing Ethernet work.
After reception, each frame is copied into an IOP packet buffer and passed to ent_devm.irx. It then crosses SIF and continues through the EE-side SMAP adapter, EENET, IP, UDP and the socket layer.
This provides a general-purpose socket interface, but each frame carries the cost of packet buffering, queueing, protocol processing and multiple handoffs.
The SMAP RX ring contains 64 descriptors, with the driver's initialization, indexing and ownership logic built around that fixed layout.
FASTNET receive path
FASTNET keeps Sony's DEV9 and SMAP hardware handling, but replaces the normal receive handoff:
Code:
SMAP hardware
-> patched IOP ent_smap.irx
using dev9.irx services
-> direct SMAP FIFO copy
-> IOP aggregation chunks
-> batched SIF DMA
-> EE ring buffer
-> FASTNET parser
-> consumerThe receive patch is applied to the IOP-side ent_smap.irx after the original descriptor, frame-length and MAC checks.
It changes the destination of the existing SMAP FIFO copy and redirects completed frames before the normal ent_devm.irx handoff.
Frames are written directly into larger IOP aggregation chunks instead of separate network packet buffers. Several frame records are then transferred together to the EE.
Protocol classification is performed after the frames reach the EE ring. ARP and FASTNET UDP traffic are handled directly, while unrelated traffic is discarded.
The EE-side SMAP adapter remains in use for interface state and the existing transmission path, including FASTNET replies.
EENET and FASTNET comparison
IOP buffering
EENET: A separate packet buffer and handoff for each received frame.
FASTNET: Multiple frame records stored in larger aggregation chunks.
IOP-to-EE transfer
EENET: Each frame follows the normal ent_devm.irx and SIF delivery path.
FASTNET: Several frames are transferred together with SIF DMA.
EE processing
EENET: Ethernet input, IP, UDP, socket buffering and application delivery.
FASTNET: Dedicated ring, direct protocol validation and direct dispatch.
Hardware handling
Both paths retain Sony's DEV9 services, SMAP descriptor management, FIFO handling, interrupts and hardware error processing.
IOP aggregation
FASTNET uses eight 32 KB chunks:
Code:
8 x 32 KB = 256 KBEach stored record contains:
Code:
frame length
Ethernet frame
alignment paddingA chunk is queued when:
* The next frame does not fit
* It reaches the 24 KB transfer threshold
* No new frame arrives for about 1 ms
The frame is copied directly from the SMAP FIFO into its final location inside the active chunk. No intermediate packet allocation or second IOP-side copy is required.
This changes the transfer unit from one frame to a group of frames, reducing SIF requests, completion callbacks and synchronization overhead.
SIF DMA and EE ring
Two DMA transfers can be active at the same time.
Each transfer uses one payload descriptor, or two when the EE ring wraps, followed by a commit descriptor:
Code:
Maximum FASTNET usage:
2 contexts x 3 descriptors = 6 SIF DMA descriptorsThe SIF DMA queue contains 32 descriptor entries.
The updated EE write position is transferred after the payload:
Code:
payload DMA
-> commit DMA
-> records become visible to the EEThe EE processes only committed records, preventing incomplete data from being exposed to the consumer.
After processing the records, the EE reports its read position so the ring space and IOP chunks can be reused.
Measurements
The implementation was tested on retail PS2 hardware in both count mode and EE copy mode.
Each stage transferred:
Code:
128 MB
94,255 FASTNET DATA packetsThe 3–10 MB/s sweep completed with:
Code:
0 packet gaps
0 missing bytes
normal completionCopy mode performs an actual EE-side payload copy rather than only counting received packets.
A fine sweep from 10.0 to 12.0 MB/s was then performed in 0.1 MB/s steps.
The receive rate stopped increasing at approximately 11.0 MB/s, corresponding to roughly 92.3 Mbps of FASTNET payload throughput.
The first packet loss appeared at a requested rate of 11.4 MB/s.
Code:
10.0 MB/s reliable sustained rate
~11.0 MB/s measured receive limit
11.4 MB/s first observed loss in a 128 MB stageFASTNET combines Sony's existing DEV9 and SMAP hardware path with a focused receive patch in ent_smap.irx, direct SMAP FIFO copies, IOP aggregation and ordered SIF DMA publication into EE memory.
The project is developed and built with Sony's SCE SDK. The reverse engineering, architecture and validation were checked against SCE SDK documentation, Sony libraries and retail PS2 hardware.
Vibe coding was used to accelerate parts of the implementation.
The source code will be released at a later date. I have been working on this project for nearly three months, and doing this without access to a PS2 development kit has been genuinely exhausting. I hope you can understand and be patient. The motivation I had at the beginning is now close to being completely drained.
PS2NBD — coming after FASTNET.
Last edited: