Ramblings on Software and Tech

I don't use the most powerful laptop I can get my hands on, my hardware budget tends to go to the bigger workstation mostly. I purchased an Asus ProStudio W7604 in late 2024 with an i9-13980HX Intel CPU. Less powerful than the ROGs or TUF that I would normally get, but a competitive price (that was right before the whole tariffs debacle started).

The CPU is one of those reasonably new architectures with a makeup of 'Performance cores' (8 cores, 16 threads) and 'Efficiency cores' (16 cores, 16 threads). The cores have different maximum boost and sustained frequencies. I thought I could just set the power profile to 'performance' and be done with it.

That worked well enough for a while, until I noticed something was off. I maintain a pretty large C++ build job that can be done either on Linux or on Windows over WSL2. I dual boot this laptop between Arch and Windows 11, and I had recently started using it to test those builds.

I noticed that Windows was working the system a lot harder that Linux would. Upon closer inspection I saw that on Linux the P-cores would happily settle at 2.8GHz for the duration of the build, while Windows had no qualms running them at 3.8GHz. Rhu rho.

That sent me down a rabbit hole of attempts and dead ends before I could improve the situation. I used Kagi's Research Assistant and tried various things .. the traditional ways to talk to talk to the Embedded Controller (EC) don't work (hardware is too recent?), the more modern "Windows Management Instrumentation" (WMI) did not work (no firmware support?).

After tweaking kernel command line (intel_pstate=active acpi_enforce_resources=lax) I was able to issue a direct ACPI call to set EC thermal profile to performance: echo '\_SB.ATKD.FANL 0x02' > /proc/acpi/call and do a bunch of other magic with the throttled service to set the CPU package power levels higher for sustained used (around 100W, although I think I could go a little higher).

Nothing has melted yet. The build on Windows takes 37 minutes, the build on Linux is now 20 minutes.

I put the 10 minutes difference down to better I/O performance and the Linux kernel being generally better. It seems though that Windows bounces between PL1 and PL2 every 20 seconds or so. It's definitely losing an edge there.

Here's a more detailed summary produced by Kagi once I got everything working - more detailed information if you run into a similar issue:

ASUS ProStudio W7604 / i9-13980HX / Arch Linux — Performance Optimization Session Summary

There are lots of cheap solar panels on eBay, most of them making outlandish performance claims. A particular offer caught my attention: a small, flexible panel that supposedly produces 300W at 18V. They are available from multiple vendors but it's basically all the same product (here, here and there).

I wanted to have a little fun and see how much juice I could actually get out of those, and if they are worth anything. I was hoping for 150W, and anything beyond 200W would be really good. I also saw some YouTube videos claiming one could build a cheap rheostat by putting some electrodes in salty water, which also sounded fun. Here's a summary of the adventure, where I found out yet again that theory rarely survives an encounter with practice.

My first attempt involved using a water heating element buried in sand. The one I bought is way off the actual power output of the panels, ended up being completely useless and made something like 10 Watts. At that point I started to understand maximum power point tracking, and since I had no idea what the actual power output of the panels was, I decided I needed a rheostat to find out.

I fumbled around making various contraptions: using some thin galvanized plates, even trying a coil of sorts. I learned that distance between the electrodes doesn't matter much, that once you add enough salt there's no point adding more, and that the resistance of my contraptions was way too low, the panels were operating close to short circuit and not producing anything.

I also concluded that Ohm meters are pretty much useless for this, and so are the clamp-style multimeters for measuring current; I needed shunt resistors. My theory about the Ohm meter is that they use a very small voltage and the rheostat setups are non-linear; You are not measuring anything useful unless you are close to your target voltage.

I also picked up some wirewound resistors, enough to dissipate up to 500W of power. I wasn't getting anywhere with the electrolyte rheostat, so I wanted to try something different. But redoing the wiring constantly to adjust the resistance is completely unpractical.

I eventually went back to a rehostat design with steel rod electrodes. Only two at first, then four later so I had more range for adjusting the resistance. With two to three teaspoons of salt (rock salt used to mel ice on driveways) in the water, and the half-inch steel electrodes I am able to range between 3 Ohms and 15 Ohms and explore the "knee" of performance and find the MPP for the panels.

After a few more days of experiments, during which I found that loose connections can easily create one or two Ohms of parasite resistance and completely screw your results, I got a few sessions of data that I fell are reasonably trustworthy.

Unfortunately I could never get the panels above 40W. It's North Texas in May and my house panels are performing at their top. It was a little hazy though, so maybe on an even better day I could hope for 50W, but I'm reasonably sure those panels will never produce more.

For an extra bit of fun I put the two panels in series and got close to 70W, as expected. That worked at higher voltage and a higher MPP resistance, which was a good way to validate the range on my rheostat design.

What's next? Well, it's raining all of next week for one. I plan to acquire better panels and set them up on my backyard pergola. There should be enough space for about 2kW. That should slot in nicely with an Oupes Mega 3 power station for an off-grid setup. I can't live out of an RV quite yet, but I'm taking steps.

