Sign in with
Sign up | Sign in
Your question

Cache Disabling...How?

Last response: in CPUs
Share
November 4, 2006 8:18:22 PM

This is a two-pronged question, that i'm not sure many will know the answer to.

1. How would Intel/AMD disable cache during manufacturing?

i.e. Say they have a Core2Duo chip that (at best) should have 4096KB's L2 cache. Let's say that 256K of that is non-functional, and therefore they disable a whole 2048KB's of cache, to end up with an Allendale(which they would obviously set to a lower multiplier...7x or 8x). How would they disable the cache(i'm assuming that cache is the same as Memory=Columns x Rows)?

2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?

I've never seen any info on either of these questions, and i wonder if any of our resident process experts(possibly JJ, Joset, JkFlipFlop) or anyone else for that matter, knows the answer. :) 

More about : cache disabling

November 4, 2006 8:30:53 PM

To be honest.

1.) I dunno

2.) I... dunno.

The question I have is.. to know that info, would you try to consider in re-activating the disabled cach?
November 4, 2006 8:46:58 PM

Quote:
To be honest.

1.) I dunno

2.) I... dunno.

The question I have is.. to know that info, would you try to consider in re-activating the disabled cach?
That would be cool if you could. Even if you could get an Allendale up to 3MB cache. I highly doubt it's feasable, or people would be doing it already, and Conroe sales would really suffer.
Related resources
November 4, 2006 8:49:21 PM

O.o wouldn't that necessitate a clean room?
November 4, 2006 8:55:56 PM

Quote:
O.o wouldn't that necessitate a clean room?
Probably.That wasn't the reason for my post anyways.... Just interested in the process. :wink:
a c 82 à CPUs
November 4, 2006 8:58:34 PM

Quote:
2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?


I'd think that given that a fault can occur anywhere it could be a single gate that forms a bit, or it could be in an area that controls a a row or a column or a byte, and hence the fault could be any size.

The problem with re-enabling these is that you'd have to ensure that you knew precisley where the fault was and block it out so that it could not be used.

I wonder if the old days of unlocking multi's with a pencil might come back.
November 4, 2006 9:04:22 PM

Quote:
2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?


I'd think that given that a fault can occur anywhere it could be a single gate that forms a bit, or it could be in an area that controls a a row or a column or a byte, and hence the fault could be any size.

The problem with re-enabling these is that you'd have to ensure that you knew precisley where the fault was and block it out so that it could not be used.

I wonder if the old days of unlocking multi's with a pencil might come back.Too bad it wasn't easy like unlocking PS/VS on a GPU with software like Rivatuner. :p 
November 4, 2006 9:22:19 PM

Maybe they stuck a small pin through the die - just like my friend did with his flatmate's box of condoms 8O
November 4, 2006 9:39:01 PM

That's no good. 8O

..and i'll follow that up with a.. oh jeezuz.
November 4, 2006 10:41:07 PM

Quote:
This is a two-pronged question, that i'm not sure many will know the answer to.

1. How would Intel/AMD disable cache during manufacturing?

i.e. Say they have a Core2Duo chip that (at best) should have 4096KB's L2 cache. Let's say that 256K of that is non-functional, and therefore they disable a whole 2048KB's of cache, to end up with an Allendale(which they would obviously set to a lower multiplier...7x or 8x). How would they disable the cache(i'm assuming that cache is the same as Memory=Columns x Rows)?

2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?

I've never seen any info on either of these questions, and i wonder if any of our resident process experts(possibly JJ, Joset, JkFlipFlop) or anyone else for that matter, knows the answer. :) 



I seem to recall Jack discussing this a in thread not to long ago.

If I recall correctly, the chip has an internal "fuse". If the cache bank is defective, they overvolt that circuit and pop the fuse, permenantly locking of that cache.

I also recall they mentioned excess cache to compensate for bad cache.

Im sure JJ will be by with an accurate answer for ya soon enough
November 4, 2006 11:46:13 PM

Quote:
This is a two-pronged question, that i'm not sure many will know the answer to.

1. How would Intel/AMD disable cache during manufacturing?

