I would have thought that Linux and RAIDing is something so common now, one wouldn't even need to think about it. But when I looked around for a new motherboard with an on board RAID controller and researched a little which controllers are supported best under Linux I found out, that there are only two controllers Highpoint and Promise, which one might consider. Nevertheless both of them apparently still need specific kernel versions or specific distributions and also have some other flaws
So I went with a software RAID and bought two identical Samsung 160 GB discs, whose serial numbers differ by 1. Installed them in the server and proceeded to put a partition on each of them before raiding them together with mkraid. Creating one big partition on each of the discs lead to slightly different sized partitions, so I had to manually size them to make then even. That I already found peculiar.
Then i raided them together for mirroring and came up with a RAID of about 800 MB. Surprise!
Both harddiscs had differing geometries!
bash-2.05# hdparm -g /dev/hdd /dev/hdd: geometry = 16709/255/63, sectors = 268435455, start = 0 bash-2.05# hdparm -g /dev/hdc /dev/hdc: geometry = 266305/16/63, sectors = 268435455, start = 0Apparently the geometry information was read by the raid software and the least common denominator 16709*16*63 used ...
A theory why there are different geometries in the two harddiscs is, that due to bad sectors there is an algorithm used by the harddisc vendor, that tries to compute a geometry, that is closest to the actual number of sectors available.
Now we will be mirroring with rsync.
Boring...
Doom 3 will contain satanistic sympols witch our precious youth will see! Some claims that they look more forward to doom 3 than the second coming of Jesus Christ. The madness and violence must stop NOW! Don't let ID Software ever release doom 3 or it won't be long before we'll have a youth full of devil woreshippers and another columbine highschool situation
I mean if you write a petition to the U.S. Congress, even with only three whole sentences, at least run a spell checker over it once. Everything else will be just unintentionally funny.
![]() | Try Gridrunner++. This is a Jeff Minter game and of course the speed of the game and the amount of destruction dealt are just insane. It's a bit older from 2002. You are no gamer if you haven't played a Minter game. |
Also this gives me a public feedback and discussion venue for my sporadically appearing articles.
Weblog users have first crack at it. Tell me if anything is not working.
![]() |
To be able to play this I had to upgrade my machine a little. Specifically I swapped the old motherboard for a dual channel board with 1 GB of memory. That allowed my Athlon 2400 to run at full speed instead of the crippling 1800 (Quantispeed) speed of the old board. The speed up is incredible. Much more than I expected. Urban Terror's "Rommel Map" now plays silkily smooth, well most of the time :) A good motherboard does pay off.
I also bought a nice case with appropriate cooling. My PC has now more fans than my G5 and runs quieter too. Though it looks nice for a PC, it sure doesn't look better than my Apple :) |
| One final remark : I've compared GnuStep implementation and yours. As you suspected it, Mulle's version is faster for all operations but the allocation. I tested it with a little piece of code which requires a lot of pools allocation and the difference is quite sensible. |
I also need the new article to have something to show for the grand opening of the Forum :)
C# appears to be winning, and that's a fundamentally better language. Though I in general still don't see the advantage of virtual machines on the application level for anything, except for browsers really.
operateAnnihilate uses plain [object method] calls. Fast operateAnnihilateFast is the one using function pointers. operateAnnihilateFastest is the new stuff :) The results were:
Starting operateAnnhilate... Stopped operateAnnhilate 8891ms elapsed_ Starting operateAnnihilateFast... Stopped operateAnnihilateFast 9717ms elapsed_ Starting operateAnnihilateFastest... Stopped operateAnnihilateFastest 6456ms elapsed_Oops! Plain message sending is faster now. This has me stumped.
So I went over it with otool. To my pleasant surprise I noticed that with XCode 1.5 and the newest gcc installed, the dummy methods are indeed compiled to blr and blr only. Most optimal :). The function pointer call sequence itself, though is still quite lacking as one stall could easily be avoided.
At first I thought that maybe Apple took the suggestion and used function pointers itself, somehow more optimally... They don't.
Then I figured they might have implemented some of the Tiger techniques already... They haven't.
Then I traced through both codes with the debugger. Still the function pointer technique is about six instructions shorter...
Smells like a cache problem...
I have to admit that the PMC registers in the PPC 970 are just slightly :) beyond my comprehension. They seem to differ much from the 7450, where I have the documentation. Unfortunately the documentation for the PPC 970 monitoring registers are supposed to be described in detail in Book IV of the architecture guide, of which three volumes have been published...
If anyone has some more info about the PMC registers, please leave a comment or mail me.
Also I'd like to get the mysterious "cache problem" sorted out before.
I then got the idea that, since the 970 is derived from the POWER4, that maybe the performance monitoring unit of the 970 is a copy of that chip. Either I looked in all the wrong places, or the POWER4 / RS64 III CPU is much worse documented than the 970. Although it's the much older chip.
As - this being my holidays - I have a little time on my hand, I tried the amber, simg5, scrollpv combination from CHUD to see if that got me any futher. Unfortunately the last two tools are written in Java :) And scrollpv does not seem to be working correctly any more. What I could see, I didn't find more valuable, that what I could see in Shark.
So I am none the wiser.
I think looking through the architecture books, I can figure most of the events out by myself. This sorta reminds me of my earlier endeavors, which goes to show, that I haven't gotten anywhere :)
Die Termine für diese Saison sind soweit eingetragen, wie sie schon feststehen.
I am still procrastinating on the article, because I hope some fairy will reveal the PPC 970 cache secrets to me yet.
Starting operateAnnhilateNaive... Stopped operateAnnhilateNaive 5289ms elapsed Starting operateAnnhilate... Stopped operateAnnhilate 3719ms elapsed Starting operateAnnihilateFast... Stopped operateAnnihilateFast 3494ms elapsed Starting operateAnnihilateFastest... Stopped operateAnnihilateFastest 2766ms elapsedGroan. Talk about determinism and digital computers... The problem vanished in the exact moment some kind souls from the CHUD team clued me in on how to measure instruction cache performance with Shark on the 970.
Oh oh wait, now the problem is back. Hurra.
Starting operateAnnhilateNaive... Stopped operateAnnhilateNaive 5189ms elapsed Starting operateAnnhilate... Stopped operateAnnhilate 3641ms elapsed Starting operateAnnihilateFast... Stopped operateAnnihilateFast 4198ms elapsed Starting operateAnnihilateFastest... Stopped operateAnnihilateFastest 2617ms elapsedThe result of sharking is that operateAnnihilateFast runs slower, because the data cache is not as effective in this case. With the exact same data and the exact same sequence of access no less. The instruction cache is out of the equation, first because Shark says so and second because reordering of the methods didn't make any difference. May current favorite culprit is the context switch.
offline |
online |
![]() Configuration |
If you like you can download the project. It's not polished, even has some cosmetic bugs, it doesn't have a unique icon. No homepage for it and no documentation. Realistically, I wont spend any more time on this.
It might be that you need MenuMeters installed to run this, because MenuMeters comes with a MenuCrack thingy, which could be neccessary.