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 that FASTNET reaches roughly 92.3 Mbps of payload throughput, using about 92% of the PS2's 100BASE-TX receive capacity.
EENET receive path
The standard EENET receive path moves each frame through Sony's general-purpose network stack:
The IOP-side ent_smap.irx handles the SMAP descriptors, FIFO access, frame validation and the hardware-facing receive work.
Accepted frames are copied into IOP packet buffers and passed to ent_devm.irx. They then cross SIF and enter the EE-side SMAP adapter before continuing through EENET, IP, UDP and the socket layer.
This provides the normal socket interface, but buffering, queueing, protocol processing and delivery are performed separately for each packet.
The SMAP RX ring contains 64 descriptors. The driver's initialization, indexing and memory layout are built around that fixed count.
FASTNET receive path
FASTNET keeps Sony's DEV9 and SMAP hardware handling, but changes how received frames leave the IOP:
A focused binary patch is applied to a known revision of the IOP-side ent_smap.irx.
The patch redirects the existing SMAP FIFO copy after the RX descriptor and frame length have been validated, but before the normal ent_devm.irx handoff.
The patch changes:
* The destination used by the SMAP FIFO copy
* The completed-frame submission path
* The continuation point after submission
The original RX descriptor handling, frame-length checks, MAC filtering and hardware error handling remain in the Sony driver.
Accepted frames are copied directly from the SMAP FIFO into FASTNET-managed IOP memory. Completed frame records are submitted to the aggregation bridge instead of entering the normal EENET receive path.
The IOP patch does not classify packets by UDP port. Frame classification is performed later on the EE side. The FASTNET parser handles ARP, CONTROL and DATA traffic, while unrelated traffic is discarded.
EENET and FASTNET comparison
Hardware access
EENET: Sony's SMAP driver using stock dev9.irx services
FASTNET: The same hardware path with a focused receive patch in ent_smap.irx
IOP buffering
EENET: Each frame is copied into an IOP packet buffer
FASTNET: Frames are copied directly into larger aggregation chunks
IOP-to-EE transfer
EENET: Frames follow the normal ent_devm.irx and SIF handoff
FASTNET: Several frame records are grouped and transferred together with SIF DMA
EE processing
EENET: EE SMAP adapter, EENET, IP, UDP and socket delivery
FASTNET: Dedicated EE ring, lightweight Ethernet/IP/UDP validation and direct dispatch
Transfer granularity
EENET: Packet-oriented
FASTNET: Multi-frame chunks
IOP aggregation
FASTNET uses eight 32 KB chunks:
Frames are written directly from the SMAP FIFO into the active chunk. There is no intermediate packet allocation or second IOP-side copy.
Each record contains:
A chunk is queued when:
* The next frame does not fit
* The 24 KB fill threshold is reached
* The stream remains idle for about 1 ms
Several frames can therefore be transferred with one SIF DMA request.
This reduces DMA submissions, completion callbacks and synchronization work compared with handling every frame as a separate transfer.
SIF DMA and EE ring
Two persistent DMA contexts are used.
Each transfer contains one payload descriptor, or two when the EE ring wraps, followed by one commit descriptor.
The SIF DMA request queue contains 32 descriptor entries.
The commit containing the new EE ring write position is submitted after the payload:
The EE processes data only up to the committed position, so incomplete records are never exposed to the consumer.
After processing records, the EE reports its read position to the IOP so ring space and completed chunks can be reused.
EE-side integration
Sony's EE-side SMAP implementation remains linked from the stock ent_smap.a library.
It continues to provide the SMAP interface lifecycle, media state and EE-to-IOP transmission resources. FASTNET uses the existing transmission path for ARP and CONTROL replies.
Selected Sony EENET objects for malloc, socket2, mbuf and if are relinked with the required changes for the surrounding network environment.
FASTNET payload reception itself uses the dedicated EE ring and does not return to the normal socket receive path.
Measurements
The current 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 includes an actual EE-side payload copy.
A fine sweep from 10.0 to 12.0 MB/s was then performed in 0.1 MB/s steps.
The receive rate reached a plateau at approximately:
The first packet loss appeared at a requested host rate of 11.4 MB/s.
FASTNET combines Sony's existing DEV9 and SMAP hardware path with a focused RX patch in the IOP-side 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 module analysis, binary patching and DMA implementation are based on SCE SDK documentation, libraries and stock binaries.
Vibe coding was used to accelerate parts of the implementation, while the reverse engineering, architecture and final validation were checked against SCE SDK documentation and retail PS2 hardware.
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 that FASTNET reaches roughly 92.3 Mbps of payload throughput, using about 92% of the PS2's 100BASE-TX receive capacity.
EENET receive path
The standard EENET receive path moves each frame through Sony's general-purpose network stack:
Code:
PC
-> Ethernet / IPv4 / UDP
-> SMAP hardware
-> IOP ent_smap.irx
using stock dev9.irx services
-> IOP packet buffer
-> ent_devm.irx
-> SIF
-> EE-side ent_smap implementation
-> EENET
-> IP / UDP
-> socket receive buffer
-> EE applicationThe IOP-side ent_smap.irx handles the SMAP descriptors, FIFO access, frame validation and the hardware-facing receive work.
Accepted frames are copied into IOP packet buffers and passed to ent_devm.irx. They then cross SIF and enter the EE-side SMAP adapter before continuing through EENET, IP, UDP and the socket layer.
This provides the normal socket interface, but buffering, queueing, protocol processing and delivery are performed separately for each packet.
The SMAP RX ring contains 64 descriptors. The driver's initialization, indexing and memory layout are built around that fixed count.
FASTNET receive path
FASTNET keeps Sony's DEV9 and SMAP hardware handling, but changes how received frames leave the IOP:
Code:
PC
-> Ethernet / IPv4 / UDP
-> SMAP hardware
-> patched IOP ent_smap.irx
using stock dev9.irx services
-> direct SMAP FIFO copy
-> IOP aggregation chunks
-> batched SIF DMA
-> EE ring buffer
-> FASTNET parser and consumerA focused binary patch is applied to a known revision of the IOP-side ent_smap.irx.
The patch redirects the existing SMAP FIFO copy after the RX descriptor and frame length have been validated, but before the normal ent_devm.irx handoff.
The patch changes:
* The destination used by the SMAP FIFO copy
* The completed-frame submission path
* The continuation point after submission
The original RX descriptor handling, frame-length checks, MAC filtering and hardware error handling remain in the Sony driver.
Accepted frames are copied directly from the SMAP FIFO into FASTNET-managed IOP memory. Completed frame records are submitted to the aggregation bridge instead of entering the normal EENET receive path.
The IOP patch does not classify packets by UDP port. Frame classification is performed later on the EE side. The FASTNET parser handles ARP, CONTROL and DATA traffic, while unrelated traffic is discarded.
EENET and FASTNET comparison
Hardware access
EENET: Sony's SMAP driver using stock dev9.irx services
FASTNET: The same hardware path with a focused receive patch in ent_smap.irx
IOP buffering
EENET: Each frame is copied into an IOP packet buffer
FASTNET: Frames are copied directly into larger aggregation chunks
IOP-to-EE transfer
EENET: Frames follow the normal ent_devm.irx and SIF handoff
FASTNET: Several frame records are grouped and transferred together with SIF DMA
EE processing
EENET: EE SMAP adapter, EENET, IP, UDP and socket delivery
FASTNET: Dedicated EE ring, lightweight Ethernet/IP/UDP validation and direct dispatch
Transfer granularity
EENET: Packet-oriented
FASTNET: Multi-frame chunks
IOP aggregation
FASTNET uses eight 32 KB chunks:
Code:
8 x 32 KB = 256 KBFrames are written directly from the SMAP FIFO into the active chunk. There is no intermediate packet allocation or second IOP-side copy.
Each record contains:
Code:
frame length
Ethernet frame
alignment paddingA chunk is queued when:
* The next frame does not fit
* The 24 KB fill threshold is reached
* The stream remains idle for about 1 ms
Several frames can therefore be transferred with one SIF DMA request.
This reduces DMA submissions, completion callbacks and synchronization work compared with handling every frame as a separate transfer.
SIF DMA and EE ring
Two persistent DMA contexts are used.
Each transfer contains one payload descriptor, or two when the EE ring wraps, followed by one commit descriptor.
Code:
Maximum FASTNET usage:
2 contexts x 3 descriptors = 6 SIF DMA descriptorsThe SIF DMA request queue contains 32 descriptor entries.
The commit containing the new EE ring write position is submitted after the payload:
Code:
payload DMA
-> commit DMA
-> records become visible to the EEThe EE processes data only up to the committed position, so incomplete records are never exposed to the consumer.
After processing records, the EE reports its read position to the IOP so ring space and completed chunks can be reused.
EE-side integration
Sony's EE-side SMAP implementation remains linked from the stock ent_smap.a library.
It continues to provide the SMAP interface lifecycle, media state and EE-to-IOP transmission resources. FASTNET uses the existing transmission path for ARP and CONTROL replies.
Selected Sony EENET objects for malloc, socket2, mbuf and if are relinked with the required changes for the surrounding network environment.
FASTNET payload reception itself uses the dedicated EE ring and does not return to the normal socket receive path.
Measurements
The current 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 includes an actual EE-side payload copy.
A fine sweep from 10.0 to 12.0 MB/s was then performed in 0.1 MB/s steps.
The receive rate reached a plateau at approximately:
Code:
11.0 MB/s FASTNET payload
92.3 Mbps payload throughput
approximately 95 Mbps on the Ethernet wireThe first packet loss appeared at a requested host 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 RX patch in the IOP-side 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 module analysis, binary patching and DMA implementation are based on SCE SDK documentation, libraries and stock binaries.
Vibe coding was used to accelerate parts of the implementation, while the reverse engineering, architecture and final validation were checked against SCE SDK documentation and retail PS2 hardware.
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: