Blzut3's Weblog

Weblog ECWolf ECWolf Wiki
News

New development builds server 2018-11-13 04:44:03

For those who aren't familiar I've been building most of the binaries on the DRD Team devbuilds site. How that came about is that people were requesting ECWolf development builds, but no one was volunteering to do them so I just setup some scripts and a VM on my Mac and it has been building (mostly) nightly for several years now. Since I already expended the effort to setup an automatic build for ECWolf I ended up absorbing most of the other builds as well.

The build Mac was a base model late 2009 Mac Mini. Shortly after it took on the build server role I upgraded it with 8GB of memory and a 1TB SSHD. Which sped things up a lot, but of course there's only so much a mobile Core 2 Duo can do. Fast forward the end of 2016 and with the release of Mac OS X 10.12 and even though the late 2009 Macbook with identical specs to the Mac Mini is supported, I end up stuck on 10.11 (yes I'm aware there are work arounds to install even Mojave on it). Between the Core 2 just not cutting it anymore by my standards and it no longer being supported by Apple it was time for a new machine, but of course this was right at the time Apple was forgetting that they even made Macs.

Now while I realize it might be a tad ironic since I buy retro computer hardware all the time, I of course couldn't bring myself to buy a 2 year old computer much less a 4 year old one. That's even ignoring the fact that the 2012 models were higher specced. But here we are in November of 2018 and Apple finally released a new Mac Mini, with non-soldered memory no less! So of course I bought one. For those who want to know I got the i7-8700B with 1TB storage, 10G Ethernet (since my NAS and main desktop are 10G), and of course 8GB of RAM since I can upgrade that later.

Here we are 9 years later and once again paying almost as much for the Mac as my desktop and getting 1/3 the power.

Now that I get to basically start over from scratch I'm taking some time to make my build scripts a little more generic. Over the years I've had people ask to see my scripts (mostly since they wanted to help fix some build issues), which wasn't really useful since they were just basic "make it work" style throw away code. This time around I want to get something I can throw up on github, not because they'll be particularly reusable by anyone but rather to provide a way to make what's actually happening more transparent.

I haven't talked about the elephant in the room yet though: Windows. When I initially setup the build server in 2012 I decided to use Windows Server 2012. The primary reason for this was I was hoping to use the server core mode to reduce memory usage, on top of Windows 8 seemingly using less memory than Windows 7. This was especially important since at the time the Mac only had 2GB of RAM. This was fine until Visual Studio 2017 came along and required Windows 8.1. What most people don't know is that Windows 8.0 and 8.1 while treated as the same OS by Microsoft are treated as separate operating systems when we're talking 2012 vs 2012R2. In other words both 2012 and 2012R2 are supported for the same period of time and there's no free upgrade between them. So everyone that was using 2012 for build servers got screwed.

Due to how slow the 2009 Mac Mini was, the fact that the builds were working, and laziness I didn't bother doing anything about it. But now that I have a new machine I need to figure out what I'm going to do for the Windows VM. I would like to try server core again given that Windows containers are a thing, we now have an SSH server on Windows, and I would get to control when updates are applied. But after being screwed over with new Visual Studio versions requiring the "free upgrades" to be applied I'm not sure this route is viable especially given the cost of Windows Server. Might end up just having to use Windows 10, which I don't really have a problem with except that the VM will be suspended most of the time so the auto updates could pose some problems with the builds reliably kicking off at the scheduled time. Still not sure what to do here.

Anyway, with all of that said to pad out this post so that it's more than a few sentences. If anyone was wondering, it's not particularly difficult to setup a PowerPC cross compiler on Mojave. Which actually surprised me since my previous setup involved using compiling and moving an install over from Snow Leopard, but it seems that the XcodeLegacy scripts got a little less quirky since the last time I ran them. Right now it's GCC 6, since that's what I had working on my PowerMac, but I've heard newer does work. Just need to try it, confirm that it works, and update the article.

