Page 2 of 3

Re: Hot-rodding my G5 - storage performance

Posted: Wed Aug 23, 2017 2:40 pm
by uunix
What OS are you going to run on the Talos?

Re: Hot-rodding my G5 - storage performance

Posted: Wed Aug 23, 2017 3:15 pm
by countzero
ClassicHasClass wrote:QEMU


Everything that I need to use is x86-only, and opensource doesn't provide a valid alternative, thus I wonder how much penalty on QEMU if it had to emulate x86 on POWER9.

Re: Hot-rodding my G5 - storage performance

Posted: Thu Aug 24, 2017 7:33 am
by ClassicHasClass
To answer both uunix and countzero: yes, it is designed to run Linux, and my unit will be running Linux (probably Debian ppc64le). I would be very surprised if the *BSD guys didn't come up with a port, though, given that the hardware is open stack.

As far as x86 goes, it would be purely software emulation, but QEMU does at least have some dynamic translation capability. The endianness matches, so that's some small improvement.

Re: Hot-rodding my G5 - storage performance

Posted: Thu Aug 24, 2017 10:28 am
by countzero
ClassicHasClass wrote:The endianness matches


Yup, POWER9 is LE as well as x86, but PowerPC and POWER machines have a special hw instruction which translates a word from BE to LE and LE to BE, and It takes just one clock cycle. It's not a penalty.

Re: Hot-rodding my G5 - storage performance

Posted: Thu Aug 24, 2017 5:23 pm
by Raion-Fox
ClassicHasClass wrote:To answer both uunix and countzero: yes, it is designed to run Linux, and my unit will be running Linux (probably Debian ppc64le). I would be very surprised if the *BSD guys didn't come up with a port, though, given that the hardware is open stack.

As far as x86 goes, it would be purely software emulation, but QEMU does at least have some dynamic translation capability. The endianness matches, so that's some small improvement.


I'll probably try to push for the BSDs to support it. I've got some ideas in the pipe as soon as I get the pressing issues off my plate.

You could, as well, if you wanted, boot a big endian lightweight Linux distro and try Mac-On-Linux. I'd give it a shot, at least.

Does the move to a Talos box mean anything for your Apple hobby programming?

Are you gonna keep Bruce and bruce's spares running?

Re: Hot-rodding my G5 - storage performance

Posted: Fri Aug 25, 2017 11:31 am
by ClassicHasClass
countzero wrote:
ClassicHasClass wrote:The endianness matches


Yup, POWER9 is LE as well as x86, but PowerPC and POWER machines have a special hw instruction which translates a word from BE to LE and LE to BE, and It takes just one clock cycle. It's not a penalty.


I'm well aware of this because TenFourFox uses those series of instructions (lwbrx, stwbrx, etc.) to emulate little endian typed arrays, and you're right that there's no penalty which allows that hack to work as well as it does, but applications have to be compiled to specifically do this or they'll just use native endianness (lwz, stw, etc.), so you still need software changes; it doesn't "just happen." The G3 and G4 had a very fast means of automatically treating areas of memory as little endian which was used most notably in VirtualPC, but this is not universal to the PowerPC line (the 604 and the G5 don't have it, for example).

The point is, now you don't have to worry about it, and software should "just work." I personally prefer big endian because it's how I "think" but that battle was lost years ago. And hey, the 6502 is my favourite CPU and it's little endian, so.

Re: Hot-rodding my G5 - storage performance

Posted: Fri Aug 25, 2017 6:01 pm
by countzero
ClassicHasClass wrote:I personally prefer big endian because it's how I "think"


0x12345789 is really {0x12,0x34,0x56,0x78}
std_logic(31 downto 0), love it :)

p.s.
A good and useful application to be ported to linux/PPC64 is OpenSCAD; it's a programmable Solid 3D CAD Modeller. It requires things like eigen, qtcore, qscintilla, glew, cgal, opencsg, which are all great clock cycles consumers as well as the C++ numerical library involved in the application, but this CAD is very useful for STL modelling, and it can be used to design interesting parts like the engine propellers of my ROV. It's also interesting because you can model parts with scripts.

I believe that your machine will give it a great horsepower!

Re: Hot-rodding my G5 - storage performance

Posted: Fri Sep 01, 2017 5:20 pm
by ibmfiles
Shiunbird wrote:Nowadays I use whichever combo of OS-Application works best for the task in hand. This means I touch three or four OSs daily and store all my data in a FreeNAS box.

But if it is really fast enough, based on your experience, I may get a Talos, retire the G5 and two servers, and hang everything on it, leaving it on 24/7.


I would think that PPC OS X would have more content than POWER Linux? At least, a fair amount of stuff was made for it. And some games, too.

Re: Hot-rodding my G5 - storage performance

Posted: Fri Sep 01, 2017 5:35 pm
by ClassicHasClass
Yes, definitely more is available for OS X PPC, but the machines that can run it are limited.

But qemu emulation is becoming more mature on that front, so a beast like a Talos can be the best of both worlds.

Re: Hot-rodding my G5 - storage performance

Posted: Sun Sep 03, 2017 6:32 am
by johnnym
Shiunbird wrote:http://www.sonnettech.com/product/tempossd.html
I like their products. And they won't be disposable if one day you decommission your G5, because they work with (and are even bootable) with PCs.

Do you also plan to test the read/write performance of two M.2 SSDs in PCIe adapters in your G5? :D All PCIe ports in the Powermac 11,2 models seem to have at least 4 lanes (everymac.com states 2 x PCIe x4, 1 x PCIe x8 and 1 x PCIe x16). So each could theoretically yield 1 GiB/s for reads and 1 GiB/s for writes. And even a single "good" M.2 SSD should outperform SATA SSDs easily. Would be interesting to see, what performance levels your G5 could reach with such SSDs.