i.e. Say they have a Core2Duo chip that (at best) should have 4096KB's L2 cache. Let's say that 256K of that is non-functional, and therefore they disable a whole 2048KB's of cache, to end up with an Allendale(which they would obviously set to a lower multiplier...7x or 8x). How would they disable the cache(i'm assuming that cache is the same as Memory=Columns x Rows)?

2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?

I've never seen any info on either of these questions, and i wonder if any of our resident process experts(possibly JJ, Joset, JkFlipFlop) or anyone else for that matter, knows the answer. :) 



I seem to recall Jack discussing this a in thread not to long ago.

If I recall correctly, the chip has an internal "fuse". If the cache bank is defective, they overvolt that circuit and pop the fuse, permenantly locking of that cache.

I also recall they mentioned excess cache to compensate for bad cache.

Im sure JJ will be by with an accurate answer for ya soon enoughThanks... I kind of figured that if Jack knew how it was done, he would have explained it previously. I do seem to remember him mentioning something about redundancy WRT cache.
November 5, 2006 3:18:03 AM

Hi!

Very interesting questions... it's darn late, here (5.15 am); I'll return tomorrow.


Cheers!
November 5, 2006 6:28:54 AM

That's not late, that's early.
November 5, 2006 9:54:26 AM

Quote:
Disabling cache is done routinely, but I myself am uncertain how it is done, it cannot be done easily in packaging as the complexity of cache the logic to index bad cache I would suspect is very complicated.

I will research this and get back to you...

The 'blow out the fuse' explanation is used to set various pin states in packaging to set various processor characteristics - such as VID settings and such. I doubt this is how certain sections of cache are disabled.

Jack
I look forward to your post. I figured it would be an interesting, yet little-known subject. Maybe the manufacturers classify that info as trade secrets, and therefore don't publish it? :?
November 5, 2006 4:04:08 PM

Quote:
This is a two-pronged question, that i'm not sure many will know the answer to.

1. How would Intel/AMD disable cache during manufacturing?

i.e. Say they have a Core2Duo chip that (at best) should have 4096KB's L2 cache. Let's say that 256K of that is non-functional, and therefore they disable a whole 2048KB's of cache, to end up with an Allendale(which they would obviously set to a lower multiplier...7x or 8x). How would they disable the cache(i'm assuming that cache is the same as Memory=Columns x Rows)?

2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?

I've never seen any info on either of these questions, and i wonder if any of our resident process experts(possibly JJ, Joset, JkFlipFlop) or anyone else for that matter, knows the answer. :) 


1-They take a hammer and a nail and BANG, hit the area of cache to eliminate...this was too easy.
2-(I am serious here) No wonder that defective areas are random in size but since they are groupped in packages, like MB RAM, I guess you can't disable just say 16K of it just like you can't take out a chip from a RAM slot and still have it work. Even if they could do so, the result would be an incredible spectrum of products with variable specs (cache size), that is a marketing nightmare.
November 5, 2006 6:12:24 PM

Quote:
Disabling cache is done routinely, but I myself am uncertain how it is done, it cannot be done easily in packaging as the complexity of cache the logic to index bad cache I would suspect is very complicated.

I will research this and get back to you...

The 'blow out the fuse' explanation is used to set various pin states in packaging to set various processor characteristics - such as VID settings and such. I doubt this is how certain sections of cache are disabled.

Jack


Ah, thank you for correcting the mis-information I fed Tanker
a c 102 à CPUs
November 5, 2006 9:45:23 PM

Well, #1 is actually not too hard to answer for most all lower-cache CPUs made. Intel (and AMD) simply use different mask sets for lower-cache and higher-cache units. So >95% of all Allendales are made with only 2MB L2 to begin with, as are AMD's 512KB L2 chips. This saves on die space and is more profitable for the makers as you get more chips per wafer. There also aren't nearly enough bad high-cache chips that go bad and have to be disabled. JKflipflop told me this is actually how it's done.

#2. I'd guess that cache gets crapped up in a region as a particle hits the die or something so it will be a random number.
a c 102 à CPUs
November 5, 2006 10:13:18 PM