AMD K6-2+/K6-III+ freezing in Quake 2018-04-22 02:54:07

Recently was helping my brother with a K6-III+ build for DOS gaming and had to debug a rather odd issue. When enabling write combining Quake would freeze or sometimes crash quickly when running in high resolutions (the few other games I tested seemed to be fine). Didn't matter if the CPU was running at 200MHz, underclocked FSB, you name it. The board I was using is a Biostar M5ALA Rev 1.1 with the ALi Aladdin V chipset, which is supposedly the more stable of the Super Socket 7 chipsets. I did eventually figure out that disabling the L2 and L3 caches or using a K6-2 (non-plus) would make the game stable, but also using a SiS530 based PCChips board (probably the cheapest board I've ever used) would be perfectly stable as well ruling out issues with the CPU.

However it turns out the real issue was much simpler than a hardware issue. Running speedsys produced a rather anomalous result for memory writes.

I initially ignored the result, but after spending a few hours with a friend trying to figure out what could be wrong with k6wcx, we tried installing k6dos.sys. Not only did this boost frame rates well beyond what k6wcx was doing (90+fps in 320x200, 30+fps in 640x480 vs about 70 and 20 respectively), but Quake was suddenly stable. Furthermore setting the memory regions with k6wcx gave an additional boost in speed without issues! But more importantly the write test were correct in speedsys:

So it appears that the M5ALA sets the cache to write-through instead of the generally preferable write back! It also seems that write through doesn't agree with write combining.

New server plus some odds and ends 2018-02-04 06:58:52

I have finally purchased my own hosting and moved this site off MancuNET. MancuNET has been great for the last 5 years, but between having a full time job and all the sales of S3DNA I figured it was quite silly to be using someone elses resources. Plus I started using Matrix and due to some complexities in regards to SSL certs running things myself just proved to be easier. (For those who aren't aware of Matrix, it's a fully open and federated communication platform. Similar to Discord or Slack in feature set, just 100% open.)

While not really related, I also decided to move ECWolf's repositories over to a Bitbucket team. When I initially move ECWolf from SVN over to Merurial Bitbucket didn't have the teams feature so I had the repo under my name. While I'm still largely the sole contributor to ECWolf I still figured it's better to get the transition out of the way. The big benefit is that all the ECWolf related repos are more discoverable since they won't get buried under any other projects I may be working on. The downside is everyone needs to update their clones to point to the new location.

ECWolf also has a new logo/icon courtesy of NeuralStunner. The hope here is that the new icon still feels related to Wolfenstein while being freely licensable.

Suppose this is as good of time as any to formally talk about my plans for ECWolf 1.4. I think it's clear as day to anyone that I perhaps scoped too much into the 1.4 release. At least these days where I don't have quite as much time to work on hobby programming as I used to. In order to narrow the focus I have decided to drop Mac Wolfenstein support from the 1.4 goals. To be clear this means nothing long term as ECWolf will get Mac Wolf support, but I personally would rather focus on finishing the initial multiplayer code for 1.4.

On the topic of refocusing, I would like to formally say what everyone else has no doubt figured out before me: I no longer have time to actively participate in GZDoom/Zandronum development. I know, real shocker here but making this formal really does lift a lot mentally. I've definitely thought way too much about the shared code in ECWolf since at this point my contribution rate really is that of any other third party contributor. I will of course still be doing the builds that I have been doing so this really is just a statement for my own sake since as far as everyone else is concerned things are continuing as normal.

Now while things have been quite slow, things haven't been exactly dormant over the last year either. A few months ago I had a random epiphany that adding more Z height support would actually be quite easy to do, so now ECWolf can render things at varying heights. Admittedly it's not especially useful right now, but its a step in the right direction and it makes for more interesting screen shots than the feature actually is.