We are quite snowed in over here, so I took the time to add a RSS feed and comments support.

I reviewed various options (Disqus, Commento, Staticman), but I've always wanted to leverage Masto for this stuff so we'll give that a try.

See you in the comments!

With RAM prices exploding for consumers, I was wondering if renting cloud systems would be more practical and cost effective now than it used to be. I last had a look at this about 5 years ago, and it was pretty rough.

I went to EC2 as they seem to be the leader of the pack and set up an AMI to play with. I installed Unreal Engine, built some test projects to see what kind of day to day experience I should expect for the basic build and test iteration.

A few details on the setup: I picked Windows Server 2025 in us-east-1 with a 100GB NTFS root volume, and a 250GB ReFS 'Dev Drive'. By some accounts ReFS improves dev workloads (compile times and asset baking) by 15 to 20 percent.

You can pick a standard AMI and install the NVidia drivers yourself. Do not install the public drivers, "Tesla drivers" or "TCC drivers" - they will not give you any graphics capabilities, install the WDDM GRID or gaming drivers instead. It's fiddly and annoying though, so just pick a pre-configured AMI from NVidia.

Now the good surprise - Amazon offers DCV for remote desktop streaming and it's free on EC2. Easy to deploy and easy to use out of the box. It caps out at 60 fps but it'll get you started quickly.

I wanted something a little better so I installed RustDesk, which claims to support up to 120fps streams. If you want more than 30 fps though, you need either a subscription, or direct to IP connection rather than the "peer rendez-vous" system that RustDesk offers by default. That did take some work, poor documentation or maybe I get confused easily. TL;DR just install RustDesk client on both sides and don't bother with the self-hosted Windows services thing. On the server side go into Settings -> Security and Enable direct IP access, and voilà.

The not so great part: the best you can get on EC2 are Tesla L40S GPUs (G6e instances). Those are roughly equivalent to GeForce RTX 3060 Ti / Radeon RX 6700 XT - sure they can have up to 48GB of VRAM but that's not particularly interesting in my use case. So you're left with very middle-of-the-road GPUs.

I ran a fillrate limited game with simple shading over 1080p virtual display resolution, balancing out game fps using r.ScreenPercentage to find an optimal point in stream fps and landed on the game scaled 72.9%, 1400x788 at 100fps, and the stream at 60 fps with 70ms latency (nvenc H265).

That feels very serviceable but it's not great. I reproduced this same setup against my personal machine with a RTX 4070 super and at 72.9% 1400x788 the game runs at 145fps and the stream reaches 90 fps with 45 ms latency. That feels noticeably better of course.

Some very basic thinking about cost. I put together a build on PC part picker that I'd call roughly equivalent (GeForce RTX 3060 Ti 12GB, 2TB SSD storage, 64GB RAM, AMD Ryzen 5 5600X 3.7 GHz) for about $2k. The g6.2xlarge is $0.98/hour, round that to $1. Let's say you're disciplined enough to use 50h/week of the instance and turn it off at night (not as easy as it sounds), that's $200 a month in compute costs. Maybe add $50 for your EBS volumes. Your break even is at 8 months.

Unless you're a very small studio and you're trying to get funded, this doesn't seem very appealing. Investors prefer capital expenses over running costs, in my experience they really like to see amortized IT assets on your balance sheet.

For CI and asset bakes, automated regression testing, keeping track of your VRAM / RAM / game and render time envelopes this can be a nice solution. There are other advantages of course, you can scale your specs up and down quickly, you can onboard a little faster..

If you want really high end GPUs, Google offers the RTX PRO 6000 (96GB) - but it'll cost you ($3.5 to $4 / hour). Then there's a dozen smaller cloud companies specialized in GPU hosting (GPUHub, Vast.ai etc.) with more competitive pricing but they are focused on inference and it's not clear they'll support graphic workloads.

My blog was hosted on typepad until last summer, when the antique and deserted platform decided to close for good, with very little heads up and quickly trashed all it's remaining content without offering any backups. I didn't have the time or energy to do anything about it then, and I thought that I had a backup anyway, so I let that slide.

Welp.

Lucky for me, archive.org has a recent snapshot, all posts, images and comments.

We are now self hosted on the Lektor CMS.

https://blog.ttimo.net/ is the forever home for this blog now.

Recovering and converting from archive.org was a pretty involved process, I had to extract out the content from the html soup and iterate quite a bit to put things back in a readable state. It's probably still a little messed up in places, let me know if you notice something.

Now, I don't think the content on here was all that important - a lot of it is very outdated - but it's a nice historic record for myself and I'm hoping to start posting more regularly again. New year resolutions and all that.

I don't have a comment system in place yet. I'll get to that. Get on Mastodon in the meantime.

I donate to archive.org and you should too .. not just for saving my crap, but for all the other great stuff they do!