Well I'll be...I guess JK wasn't right after all. That does seem odd for Intel to disable the cache on those chips as the fail rate in the industry is about 5%. I know for a fact that AMD uses separate masks for the 512KB and 1MB L2 chips (it kind of has to.) So I guess Intel must have a problem getting all 4MB cache online (not likely,) they really busted their butts to get Conroe shot and out and thus only made 1 mask (more likely) or they only had one line open to make one die type of CPU and of course it was the full 4MB one (sort of likely, but less so that #2 because of the following.)

What this does say is that Intel has a ton of 65nm production capacity as it's willing to toss 4MB cache versions off as 2MB ones. I bet the guys in Sunnyvale are wishing that they had that luxury...
November 6, 2006 12:20:04 AM

Quote:
1. How would Intel/AMD disable cache during manufacturing?

i.e. Say they have a Core2Duo chip that (at best) should have 4096KB's L2 cache. Let's say that 256K of that is non-functional, and therefore they disable a whole 2048KB's of cache, to end up with an Allendale(which they would obviously set to a lower multiplier...7x or 8x). How would they disable the cache(i'm assuming that cache is the same as Memory=Columns x Rows)?

2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?


Here's a simple & quick answer to both your questions (Intel's "I5" procedures for the Pentium Pro cache redundancy testing, 1993-1997); although this doesn't address, in depth, the DFT (Design For Testing) methods during process, nor the more sophisticated techniques (both Soft & Hard) available today, it provides a basic understanding of redundancy/yield and the Known Good Die factor (KGD), among others.
I don't have the time now, but I'll post some more info on wafer/die testing process, asap.

http://developer.intel.com/technology/itj/q41997/pdf/manufacturing.pdf

(Again, very interesting points; I've just missed those issues, while going through litho/manufacturing...)


Cheers!
November 6, 2006 12:23:51 AM

Quote:
Maybe the manufacturers classify that info as trade secrets, and therefore don't publish it? :?


Not at all; there's plenty of info around (and very interesting stuff, indeed!) :wink:


Cheers!
November 6, 2006 4:25:10 AM

Quote:
1. How would Intel/AMD disable cache during manufacturing?

i.e. Say they have a Core2Duo chip that (at best) should have 4096KB's L2 cache. Let's say that 256K of that is non-functional, and therefore they disable a whole 2048KB's of cache, to end up with an Allendale(which they would obviously set to a lower multiplier...7x or 8x). How would they disable the cache(i'm assuming that cache is the same as Memory=Columns x Rows)?

2. This may be even harder to answer.

Say there is defective cache on the chip, would the defective "amounts" be random sizes.. i.e. 278KB, or would the defective areas be in amounts of say 64KB/128KB/256KB/512KB?


Here's a simple & quick answer to both your questions (Intel's "I5" procedures for the Pentium Pro cache redundancy testing, 1993-1997); although this doesn't address, in depth, the DFT (Design For Testing) methods during process, nor the more sophisticated techniques (both Soft & Hard) available today, it provides a basic understanding of redundancy/yield and the Known Good Die factor (KGD), among others.
I don't have the time now, but I'll post some more info on wafer/die testing process, asap.

http://developer.intel.com/technology/itj/q41997/pdf/manufacturing.pdf

