Feasibility experiment upgrading OASYS to Intel Core 2 Duo

[jerrythek]

Jerry is completely correct.
- Dan

I love to read that - I just may frame this.

On another note, I wonder if when Jerry says that the software was "optimized" for the hardware, it means that there are hard limits set in the software. For example, the maximum polyphony might be hard-set, not necessarily with the intention to limit future upgrades but to provide a more stable system.

I'm not going to go too deep into this, as we don't divulge everything about our designs or future plans.

But Dan and others have stated many times in the past that we optimize the synth engine to make maximum use of the instructions/DSP power of the processor at the lowest levels. So it is much more than just limiting polyphony - it is timing of the voice triggering, envelopes and LFOs, EVERY part of the synthesis and effects engine to wring the best timing and most capable performance from the system.

This is why Elvis' very knowledgable but misplaced assumptions of how a computer and code running under Linux would automatically benefit from the processor change are not quite correct. We are NOT running a Linux app on a PC, we are running a highly optimized custom set of applications on a Pentium processor, treating it more like a DSP. There's some Linux underpinnings/routines in there, but we are NOT a linux-hosted app.

So significant performance gains don't come automatically - our software experts have to do things to take advantage of the new power.

I'm venturing far enough away from my expertise here, so let me stop now.

It's a very interesting discussion and I don't mean to stop it, I'm just offering some insights into what is going on and what is possible.

Regards,

Jerry

[MartinHines]

It's a very interesting discussion and I don't mean to stop it, I'm just offering some insights into what is going on and what is possible.

Regards,

Jerry

Jerry,

If Korg Japan DOES ever decide to create an OASYS 2, please tell them most existing owners of the OASYS would definitely be interested in some type of "hardware update option", if it were feasible.

[steve m]

As per my reply in another thread regarding motherboard availability in the future, surely Korg must have worked with various motherboards for Oasys and know that this type of thing can be done. Otherwise what future will Oasys have when the 'original' motherboards are no longer available ?

I would hope that the Oasys R&D team don't expect that the same motherboard will be available 4 or 5 years after the original production run. They must have a solution for the future, surely ? If not, it's owners like us that have no option but to try experiments like this. Well done ! If the work that you do now helps many users down the track with their motherboards as they fail, we will all owe you a beer!

I will be watching this thread with great interest, the work you are doing now may guranatee that your Oasys will still be going in 10 years time.

Good on you for having a go, I salute your endeavours !

[ski]

Jerry is completely correct.
- Dan

I love to read that - I just may frame this.

One of these days I wanna get me one of those!

[MartinHines]

I would hope that the Oasys R&D team don't expect that the same motherboard will be available 4 or 5 years after the original production run. They must have a solution for the future, surely ?

I assume Korg Japan purchased a certain number of motherboards w/CPUs as spare parts inventory, which would be similar to every other product they have produced.

As an example, Korg Japan has/had an inventory of spare parts for the Trinity workstations, which would have included the main processor boards.

Similar to any other keyboard manufacturer, Korg won't support the OASYS indefinitely, including spare parts.

[mdh]

The OASYS application and the various synthesis engines are probably separate processes, co-operating together to form the complete system and would benefit from multiple execution units (i.e. CPU cores). You don't need to do any further optimization to the code to immediately gain these benefits. You will just have to enable multicore processor support in the linux kernel to immediately take advantage of the multiple cores.

Not quite true, as we've discussed before on various hardware-upgrade musing threads, adding multiple cores introduces other issues you need to thoroughly examine, for example the Intel chips have small caches and use cache sharing amongst the cores so context switching can introduce latency issues which in the (presumably) RT environment you need to fix.

What I've always liked is the platform the OASYS provides... notice how neatly everything is put together and how easily replaced it all is?
Who knows what Korg has up their sleeve for the future? They sure as hell aren't going to announce it pre-emptively in a public forum so their competitors can snarf their IP.

[elvisjohndowson]

Not quite true, as we've discussed before on various hardware-upgrade musing threads, adding multiple cores introduces other issues you need to thoroughly examine, for example the Intel chips have small caches and use cache sharing amongst the cores so context switching can introduce latency issues which in the (presumably) RT environment you need to fix.

See the following article: http://www.behardware.com/articles/623- ... -test.html . (You should also take at look at the application benchmarks towards the end of the article on performance between the Pentium D and the Core 2 Duo)

Compared to the Pentium D, the Core 2 Duo caches are larger and are an order of magnitude faster in terms of latency, (per core)
L1 code (12k vs. 32k)
L1 data (16k vs. 32k)
L1 D latency (4 cycles vs. 3 cycles)
L2 (2x2MB 8-way vs 4MB 16-way)
L2 D latency (31 cycles vs 14 cycles)

See also the fact that the newer processors (Intel Core 2 Duo E6850) have a faster front side bus (1333Mhz) and you could couple it with newer DDR3 memory.

Intel has also improved on the cache memory access. read the article on smart memory access : http://www.intel.com/technology/archite ... abs_engage

For sure, you will have to optimize on data access patterns, it's true for any multi-processor. But the benefits are there, ready to be exploited.

Look at the technology of the IBM Cell Broadband Engine used for the PS3, for example. Developers have already addressed these challenges on a multicore processor (9 in total, 1PPU and 7/8SPU vector processors). (7SPUs used on the PS3 version, 8 for the standard versions).

So there are many performance gains that can be realized.

Best regards,

Elvis Dowson

[danatkorg]

Compared to the Pentium D, the Core 2 Duo ...

Yes, there are absolutely many hardware improvements in the Core 2 Duo.

So there are many performance gains that can be realized.

As noted earlier, not without changes to the OASYS software.

Best regards,

Dan

[Synergy]

Jerry is completely correct.
- Dan

I love to read that - I just may frame this.

One of these days I wanna get me one of those!

You are absolutely... Doh!!

[elvisjohndowson]

So there are many performance gains that can be realized.

As noted earlier, not without changes to the OASYS software.

I see the situation more clearly Dan.

I was just responding to mdh's comments to highlight that there have been some changes factored into the architecture to mitigate the effects of separate cores and common cache.

Perhaps, one way of looking at things would be to release a technology upgrade kit, with software updates being released over time, to tap into the extra power that the updated platform provides you with time. So, the changes to the OASYS software could come with time.

Best regards,

Elvis Dowson

[mdh]

Compared to the Pentium D, the Core 2 Duo caches are larger and are an order of magnitude faster in terms of latency

For Intel's sake I certainly hope their chip's replacement's replacement is better I was speaking (though must have edited it out... ) in comparison with an AMD chip (AMD have double the L1 cache of the Core 2 Duo for starters). My point being, in fact, not Intel v. AMD but the fact that you don't necessarily instantly get performance improvements by going multicore in an RT environment. I don't want my sound to stop because it was too busy process-migrating to another core to handle some RT event(s).

No-one doubts a properly engineered piece of software for a current multicore processor would be better performing than what was written almost 3 years ago for a single core processor of that day. Sometime down the track when Korg's competitors have caught up and Korg need to replace the current OASYS with something better, maybe we'll get that.
Maybe they'll decide to throw in the towel and open a cheese shop instead.

[sasori]

I think what we should take from the tenor of the korg guys is that we're screwed when the day comes that we are in the position of having to revive these things. They're not going to just let people (let alone help) who spent large sums of money on something keep their investment going unless its through them and paying far too much for ancient technology. As it is, IDE drives are getting squeezed out of the market. The motherboard is no longer alive at all and the processor will be completely gone as well, soon enough.

Now, the hippy-american attitude is to keep things alive for as long as possible. Look at the VW Bug market. Its huge. You can build a Bug from scratch. You can put a turbo on it, hydrolic lifters, electronic ignition, on and on.... it really is a bug; It'll last longer on this planet than we will. And for sure, than this Keyboard will, and Korg will see fit to that.

All we want to do is to be ensured that we can keep this thing alive as long as possible because it was a significant investment that we thought was going to be on the market for more than 3 years and not abandoned.

So, if we want to supplant a mboard and processor just to keep it going; not caring about 'upgrades', we truely are on our own to try, just as this brave chap did.

Meanwhile, we all might want to start checking out the possibility of watercooling systems for the important components of the system; especially the korg-centric cards.

[elvisjohndowson]

The unique part of the OASYS is that PCI card that contains its product ID. Its been a long time since I attempted it, and I know more about Linux now than I did back then, so I think that one could potentially compile a compatible kernel for a motherboard, incorporate the real-time linux extensions, build the drivers, and for the Korg specific parts, copy over parts of their original drivers and get a new motherboard system to boot.

[synthjoe]

The unique part of the OASYS is that PCI card that contains its product ID.

Do not neglect the importance of the software/firmware here. I know it is easy to do so nowadays, when everything is supposed to work with standard interfaces, drivers, DLL's, API's and so forth.

However, Oasys doesn't appear to work that way, the O software seems to rely on only on a few standard I/O routines of Linux but the core of the software and the processing relies heavily on the exact hardware components, the way they react to a specific software instruction and maybe even the BIOS code on the MB. Still, you're able to boot a Linux, but the core of the O software is too low level (machine language, maybe?) and tuned with the hardware to work on a different one, as I understand. I think this is what Jerry and Dan are referring to.

I'm very interested in your experiment - even though I also think that there should be no need to upgrade a nice sounding synth, in principle (to illustrate how contradictory real life is: happy with my SY99/T2/Trinity without any upgrade but I was anxious to get the DSS-1 upgrade by Tom Virostek).

My approach would be to take this in much smaller steps than you do: swap the processor for a faster one first (just higher clock speed, but the same architecture), then upgrade the BIOS to the latest one, then take another MoBo with the same processor, etc. It is easier to figure out how a black box (e.g. O HW and SW together) works when changing only one of the input parameters at any one time.