| 1 |
On Monday 17 January 2011 16:59:26 Jason Weisberger wrote: |
| 2 |
> The word "probably" implies that you have no idea what the statistics were |
| 3 |
> on getting a perfectly good core were or why they disabled entire batches of |
| 4 |
> cores based on an error from one. |
| 5 |
> |
| 6 |
> You are just overdriving your point. If he doesn't want to enable updation |
| 7 |
> of microcode, it won't hurt anything. If it was functioning fine before, it |
| 8 |
> will also be fine without an update. There is nothing wrong with keeping |
| 9 |
> the version of code that is stable for you. It isn't stupid, its a good |
| 10 |
> rule of thumb. If it isn't broken, don't fix it. |
| 11 |
|
| 12 |
the problem is: how do you know it is stable? Just might be lucky that fixed |
| 13 |
function was not hit by you so far. But will that be true tomorrow? Next week? |
| 14 |
With the next gcc version? |
| 15 |
|
| 16 |
Microcode updates are there for a reason. There are ZILCH reasons to turn it |
| 17 |
off in the bios. 'Oh, there are a lots of fine 4cores marketed as 3cores. I want |
| 18 |
that' is not a reason not to turn it on. It is a reason to buy a mobo who can |
| 19 |
unlock those cores without turning off microcode updates. |
| 20 |
|
| 21 |
Call me old fashioned, but I prefer computers as deterministic machines - and |
| 22 |
not very expensive random number generators (which is also the main reason why |
| 23 |
I don't overclock. 5% faster for 1% better chance of errors? 5% I will never |
| 24 |
ever able to 'feel'? No thank you). |
Archives