(Again, very interesting points; I've just missed those issues, while going through litho/manufacturing...)


Cheers!Thanks Joset. Interesting, although i figured it would be pretty technical(my brain hurts now)..I'm positive i have ADD...especially when i was in high-school. What i get out of that article, is how they test for bad cache, and how they replace it with a redundant cell. It doesn't specifically(that i can see) tell how they would disable cache... i.e. with a C2D chip, and lets say there's ~256KB defective....they would then disable 2048KB leaving 2048 KB working cache for an Allendale. It doesn't really say how they disabled it...unless the flash cell disables it by sending high voltage into it?

For example, as per article:

Quote:
a sub-array is replaced by it's neighbouring sub-array, closest to the redundant sub-array. The sub-arrays between the bad sub-array and the redundant sub-array are also switched to their neighbouring sub-array. All this switching is done by muxes in the read and write paths of the device.


That's the closest explanation that i can see regarding disabling(some good/some bad) cache. :?
November 6, 2006 4:55:11 AM

Quote:
Well I'll be...I guess JK wasn't right after all. That does seem odd for Intel to disable the cache on those chips as the fail rate in the industry is about 5%. I know for a fact that AMD uses separate masks for the 512KB and 1MB L2 chips (it kind of has to.) So I guess Intel must have a problem getting all 4MB cache online (not likely,) they really busted their butts to get Conroe shot and out and thus only made 1 mask (more likely) or they only had one line open to make one die type of CPU and of course it was the full 4MB one (sort of likely, but less so that #2 because of the following.)

What this does say is that Intel has a ton of 65nm production capacity as it's willing to toss 4MB cache versions off as 2MB ones. I bet the guys in Sunnyvale are wishing that they had that luxury...

Both AMD and Intel had to do that, even if the cache was perfect e.g. Toledo when they stopped producing Manchester.
It's purely for market reason, but sometime the -ve outweighs +ve and that's the reason why Intel are coming out with 'native' Allendale(or whatever it's going to be called).

It's very easy to see this reason once you've experienced the Morgan/Throton/... eraI'd always heard that Celeron's were just P4's/PIII's with the cache chopped. :) 
November 6, 2006 7:22:42 AM

Quote:
Side note, here is a nifty little explanation of cache in general, worth a read....

http://www.slcentral.com/articles/00/10/cache/index.php

Side side note -- I recall an interesting discussion where people often misconstrued electrons and signals in the platform as traveling at the speed of light, they do not and this site had a this to say, which ultimately leads to latency :) 

Despite the common misconception that electricity flows at the speed of light, it does not. It certainly travels at speeds far greater than the speed of sound, but electrons flow at a finite speed that is much lower than that of light, and this fact has an impact upon the design and performance of processors. Why mention this? One must remember that computers only deal with information in low and high voltages of electricity. The speed of any given part of a computer is, at the very least, bound by the speed at which electricity can be transmitted across whatever medium it is on. This, in turn, shows us that the ultimate performance bottleneck is necessarily the speed at which electricity can move. This is also the case for cache.
Thanks Jack. Actually, this article sheds a little light on what they do.

Quote:
Intel has taken a different approach with the P3 Coppermine. If one half of the cache is bad, but the other is fine, Intel just uses a laser to fuse the second half of the cache, and disable it. This saves the good part, and allows Intel to sell it as a Celeron. While they do this, they often just disable half of it anyway to get a Celeron to sell. This is actually cheaper than designing a chip with half the L2 cache, because Intel does not have to create different masks and such for another chip.


Further reading in this article brings up another interesting point(assuming things haven't changed that much in the 6 years since this was written).

Quote:
One would think that AMD would do with their Duron and Athlon the same as Intel does with their Celeron and P3 Coppermine. However, they did not. When disabling a section of the cache, it also cuts the associativity proportionally with the fraction that was disabled. Thus the Celeron is only 4-way associative while from the same core. This reduces hit rate, and that's not something that AMD was willing to do. Also, simply disabling a part of a cache merely to have a product another market isn't an efficient use of fabrication capacity.


So, from what they're saying here, disabling cache actually incurs a slight performance penalty. This makes me wonder if, when Intel starts producing legitimate 2MB L2 Allendale's, will the non-disabling of cache create any performance differential(presumably better)? If that's the case, the Allendale's will be an even more attractive CPU, having more efficient cache, less transistors, probably some process updates(new stepping) and maybe even slightly lower pricing? I'm sure Intel will take in the savings brought about from less L2, rather than pass it along to the customer, though. :) 
November 6, 2006 8:11:23 AM

Quote:
Yeah, I ran across the article with some simple google searching, it did a good/decent job describing how cache works but I am not certain of the laser method, seems labor and cost intensive.

Though I would not necessarily put it out of the window until I have had more time to read up on current literature.

Jack
I could have a Googled it too, as well, but i figured...hey this is a CPU forum, and it could manifest some interesting posts. I felt it worthwhile to create a thread.It's not because i was lazy. :wink: :) 
November 6, 2006 8:10:29 PM

Quote:
Yeah, I ran across the article with some simple google searching, it did a good/decent job describing how cache works but I am not certain of the laser method, seems labor and cost intensive.

Though I would not necessarily put it out of the window until I have had more time to read up on current literature.

Jack
I could have a Googled it too, as well, but i figured...hey this is a CPU forum, and it could manifest some interesting posts. I felt it worthwhile to create a thread.It's not because i was lazy. :wink: :) 

No, it was a good topic.... while I know it is possible, and it is common practice, I cannot honestly say exactly how they do it. My curiousity is now on this and when I find out I can post it back unless someone beats me to the punch :)  ...

JackThanks. I have to wonder now, whether a "native" 2MB cache Allendale will show any difference with the L2 being increased to 16-way associativity. Somehow, i doubt it will make very little difference, seeing how a Conroe clocked at Allendale speeds isn't showing huge increases(and i would think doubling of cache would make a much bigger difference than double the associativity). Sorry for steering the thread of course a little. :?
November 6, 2006 8:54:44 PM

Im guessing disabling the cache is not a bios tweek?
November 7, 2006 9:12:34 PM

Quote:
Here is another paper that discusses cache faults and how they are handled, if you read AMD's bios programming guide you can also see where the cache size is set by special Machine Specific Registers (MSRs), likely redundant cache is implemented, say one targets a 2 meg cache design, you physically build 2.5 Meg, then at startup faulty blocks can be marked as bad and not used.

AMD's Bios Guide: http://www.amd.com/us-en/assets/content_type/white_pape...

ftp://ftp.cs.wisc.edu/markhill/Papers/toc93_faults_orig...

A manufacturing defect causes a fault in a cache if it impairs the correct operation of the cache. We will study those faults that make a bit in the cache unable to retain the value written to it, but that do not otherwise perturb the operation of the cache (e.g., do not cause an electrical short circuit). A fault causes an error if it causes the system to enter a logical state other than the one intended. We can prevent faults in an on-chip cache from causing errors by (1) discarding chips with such aults, (2) using redundant memory, or (3) disabling cache blocks that contain faults. The advantage of discarding chips, method (1), is that it works for any defect. Its disadvantage, however, is that by reducing yield it increases chip cost.


Those who may be older and remember that hard drives initially had to have a low-level format, usually a routine programmed in bios accomplished the task, in which before partitioning and high level formats, one would low level format the HD where bad sectors would be found and marked in the allocation table for the HD. As HD quality go better the low level formatting has become a non-issue and is likely done at the factory, nonetheless, I am postulated with limited information that cache initializes and functions similarly.

In that, upon startup up the BIOS bootstrap code initializes the cache memory and tests the caches up to the point of the actual size needed or specified by the MSRs. In this, as the processor initializes, if a block is found bad or faulty it is simply marked as bad or faulty and never used. The cache continues it's memory check through all the physically available SRAM until the specified amount of good cache is found (specified by the configuration set by the MSR registers).

So say Intel has a 4 meg part, but setups up the MSRs to identify it as a 2 meg part. The bios intialization then tests and validates good cache up to 2 megs, then quits after 2 good megs of cache are allocated. This would make the most sense. Of the 2 mega bits data that can be bad there is no way to physically pin out hard logic in the package to account for every word line and bit line.

I am still reading and learning so I can confidently bring back to the forum the methods employed to accomplish such a task. This is a detail that I do not have a great deal of knowledge on.

Jack

The way I see it this is, perhaps, one of the most important issues on chip manufacturing, next to process & litho; it influences all aspects of manufacturing, from sand-to-chip/yield, literally.
I'm still reading through & searching (good AMD paper, btw), in order to get a glimpse of a sequencial order for logic/cache error detection/correction techniques, both at the soft & hardware levels; so far, I've only found out that, from wafer quality grade through defect detection precision tools, to Design For Testing (DFT) procedures & [on-chip] Logic/Memory Built-In Self Test (BIST http://www.mentor.com/products/dft/memorytest/index.cfm), all contributes to initial, mid-process & final binning decisions, on what concerns the means by which wafer batches are selected to provide the best end results, i.e., higher yields.
For instance, even the kind/type of defects are taken into account, at the process level & graded in accordance with its "severity", some being considered "normal" (sort of inoffensive). I've also found out that, cache redundancy & ECC are just some ways of dealing with defective patterning and that Machine Specific Registers (MSR) can "store" defective cache bit pointers within the core logic (not in the cache, itself); also interesting, is the use of small portions of flash memory (see my previous post above), for a reason (of course!): MSRs behave as ROM as long as only warm resets are performed; once a cold reset to the processor is made, MSRs are erased and so are the defective cache bit pointers (perhaps this is not the most adequate wording; anyway...); as known, flash memory retains its content, even when in off state; a 'perfect' ROM for storing/maintaining the relevant info on the defective cache coordinates (I wonder how this might work with shared cache, since both logic cores can address the whole cache blocks... maybe defective management has just evolved enough... but not that much, in order to link both L1 caches... I'm just guessing).

I'll try to collect, understand & post in some order, all the relevant data I can find on the subject, as it seems so darn interesting from every angle I look at it.

@1Tanker: I know you've addressed this issue before; I just missed it. Well, seems that you've got me hooked, this time around! :wink:

(Just a few illustrative links):

http://www.freescale.com/files/technology_publications/doc/Papers/Eintell5170ARTICLE.pdf - On typical litho defectivity

http://www.nikonprecision.com/immersion/media/Immersion_Defectivity_D6996.pdf - on Nikon's Immersion Litho

http://www.sematech.org/meetings/archives/other/20001030/08_Test_Screen_Shirley.pdf - elementals of defect management

http://userpages.umbc.edu/~abhishek/link_docs/defect_based_test.pdf - Intel Automatic Test Pattern Generation (ATPG)


Cheers
November 8, 2006 12:17:30 PM

Quote:
...or not as I already do have a fair amount of clue how Intel does it and it's pretty extreme.


Could you elaborate on that, please? I know it's pretty extreme but's also darn decisive, at all process levels. After all, it's not what goes right that defines success (in general) but, rather, what goes wrong.
Thanks.


Cheers!
November 8, 2006 12:29:26 PM

Quote:
O.o wouldn't that necessitate a clean room?


It's done through all the chip manufacturing stages (Hard & Soft errors' checking, testing, debugging, etc); very high quality Si wafers are a prime requirement, in order to reduce cummulative defects, throughout the process; so, yes, you're right: A high-level (JKflipflop?!) clean room is a must.


