Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
ZDNet Clock Not Opening...
- Thread starter pdechavez
- Start date
- Sort by reaction score
It should boot in 32 bit automatically unless you changed something in terminal. Go into about this Mac, and look to see if your in 32 or 64 bit mode.
It's not a SL issue, it's a 64 bit issue. It wouldn't open on my 3.1 in SL in 64 bit mode and would under 32 bit.
Let me repeat myself. It works on SL on my 2008 3.1 under SL when I boot in 32 bit mode. It does NOT work when I boot in 64 bit mode.
Having trouble understanding your sentence
I am running 10.6.6 on my macpro1,1. I can open ZDNet Clock and set my clock by increasing my FSB from 667MHz to 764MHz resulting in my clock going from 2.33GHz to 2.66GHz. So obviously I can set my clock. I can run comparison handbrake runs and show that speed has increased. Since the system clock increases alongside FSB you can not "prove" the overclock by relying on a benchmark like Geekbench since it references the system clock to establish the bench.
If I restart then I would need to set my clock again but that is what I expect. So from my personal experience it works in Snow Leopard 10.6.6.
What am I misunderstanding?
Ok this is strange, Cindori is indeed right, I ran ZDnet's tool again and scored 11263 despite the tool saying it successfully upped the clock.
What I don't understand is how I managed to get my previous score (exactly 10% faster with a 10% overclock) when I don't have a 10.5 build on this MP and ran the test in 10.6.6 then too? http://browse.geekbench.ca/geekbench2/view/349922
What I don't understand is how I managed to get my previous score (exactly 10% faster with a 10% overclock) when I don't have a 10.5 build on this MP and ran the test in 10.6.6 then too? http://browse.geekbench.ca/geekbench2/view/349922
Last edited:
Maybe you ran one test in 32 bit and the other one in 64 bit. Going from 32 to 64 gives a 1000 - 1500 points boost in GB
The geekbench score shows it is a 64 bit GB. And we are clear zdnet does not work under 64 bit so there you go
Last edited:
Getting the same score in 32bit kernel and 64bit kernel.
The 32 bit and 64 bit versions of Geekbench are different though both run under 64bit kernel: http://browse.geekbench.ca/geekbench2/view/370489 http://browse.geekbench.ca/geekbench2/view/370490 and neither are as fast as the original ZDnet one in 64 bit.
Running both 32 bit and 64 bit versions of Geekbench in the 32 bit kernel: http://browse.geekbench.ca/geekbench2/view/370495 http://browse.geekbench.ca/geekbench2/view/370497 Spot the difference? Me neither.
So, what made this run faster if ZDnet doesn't work in SL? http://browse.geekbench.ca/geekbench2/view/349922
The 32 bit and 64 bit versions of Geekbench are different though both run under 64bit kernel: http://browse.geekbench.ca/geekbench2/view/370489 http://browse.geekbench.ca/geekbench2/view/370490 and neither are as fast as the original ZDnet one in 64 bit.
Running both 32 bit and 64 bit versions of Geekbench in the 32 bit kernel: http://browse.geekbench.ca/geekbench2/view/370495 http://browse.geekbench.ca/geekbench2/view/370497 Spot the difference? Me neither.
So, what made this run faster if ZDnet doesn't work in SL? http://browse.geekbench.ca/geekbench2/view/349922
Last edited:
I stated it in my post a few lines above. Geekbench CAN NOT be used to check your overclock. ZDNet Clock increases the Front Side Bus (FSB) and since Apple chose to base their system clock on the FSB you get a fast running clock. Geekbench uses the system clock as a stop watch to measure the amount of time to finish a bench but since the clock is running fast by EXACTLY the same amount as the overclock you will get the SAME result.
If you want to verify that you are indeed running faster then you need to use something that is independent of the system time clock. For example, use handbrake to encode a movie. Time it using your trusty wrist watch. Now overclock and encode the same movie. You will see that it completes the task faster based on your trusty wrist watch.
I think we are having one of those "Yes we have no bananas" kind of dialogues here
The ZDNet clocking trick IS locked in SL.
I know this because I tried making a CPU clocking utility for new Macs, based on this trick.
You can verify that the clock succeeds (or fails) by looking in System Messages
(Programs / Utilities) when you set the clock.
The messages will relate to "sysctl".
I am not always right, even though I like to think that I am.
There, I said it
Wow, interesting! This proves Geekbench really is a crap benchmark utility. :/
I know this because I tried making a CPU clocking utility for new Macs, based on this trick.
You can verify that the clock succeeds (or fails) by looking in System Messages
(Programs / Utilities) when you set the clock.
The messages will relate to "sysctl".
I am not always right, even though I like to think that I am.
There, I said it
Wow, interesting! This proves Geekbench really is a crap benchmark utility. :/
So I guess that the accuracy of this statement hinges on the definition of "new" Macs. Since ZDNet clock clearly does work on my Mac Pro 1,1 2006 model under 10.6.6 the limitation may be that it is locked in SL for "new" Mac Pro's. There are quite a few of us using ZDNet Clock on our macpro1,1 under another Mac forum that I subscribe to.
ZDNet modifies cpu values in sysctl, a part of the kernel in OSX.
Sysctl cpu values are locked in Snow Leopard kernel. Fact.
Maybe ZDnet will open. Maybe it will run fine. Maybe it will let you set the clock.
But the clock will not apply.
When ZDNet tool runs, it clearly states it is only for 10.5.
Sysctl cpu values are locked in Snow Leopard kernel. Fact.
Maybe ZDnet will open. Maybe it will run fine. Maybe it will let you set the clock.
But the clock will not apply.
When ZDNet tool runs, it clearly states it is only for 10.5.
No offense to you or your fan club but this is one of those rare instances when you are, in fact, wrong. You are welcome to dogmatically stick to your theory but you seem like the kind of person who would be interested in the facts. Get access to a macpro1,1 with snow leopard installed and try it. Keeping in mind that the system clock will run fast by the same percentage that you over clock the FSB you can verify the over clock by timing a process. I recommend timing a handbrake encode. Say 5 minutes of video encoding. You will discover that the encoding time drops by the same percentage that you over clocked the FSB.
So despite the theory, here are the actual effects that I see when I over clock my 2006 macpro1,1 with 2 quad core e5345 processors. None of these could be explained if the FSB was not, in fact, increasing.
1) As mentioned, handbrake runs decrease by approximately the same percentage as the over clock I apply. This is real, not imaginary.
2) when you apply the clock you get a string of ecc errors as the memory realigns itself to the new clock. These settle down within a few mS.
3) If I increase FSB a little too high I start to see memory ecc corrections in
the console. If I back off the errors stop.
4) If I increase FSB too far it will crash the machine.
5) Memory and CPU temperatures increase. Fan speeds also bump up shortly after applying the clock in reaction to the higher temps.
So these are real effects that are only explained by the clock actually increasing. I know you have a theory as to why this will not work but I will leave it up to you to come up with the theory that explains why this does work on macpro1,1 machines running snow leopard.
ah, I did indeed make a mistake. sysctl is part of the firmware. the sysctl.conf is part of the OS. since ZDnet OC's temporarily (for safety purposes) it does not touch the config file (hence why the clock will stick into 64-bit SL if you boot Leopard first and set it) and therefore also should work in SL.
but the sysclt values are locked on the newer firmware too (as the conf is in the OS). this is the same case with iPhones.
but the sysclt values are locked on the newer firmware too (as the conf is in the OS). this is the same case with iPhones.