Re: Hot-rodding my G5 - storage performance

Posted: Wed Sep 06, 2017 5:13 am
by Shiunbird
ClassicHasClass wrote:The G3 and G4 had a very fast means of automatically treating areas of memory as little endian which was used most notably in VirtualPC, but this is not universal to the PowerPC line (the 604 and the G5 don't have it, for example).

The point is, now you don't have to worry about it, and software should "just work." I personally prefer big endian because it's how I "think" but that battle was lost years ago. And hey, the 6502 is my favourite CPU and it's little endian, so.


I've always wondered why IBM dropped the feature on the G5. It took a while until Microsoft updated VirtualPC and performance was not that great. Some things ran better on a MDD than they ran on the G5 if I recall correctly.

We inherited little endian due to x86's massive success, but I wonder why architectures went little or big endian in the beginning.
Big endian seems to be logical, specially if you are reading memory dumps. =p

johnnym wrote:Do you also plan to test the read/write performance of two M.2 SSDs in PCIe adapters in your G5? :D All PCIe ports in the Powermac 11,2 models seem to have at least 4 lanes (everymac.com states 2 x PCIe x4, 1 x PCIe x8 and 1 x PCIe x16). So each could theoretically yield 1 GiB/s for reads and 1 GiB/s for writes. And even a single "good" M.2 SSD should outperform SATA SSDs easily. Would be interesting to see, what performance levels your G5 could reach with such SSDs.


Initially, I planned to get the best M.2 SSDs I could afford. But I keep a stable monthly budget for playing around and I was afraid of going that way, having compatibility issues and then losing money. I have a few projects running in parallel and investing too much into this one would delay the others. At some point, I planned getting a GeForce 6600 to have three PCIe slots available and see how fast I could go, but reason ended up speaking louder.

Once I'm done with my new NAS and replacing three Cisco routers with Banana devices, redoing my VPN and having the G5 in a final stable configuration, I plan to revisit this as academic curiosity, even if I end up selling the parts later for a loss. You know, for the science. M.2 SSDs could end up in my NAS as caches as well.

The G5 is my main box, so I can't afford having too much downtime for playing around.

Re: Hot-rodding my G5 - storage performance

Posted: Wed Sep 06, 2017 1:32 pm
by robespierre
Shiunbird wrote:We inherited little endian due to x86's massive success, but I wonder why architectures went little or big endian in the beginning.
Big endian seems to be logical, specially if you are reading memory dumps.


They were conventions used in closed corporate cultures. IBM always used big-endian numbering, and DEC always used little-endian.

Re: Hot-rodding my G5 - storage performance

Posted: Wed Sep 06, 2017 3:45 pm
by ClassicHasClass
I've always wondered why IBM dropped the feature on the G5.


The more I work on the metal of the G5, the more it's clear it was a hurry-up job on IBM's part to pacify Apple. It is the only Mac that uses PowerPC v2.0 encoding (that means at-bits on branches instead of y-bits, meaning every piece of software that had branch hints suddenly didn't have them on the G5) and the only Mac that uses dispatch groups for scheduling, and it is missing at least one PowerPC instruction that is just plain not implemented even though it's marked as non-optional in the spec (most notoriously |mcrxr| but I wouldn't be surprised to find others). And, as pointed out, it is completely lacking the G3 and G4 pseudo-little-endian mode. All of these things had to be worked around in software (as Microsoft did for VPC and as I do for TenFourFox) or in the OS.

The reason is simply because IBM took a POWER4 core off the shelf, stretched out the pipelines to boost the clock speed and bolted on the AltiVec design they still had sitting around from the 7400. And it shows: the 970 has far more in common with server POWER chips of that era than with any categorical PowerPC chip that preceded it. But it had massively better bandwidth and could be clocked really high, so if you could deal with the TDP it would stomp the G4 flat. And it did. Think of it as the PowerPC's NetBurst.

So the reason it isn't there is the chip was already way too complex and way too hot and Apple needed it way too quickly, so IBM just phoned it in. Adding that feature would have been too costly in design time and die size. A far better G5 would have been a 7450 with a better FSB and maybe some extra cache, and while they're at it to stretch the pipeline a little to ramp it up for the marketdroids. But Motorola wasn't interested in building such a thing and IBM wasn't interested in making a successor to a Motorola design.

Don't get me wrong: I really like my Quad, and I'll never ditch it. But I think the G5 had a lot of missed opportunities, and most of them was because Apple demanded too much and IBM gave them too little.

FWIW, VPC on my Quad runs well enough, but I like the older VPCs, especially on OS 9 where they can just run flat out. VPC 3 I think was the pinnacle for DOS and Win9x gaming.

Re: Hot-rodding my G5 - storage performance

Posted: Thu Sep 07, 2017 12:48 am
by Shiunbird
ClassicHasClass wrote:FWIW, VPC on my Quad runs well enough, but I like the older VPCs, especially on OS 9 where they can just run flat out. VPC 3 I think was the pinnacle for DOS and Win9x gaming.


Thanks for all the interesting info.

I have the same experience. VPC works.
I've heard one of the Connectix VPCs for OS 9 supports 3D hardware acceleration. Do you know if that's true and what version that would be?

I've also now and then looked into getting their playstation emulation software.

Re: Hot-rodding my G5 - storage performance

Posted: Thu Sep 07, 2017 2:57 am
by 1byte
ClassicHasClass wrote:
I've always wondered why IBM dropped the feature on the G5.

The more I work on the metal of the G5, the more it's clear it was a hurry-up job on IBM's part to pacify Apple.


Do you feel its a poor implementation then? I've always wanted one of the quad G5's, but I wonder if getting one of the IBM systems would be better. I have no Mac OS requirement, and my use would be purely linux development.