Cheers!
November 8, 2006 12:34:46 PM

I'm trying to figure out how to make a clean room in my basement... :wink:
Thanks.
November 8, 2006 12:41:55 PM

Cover your walls in your basement with maggots... They clean wounds very well, maybe they will clean room very well too.....
November 8, 2006 4:17:57 PM

Quote:
Cover your walls in your basement with maggots... They clean wounds very well, maybe they will clean room very well too.....


:lol: 

Ok. Away with the vacuum cleaners...


Cheers!
November 8, 2006 9:06:34 PM

:lol:  :lol:  :lol: 
Talking about clear rooms, I'd like to share the secret of keeping mine clean:
about 6 days/week the whole surface of it is THE trash bin; I can throw everything on the floor. When I see the stuff I am walking on is getting too much, I wipe it off :wink:
November 8, 2006 9:10:13 PM

Quote:
:lol:  :lol:  :lol: 
Talking about clear rooms, I'd like to share the secret of keeping mine clean:
about 6 days/week the whole surface of it is THE trash bin; I can throw everything on the floor. When I see the stuff I am walking on is getting too much, I wipe it off :wink:


How do you equate layers of dust, trash, and mold and god knows what else, with a "clear room".

Are you saying you live outside and your room is not really clear so much as its invisable?
November 8, 2006 9:35:00 PM

