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.
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.
Note:
As a small bonus, PS2NBD uses the original PlayStation 2 BIOS OSD font for its on-screen interface.
On a retail PS2, pressing the physical RESET button once performs a safe power-off sequence instead of an immediate reset.
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.
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.
PS2NBD B143 Preview is now available.
This is a public preview/test build, not a final release.
Requirements
* Windows 10 or Windows 11
* PowerShell 7 or newer
* Python 3
* PC and PS2 connected to the same local network
* UDP ports 31002 and 31003 allowed through the firewall
Default network addresses:
* PC: `192.168.1.101`
* PS2: `192.168.1.102`
These addresses can be changed through the host launcher parameters when required.
Retail PS2
1. Extract the preview package.
2. Start `tools\run_ps2nbd_host_probe.ps1` with PowerShell 7.
3. Boot `out\ps2nbd_ee.elf` using uLaunchELF or another ELF launcher.
4. Wait for the FASTNET session to connect.
5. Use the interactive host console to run commands.
PCSX2
1. Make the `out` directory available as the PCSX2 `host:` root.
2. Keep `pcsx2boot.elf` and `ps2nbd_ee_debug.elf` in the same directory.
3. Boot `pcsx2boot.elf`.
4. Start the Windows host launcher.
5. Use the interactive console normally.
Basic interactive commands (PC Host Script)
help
Displays the available commands.
hello
Starts or refreshes the FASTNET handshake.
ping [text]
Sends a simple message to the PS2 and checks the control path.
fnstatus
Requests the current FASTNET status from the PS2.
status
Displays the current host, session and stream status.
eestreamcopysweep
Runs the automatic copy test from 3 to 10 MiB/s.
eestreamfinesweep
Runs a detailed copy-path sweep from 10.0 to 12.0 MiB/s in 0.1 MiB/s steps, using the currently selected pacing mode.
finebaseline
Runs the 10.0–12.0 MiB/s fine sweep using baseline pacing.
finehybrid
Runs the 10.0–12.0 MiB/s fine sweep using hybrid pacing.
finespin
Runs the 10.0–12.0 MiB/s fine sweep using spin pacing.
pacing [baseline|hybrid|spin]
Selects the pacing mode used by subsequent stream and fine-sweep tests. Enter `pacing` without an argument to display the current mode.
stop
Stops the active stream test.
reset
Resets the current PS2NBD session.
poweroff
Requests a PS2 shutdown.
Host logs are generated locally under `.tmp\host_probe`.
Please report the PS2 model, network setup, command used and visible error message when reporting a problem.
This is a public preview/test build, not a final release.
Requirements
* Windows 10 or Windows 11
* PowerShell 7 or newer
* Python 3
* PC and PS2 connected to the same local network
* UDP ports 31002 and 31003 allowed through the firewall
Default network addresses:
* PC: `192.168.1.101`
* PS2: `192.168.1.102`
These addresses can be changed through the host launcher parameters when required.
Retail PS2
1. Extract the preview package.
2. Start `tools\run_ps2nbd_host_probe.ps1` with PowerShell 7.
3. Boot `out\ps2nbd_ee.elf` using uLaunchELF or another ELF launcher.
4. Wait for the FASTNET session to connect.
5. Use the interactive host console to run commands.
PCSX2
1. Make the `out` directory available as the PCSX2 `host:` root.
2. Keep `pcsx2boot.elf` and `ps2nbd_ee_debug.elf` in the same directory.
3. Boot `pcsx2boot.elf`.
4. Start the Windows host launcher.
5. Use the interactive console normally.
Basic interactive commands (PC Host Script)
help
Displays the available commands.
hello
Starts or refreshes the FASTNET handshake.
ping [text]
Sends a simple message to the PS2 and checks the control path.
fnstatus
Requests the current FASTNET status from the PS2.
status
Displays the current host, session and stream status.
eestreamcopysweep
Runs the automatic copy test from 3 to 10 MiB/s.
eestreamfinesweep
Runs a detailed copy-path sweep from 10.0 to 12.0 MiB/s in 0.1 MiB/s steps, using the currently selected pacing mode.
finebaseline
Runs the 10.0–12.0 MiB/s fine sweep using baseline pacing.
finehybrid
Runs the 10.0–12.0 MiB/s fine sweep using hybrid pacing.
finespin
Runs the 10.0–12.0 MiB/s fine sweep using spin pacing.
pacing [baseline|hybrid|spin]
Selects the pacing mode used by subsequent stream and fine-sweep tests. Enter `pacing` without an argument to display the current mode.
stop
Stops the active stream test.
reset
Resets the current PS2NBD session.
poweroff
Requests a PS2 shutdown.
Host logs are generated locally under `.tmp\host_probe`.
Please report the PS2 model, network setup, command used and visible error message when reporting a problem.
Note:
As a small bonus, PS2NBD uses the original PlayStation 2 BIOS OSD font for its on-screen interface.
On a retail PS2, pressing the physical RESET button once performs a safe power-off sequence instead of an immediate reset.
Last edited:
