Issues arising from todays Drobe article Faster, better, sounds like a plan.

Firstly, thank you to the user who pointed out today’s Drobe posting and thank you also to Drobe for their efforts in bringing the NewsDesk to the market’s attention.

So in this spirit of co-operation, we would point out that the Drobe article has raised a number of issues which we hope to clarify here. It is important that anyone reading this article should not take away the idea that we are anti-Drobe or anti Chris Williams, we accept that the article was written in good faith, as is our reply.

Faster, better, sounds like a plan.
Yes it does and yes there is a plan it’s called Spectrum and despite delays the plan remains unchanged, the only difference regarding the Omega is that we have now published this small area of the plan to give the market some real information.

Bandwidth, bandwidth, bandwidth.
Bandwidth is only one aspect of many that affect system performance. Increasing the bandwidth available will only increase performance up to a certain level, beyond which the rest is wasted. A good example of this can be found with IOP321 based systems, of which the Iyonix is one readers will be familiar with. This chip was designed originally to provide very high performance intelligent RAID SCSI disc systems, and as such has a very high bandwidth connection between memory and the PCI-X bus. The bandwidth available from the memory controller is 1.6GB/sec, which is vastly more than the XScale core needs on its own. Given a cpu with 3x clock rate and maybe 40x memory bandwidth, surely the Iyonix would be consistently at least 3x faster than a 202MHz SA RPC in all the benchmarks? Not so! In fact the truth behind achieving high level of performance is far more complex than is appropriate to get into here. Except to say that such considerations are part of the various tradeoffs examined during the engineering of any computer product. Look what happened when you put your 200MHz (or whatever) SA into a RPC designed for a 40MHz ARM6. The bandwidth available apparently hamstrings the SA, but the speed increase seen is enormous.

The rest
With regards to USB and balls in Simtec court this is complete nonsence, as they are yet to recieve our drivers - hence we cannot say when they could start work or when they would be able to finish, conceiveably they could even turn round and say they were no longer interested in doing such a port.

The spin.
We have no wish to nit pick, but we feel that it’s only reasonable to point out that one person’s spin is another person’s information and without wishing to state the obvious, information is the bread on which Drobe feeds.

NewsDesk is an attempt to respond to the market’s request for real, accurate information and informed opinion. Obviously such information will be biased towards MicroDigital, after all we are only human, however it will be accurate (no lead times will be quoted).

Drobe also raises the point that “we (MicroDigital) cannot let go of the fact that our competitor uses an integrated XScale processor”, of course not, that’s the whole point. We cannot let go of this fact because it’s one of our unique selling features, that together with our soft/hardware design gives our product a clear distinction from our competition. Besides which, we were actually comparing the IOP321 with IOP331. The PXA range Drobe referred to are clearly not appropriate to our desktop market.

With regards to the comment where they state “Perhaps MicroDigital were referring to the fact that mass produced chips have bugs (shock!)”. Clearly that was not what we were saying. The point we were making is that our ability to add a 2nd processor on a plug-in daughterboard, coupled with our soft/hardware design, means that any such problems can be resolved without the need for an expensive redesign of the motherboard.

We spotted that Drobe are also capable of a low blow when in the same paragraph they allege that MicroDigital inflicted a low blow. It was difficult to follow Chris’ thought process around his comments about the XScale processors, as he switched from the manufacturer to talking about faults or bugs that may slip into our design. This is difficult to follow as we don’t design processors.

Regarding Steffen’s test results we should point out that we have not said that they were in anyway a scientifically accurate comparison between the machines, nor do we accept that his results are necessarily representative of the real world. Whether any particular benchmark is relevant or useful depends entirely on what you want to do with your computer. That said, we again thank Steffen as his results were helpful to us.

For those who have not read yesterday’s article, what we pointed out was that his results were useful to us in identifying where the ARM design, in a desktop context, relating to performance with applications using large sets of data, could be dramatically improved. We were basically highlighting the fact that we are prepared to react to constructive criticism and that our design allows us to implement such changes to users’ machines in their own premises.

Regarding future benchmarks, it would be helpful to readers if the Lightning and Northbridge update issue version numbers were quoted. As without them the results are meaningless, this is because different issues have completely different characteristics which will dramatically alter test results.

With regards to the RISC OSmark results, unless we have misread the results and far from being slam dunked, the Omega was not mentioned. However having now looked at the results quoted on Richard Spencer’s web site, they do make interesting reading.

Take for example the first result processor performance - we take this to mean that the Iyonix processor performance at 2.61xbase or 527.22MHz, this against the published 600MHz. The base machine being a 202MHz RPC. We make that a 12.13% power loss, surely one would have expected the result to be 2.9x, that said the Iyonix won that one it was 2.17x faster than a SA243.

Memory: Virtual RPC won, it was 9x faster than the Iyonix.

Rectangle copy: Iyonix won, it was 5.74x faster than the Virtual RPC.

Icon plotting: Virtual RPC won, it was 5.09x faster than the Iyonix.
SA243 came second it was 2.22x faster than the Iyonix.

Draw path: Iyonix won, it was 1.03x faster than Virtual RPC
SA243 came third the Iyonix was 1.05x faster.

Draw fill: Virtual RPC won, it was 1.85x faster than the Iyonix.
SA243 came third VRPC was 2.32 faster.

HD Read in MB/s: Virtual RPC won, it was 11.26x faster than the Iyonix which came third.

HD Write in MB/s: Virtual RPC won, it was 10.72x faster than the Iyonix which came third.

FS Read KB/s: Iyonix won, it was 1.27x faster than VRPC.

FS Write KB/s:Iyonix won it was 1.46x faster than VRPC.

Reading these results it very hard to judge exactly what ‘slam dunked’ means, we thought it referred to basket ball where the attacker jumps above the defenders and the basket rim contemptuously throwing the ball into the basket to score taking the team further into the lead.

Four out of nine doesn’t sound like a slam dunk to us and had the Omega been included, to be fair our issue 14 software would have won three of the above categories, but VRPC would still come out on top overall.

Finally, thank you Chris for marking our paper and being good enough to ignore the odd typo and grammar error. Hold on, grammar error, is that correct? shouldn’t that be grammatical error! I know it’s (becoz nobodies’ perfekt).

Top of page

Home ·  Products ·  Consultancy ·  Contact us ·  NewsDesk ·  Education ·  Partners ·  Sales ·  Owners Club

Microdigital Website© MicroDigital Limited, 2002
Any comments please contact the Webmaster