Quote:
Cover your walls in your basement with maggots... They clean wounds very well, maybe they will clean room very well too.....


:lol: 

Ok. Away with the vacuum cleaners...


Cheers!
No, no, you'll need them for the maggots!
November 8, 2006 9:40:03 PM

Quote:
:lol:  :lol:  :lol: 
Talking about clear rooms, I'd like to share the secret of keeping mine clean:
about 6 days/week the whole surface of it is THE trash bin; I can throw everything on the floor. When I see the stuff I am walking on is getting too much, I wipe it off :wink:


:lol: 

That's why Intel developed Copy Exactly!

As for AMD, they decided to do it twice a day (APM).


Cheers!
November 8, 2006 9:44:52 PM

Quote:
Cover your walls in your basement with maggots... They clean wounds very well, maybe they will clean room very well too.....


:lol: 

Ok. Away with the vacuum cleaners...


Cheers!
No, no, you'll need them for the maggots!

:lol: 

Ok then: Bring back the vacuum cleaners, on the double!


Cheers!
November 8, 2006 9:45:27 PM

Did you know the first clean room was created in Germany and the rooms were filled with non-oxygen gasses. Most the workers died...




They were first developed in 1941 i think.
November 8, 2006 10:53:27 PM

Quote:
Did you know the first clean room was created in Germany and the rooms were filled with non-oxygen gasses. Most the workers died...