Sorry for the lack of content here in 2017. Last year has been the year of projects that get stopped just before their complete for one reason or another. I wanted to write about the video capture card I bought, but then I discovered my computer was bottlenecking its capabilities so it wouldn't be fair to the reader to speculate. I had hoped to write about my over the top retro computing build, but that still has a lot of small details to finish out. I finally purchased a new primary computer and the fun story I planned to write in regards to that got delayed by early adopter issues. For those wondering I'm now running a Threadripper 1950X. Quite an amazing system for development and brings my ECWolf compile times down to 2 seconds. Not that they were particularly long before, but even everything else I work on now has negligible compile times compared to the Lynnfield/Nehalem system I had before. So glad to finally be beyond quad core processors!

Oh and I also now own ecwolf.org which redirects to any page in the ecwolf section of this site. Don't have any immediate plans to host the site under the domain.

A thought on Intel Kaby Lake 2017-01-14 01:40:32

One of the weird things I do to pass time is study the entire range of x86 CPUs available for purchase. Often when I hear people talking about processors I only ever hear about the the Intel Core i5 or i7 with the occasional budget build using the Core i3. There was of course the unlocked Pentium G3258 while that was current, and that was interesting to me for a reason that I don't think I've ever heard anyone talk about.

Specifically what interests me most about Intel's low end (Celeron, Pentium, and Core i3 although only Haswell and Skylake there) is that it has traditionally had ECC memory support, which is normally only associated with the Xeon processors. My best guess as to why is that the SKUs are low enough volume for server use that it doesn't make sense to separate them, but I could be completely off there. This fact turned out to be convenient for my brother who upgraded to a Celeron G1850 (Haswell) for a little while until I was able to help him acquire a Xeon E3 1285Lv4 (sometimes you just need a CPU you can't just buy on Newegg). The latter being a very interesting SKU since it has a lower TDP than the normal 1285 and benchmarks the same if not slightly better for some reason. (My guess here is that the normal 1285 would benchmark faster in cases where both the Iris GPU and the CPU cores are utilized at the same time.) It has a slightly higher stock clock than the Broadwell i7 and according to Intel Ark has a faster memory controller although probably due to the obscurity no motherboard I can find supports the faster memory clock and ASRock Rack apparently had no interest in talking to me about it. Of course overclocking could close this gap, but the i7 doesn't have ECC. For those that may be wondering, the Celeron offered a better experience than the unfortunately water damaged (but still working thanks to ECC) dual Opteron 285 workstation that he had before. Don't have hard numbers on that transition, but games were noticeably smoother on the Celeron, and the Xeon was a vast improvement over that.

But this post wasn't about Broadwell, with Kaby Lake we see an unlocked i3 being released. At first I was pretty excited about this since based on Skylake this would have had ECC support and overclocking (like the Pentium G3258 apparently does). Alas though it appears that Intel has decided that ECC on the low end should be no more. At least if Ark is to be believed. Quite disappointing, but of course it doesn't matter much since I don't think any ECC supporting board allowed overclocking (since it would have required using the server C series chipsets).

What we also see this generation is that the Pentium is now shipping with hyperthreading enabled. This would seem at first to really blur the line between the Pentium and i3 seeing as for whatever reason Intel drops the cache down to 3MB on the i3-7100. Many people will probably forget to mention, or at least not notice, that the i3 does have one feature over the Pentium/Celeron lines and that is AVX instruction support. This won't make a whole lot of difference in the near term since I think the only place users are likely to encounter AVX at the moment is with compression, but I suppose in the future it could become a problem as I'm hearing some people are having trouble today with their Phenom IIs not having SSSE3 instructions. I'm guessing those buying a Pentium or Celeron don't plan on hanging onto the machine as long though.

Not that I have any plans to buy a Kaby Lake system, just felt like writing about some things I found amusing. Personally I'm hoping that AMD's Ryzen lives up to their claims and more specifically that Naples (Q2) is everything that we think it is. Definitely think I'm ready to move on from quad core CPUs.

1 2 3 4 5 6 720 21 »

 

© 2004-2018 Braden "Blzut3" Obrzut