Re: gem driver for sun4m

[Erik LaBine <erik%eriklabine.com@localhost>]

On Tuesday, July 14, 2026 6:58:34 PM Eastern Daylight Time you wrote:
> So far, it seems to be working out quite well. I'm able to get about the
> speeds you'd expect running with flash storage through a BlueSCSI and I
> haven't seen any issues with stability. I'm preparing a patch now pending a
> regression test on sparc64. I'd appreciate feedback or testing from other
> port-sparc users, if there's any interest.

That took a lot longer than I thought it would, my apologies for the delay in 
follow-up. In the end, I also wanted to double check my numbers for sparc.

Downloading seems to be consistently faster than uploading. Without TLS 
overhead, both download and upload speeds scale pretty linearly with 
frequency. Except when MP gets involved, and then at least on iperf3, it's 
simply worse. Which I do find hilarious.

I ran several synthetic load tests with iperf3 to check the performance over 
time. This was a mix of IPv4 and IPv6 with TCP traffic, as well as UDP at 300 
kbit/s and 4 Mbit/s, picked slightly arbitrarily. I also included some longer 
runs (~5 minutes of sustained TCP). It all seemed very promising for 
stability!

"Sunny"
170 MHz TurboSPARC, 256 MB of RAM
Up: 26.5 Mbit/s
Down: 30.1 Mbit/s

"Share"
85 MHz MicroSPARC II, 64 MB of RAM
Up: 12.3 Mbit/s
Down: 14.4 Mbit/s

"Saguaro"
125 MHz HyperSPARC, 512 MB of RAM
up: 19.1 Mbit/s
Down: 20.8 Mbit/s

2x 125 MHz HyperSPARC with MP kernel
Up: 13.7 Mbit/s
Down: 19.0 Mbit/s

I did want to test with the multiprocessor kernel as well, even though my 
SS10's power supply struggles to run both of these modules for more than about 
10-15 minutes. I don't think the gem driver made it any less stable, at least. 
No regressions noticed on sparc64, either, which I was slightly worried about.

The switch was a Catalyst 3508G-XL connected back to the rest of the LAN with 
an SC to LC patch cable. The server was running iperf3 on amd64 and should 
have been able to handle pretty well any traffic these machines could throw at 
it.

This is my first attempt at submitting a kernel patch, so I hope this is the 
correct way to go about it. The patch is under kern/60453

Erik