They were first developed in 1941 i think.


:lol: 

Einrich Himmler & Adolf Eichman (I do not know if the spelling is correct, though; and, it doesn't really matter...), sooner than that, I believe.
Speaking about clean rooms, huh?! :wink:


Cheers!
November 9, 2006 8:39:44 AM

Quote:
:lol:  :lol:  :lol: 
Talking about clear rooms, I'd like to share the secret of keeping mine clean:
about 6 days/week the whole surface of it is THE trash bin; I can throw everything on the floor. When I see the stuff I am walking on is getting too much, I wipe it off :wink:


How do you equate layers of dust, trash, and mold and god knows what else, with a "clear room".

Are you saying you live outside and your room is not really clear so much as its invisable?
I live inside it, only that most of the garbage is paper and pencil waste so it looks like you're walking in an autumn park :lol: 
November 29, 2006 8:25:06 AM

They make the chips with more cache than they need, so if, or when, some of it fails (small amounts due to minor faults nm in scale) it can just be disabled automatically by the chip, if not laser cut to disable.

It would work very much like RAID-5, but 'expect' a failure and just electronically use the 256/260 ths of the cache that worked.

This is one reason why transistor counts sometimes go down after a refresh and production matures. (eg: 7800 GTX to 7900 GTX). It is not the 'sole' reason though, obviosuly.

Much like the IBM Cell processor, they disable entire SPEs.
IBM do not mass manufacture CPUs with low yields, that is a total BS rumour and Sony is ridding it like a pony.

November 29, 2006 8:36:39 AM

Quote:
. I have to wonder now, whether a "native" 2MB cache Allendale will show any difference with the L2 being increased to 16-way associativity. Somehow, i doubt it will make very little difference, seeing how a Conroe clocked at Allendale speeds isn't showing huge increases(and i would think doubling of cache would make a much bigger difference than double the associativity). Sorry for steering the thread of course a little. :?


Doubling set-associativity can, and often does, make more difference than just doubling the size of the cache (and not doubling set-associativity to keep it relative).

Look at the differences in L1 caches in both size and set-associativity over the last 6 years.

It explains 'much', that most forum readers simply ignore.
November 29, 2006 8:42:17 AM

Quote:
Im guessing disabling the cache is not a bios tweek?


Traditionally you could disable the entire L1, L3 (and maybe L3 ?) caches via the BIOS.

eg: For purposes of hard RAM pattern testing back in the good old days. (Wasn't that long ago either).

In some mainboard BIOS's you still can if you use [Ctrl+F1] and [Ctrl+F6] to access extra options under various menus.

eg: Disable L1 (+L2) cache and you can reach 6+ GHz on various processors quite easily in CPU-Z / CPU-ID apps, but it'll take 15+ minutes to get to Windows XP desktop from power on. :roll:

It was not an option to perform 'partial' disables on the L1/L2 cache though (well not without a very custom BIOS, and I doubt anyone has ever bothered).
!