Fair enough. As someone else pointed out, the higher energy cosmic rays are the problem, and they result in alpha particles and high speed neutrons and other fun things when they hit atoms in the substrate. So I took a short cut in my explanation. Mea culpa.
Basic point still stands: With large memory arrays of small bits, bit-flip events become more common. The chips we make at work go into cell towers, and are packed in metal cages in concrete buildings, and yet they see higher soft-error rates at higher altitudes. That's why our customers require us to have ECC on our parts.
First, it was not cosmic rays; memory was tested in a lead vault and showed the same error rate. Turns out to have been alpha particles emitted by the epoxy / ceramic that the memory chips were encapsulated in.
That was true in 1977 when bits were huge. It's not so true in 2009, when they are a few orders of magnitude smaller.
As for ECC in memory... The problem is that ECC carries a heavy performance hit on write. If you only want to write 1 byte, you still have to read in the whole QWord, change the byte, and write it back to get the ECC to recalculate correctly. It is because of that performance hit that ECC was deprecated. The problem goes away to a large extent if your cache is write-back rather than write-through; though there will be still a significant number of cases where you have to write a set of bytes that has not yet been read into cache and does not comprise a whole ECC word.
PC caches have been write-back for a long time (all the way back to the original Pentium!). And, they write-allocate, meaning that a byte write from the CPU could bring the whole line into the cache to merge with the write. (I believe this was optional in the Pentium era, but commonplace not long after.)
Actually, it's not uncommon for large RAM arrays to have "row repair" and "column repair". The RAM array has more rows and columns than are required to provide the rated capacity. During manufacturing testing, they remap some of these to work around defects and increase yield. So, if you're still seeing faults after the production tests have mapped away the obvious faults, I think you're signing yourself up for a bit of pain.
Seems like a colossal waste of time to me. If you're not concerned about performance, then it's a question of how much your time's worth. You can get 2GB for $23 and probably less if you spent more than 5 seconds looking like I did. If you spend more than a couple hours futzing with your flaky system to remap all your bad RAM, even if your time is only worth minimum wage, you quickly cross the "worth it" threshold.
Note: having more memory increases your error rate assuming a constant rate of error (per megabyte) in the memory. However, if the error rate drops as technology advances, adding more memory does not necessarily result in a higher system error rate. And based on what I've seen, this most definitely seems to be the case.
Actually, error rates per bit are increasing, because bits are getting smaller and fewer electrons are holding the value for your bit. An alpha particle whizzing through your RAM will take out several bits if it hits the memory array at the right angle. Previously, the bits were so large that there was a good chance the bit wouldn't flip. Now they're small enough that multiple bits might flip.
This is why I run my systems with ECC memory and background scrubbing enabled. Scrubbing is where the system actively picks up lines and proactively fixes bit-flips as a background activity. I've actually had a bitflip translate into persistent corruption on the hard drive. I don't want that again.
FWIW, I work in the embedded space architecting chips with large amounts of on-chip RAM. These chips go into various infrastructure pieces, such as cell phone towers. These days we can't sell such a part without ECC, and customers are always wanting more. We actually characterize our chip's RAM's bit-flip behavior by actively trying to cause bit-flips in a radiation-filled environment. Serious business.
Now, other errors that parity/ECC used to catch, such as signal integrity issues from mismatched components or devices pushed beyond their margins... Yeah, I can see improved technology helping that.
With today's wide buses, parity RAM is ECC RAM. It's worth paying the extra couple dollars.
Several years back I experienced disk corruption that seemed to be due to a bitflip that had happened in RAM and got committed to disk. That machine didn't have ECC RAM. I went to ECC for everything after that. That was back in the 128MB days, and no I don't overclock.
(Well, not aggressively. My machine is overclocked by about 1%.)
Right, because your child is never in a situation where it's unacceptable and/or extremely rude to talk on a cell phone, such as while driving, watching a movie in a theater, attending class or on another phone call. Texts at least have the benefit of being asynchronous. I know that the text arrived, and I can get back to the person discreetly at the first available opportunity.
I came here to say something along these lines. Just because someone got a good deal on eBay and so his project ended up being cheaper than a mass produced panel doesn't mean that one can mass produce panels cheaply just by buying everything on eBay to solder in your garage.
Either this guy got stuff that "fell off the back of a truck," or got lucky and paid less than what they were worth to a distressed seller. There's no good reason to believe that his experience is reproducible on any large scale. There was no innovative manufacturing process here.
Now, if he'd figured out how to make the actual cells in his garage for cheaper than we can in a proper fab, that'd be a big breakthrough, particularly if he didn't run afoul of the local environmental authorities while doing so. Alas, making solar cells generally involves such fun things as arsenic or selenium and such, not to mention industrial solvents for etching, and those aren't the friendliest chemicals to play with.
You missed my point. If you're going to do all this stuff from scratch, it's sometimes easier to work with a higher spec part. I write homebrew video games and make homebrew cartridges for an 80s video game system, so the point of the project wasn't lost on me.:-)
And, without seeing the original website, it's hard to say how much of the software stack he did himself. From what others have said, the PICaxe comes with BASIC built in, and so it's a much more turn-key thing. The "Linaxe" link is to "linaxe.bas", so it seems likely that the OS is just the PICaxe BASIC.
Am I saying the project is pointless? No! I'm a CPU focused guy, so that's what I zeroed in on, since that's all I had to go on. (Website's slashdotted.) If it were me picking a CPU, I'd've gone with a higher spec part because it's still cheap, and I'd write all the software anyway. I've never used a PICaxe before or even heard of them. I didn't know it was set up to be programmed in BASIC by default and be a quick and easy "drop in a CPU and make it go without sweating the programming much" sort of device. If this person is content to code in BASIC, their focus is likely on something else, such as the overall case and presentation. Fine by me.
Errr, I misspoke. My recent PIC projects have been PIC24 (a 16-bit PIC) and the related dsPIC33 (also a 16-bit PIC that happens to have some add'l instructions), not PIC16. Urgl.
I have one of MikroElektronika's boards. It hasn't been a perfect experience, but it got me started quickly. You can see some of my Mad Scientist stuff here. I used the dsPIC33 to emulate video game cartridges in software.:-)
I think it's more of an "end-to-end simplicity" thing vs. raw power.
If you buy the PIC32 I mentioned, it's a powerful low-cost machine, but it's a bit like buying a crate engine, tranny and chassis to build a race car. You better be, or have access to, a competent mechanic to put it together, and you'll have your purpose-built race car.
It sounds like the PICaxe is more like buying a Camry off the lot. It's got all the accoutrements and is ready to go. Turn the key, put it in gear, and you're on the road. Good gas mileage, comfy seats, stereo, etc. But, you won't win any races with it.
Ah, I see. I guess I'm accustomed to writing for microcontrollers, so I never saw that as a barrier. I've even done a design with a related PIC part (PIC16 instead of PIC32), which is why I wondered about the specs on this PICaxe.
If it were me making this sort of laptop, I'd just write my "OS" in C and compile with GCC and be on my merry way.:-) I guess to get to the "self-hosting development" level, though, I'd be wise to get some sort of interpreted language on there, a'la the old BASIC computers of the 80s. It sounds like the PICaxe BASIC is what this has going for it?
Basically, doodling is the human equivalent of wiggling the mouse to keep the screen saver from kicking in when you're not actually typing, just so you can see if something interesting pops up in the inbox.
To improve the batteries, the researchers modified an electrode material called lithium iron phosphate . . . The models suggested a way to improve conductivity by directing lithium ions toward particular faces of crystals within the material.
To exploit this, Ceder included extra lithium and phosphorus. This helps form a layer of lithium diphosphate, a material known for its high lithium-ion conductivity.
Wouldn't it be something if someone trademarks this use of lithium diphosphate on targeted crystal faces as, oh, I dunno, dilithium crystals?
As a long time UNIX / Linux user, I must say I'm impressed.
I do find it amusing that commands I'd expect to be named "dir" and "del" are spelled "ls" and "rm", though.:-)
It definitely seems to draw heavily from the UNIX and Perl tradition, right down to $_. I will say that %{...} seems to one-up perl in the "not obvious what it does" department. Is that the PowerShell equivalent of $(...) from bash?
Traditional Pascal had fixed length strings, and the maximum length of the string was part of the type. That is, there wasn't a "string" type, but rather arrays of characters. "Array [1..80] of character" is a different type from "Array [1..100] of character". To have "variable length" strings, you needed to package these up into a record type, with the length as a separate field.
The early Microsoft BASICs stored the string length in the byte before the string, as I recall, and I believe Turbo Pascal added a variable length String type, but that came later.
Slashdot Mirror
Why not?
Fair enough. As someone else pointed out, the higher energy cosmic rays are the problem, and they result in alpha particles and high speed neutrons and other fun things when they hit atoms in the substrate. So I took a short cut in my explanation. Mea culpa.
Basic point still stands: With large memory arrays of small bits, bit-flip events become more common. The chips we make at work go into cell towers, and are packed in metal cages in concrete buildings, and yet they see higher soft-error rates at higher altitudes. That's why our customers require us to have ECC on our parts.
That was true in 1977 when bits were huge. It's not so true in 2009, when they are a few orders of magnitude smaller.
PC caches have been write-back for a long time (all the way back to the original Pentium!). And, they write-allocate, meaning that a byte write from the CPU could bring the whole line into the cache to merge with the write. (I believe this was optional in the Pentium era, but commonplace not long after.)
Actually, it's not uncommon for large RAM arrays to have "row repair" and "column repair". The RAM array has more rows and columns than are required to provide the rated capacity. During manufacturing testing, they remap some of these to work around defects and increase yield. So, if you're still seeing faults after the production tests have mapped away the obvious faults, I think you're signing yourself up for a bit of pain.
As I recall memtest86 would output a report of the failing locations that you could give to the Linux kernel, telling it what locations to use and to avoid.
Seems like a colossal waste of time to me. If you're not concerned about performance, then it's a question of how much your time's worth. You can get 2GB for $23 and probably less if you spent more than 5 seconds looking like I did. If you spend more than a couple hours futzing with your flaky system to remap all your bad RAM, even if your time is only worth minimum wage, you quickly cross the "worth it" threshold.
Actually, error rates per bit are increasing, because bits are getting smaller and fewer electrons are holding the value for your bit. An alpha particle whizzing through your RAM will take out several bits if it hits the memory array at the right angle. Previously, the bits were so large that there was a good chance the bit wouldn't flip. Now they're small enough that multiple bits might flip.
This is why I run my systems with ECC memory and background scrubbing enabled. Scrubbing is where the system actively picks up lines and proactively fixes bit-flips as a background activity. I've actually had a bitflip translate into persistent corruption on the hard drive. I don't want that again.
FWIW, I work in the embedded space architecting chips with large amounts of on-chip RAM. These chips go into various infrastructure pieces, such as cell phone towers. These days we can't sell such a part without ECC, and customers are always wanting more. We actually characterize our chip's RAM's bit-flip behavior by actively trying to cause bit-flips in a radiation-filled environment. Serious business.
Now, other errors that parity/ECC used to catch, such as signal integrity issues from mismatched components or devices pushed beyond their margins... Yeah, I can see improved technology helping that.
With today's wide buses, parity RAM is ECC RAM. It's worth paying the extra couple dollars.
Several years back I experienced disk corruption that seemed to be due to a bitflip that had happened in RAM and got committed to disk. That machine didn't have ECC RAM. I went to ECC for everything after that. That was back in the 128MB days, and no I don't overclock.
(Well, not aggressively. My machine is overclocked by about 1%.)
Early DRAMs had problems with bit flips due to alpha particles coming from contamination in the packaging. (Here's the original Google search in case that cache link breaks.)
Exactly. If the response to "They didn't drop everything answer my call" is "ZOMG, take the phone away then," there's deeper problems here.
Right, because your child is never in a situation where it's unacceptable and/or extremely rude to talk on a cell phone, such as while driving, watching a movie in a theater, attending class or on another phone call. Texts at least have the benefit of being asynchronous. I know that the text arrived, and I can get back to the person discreetly at the first available opportunity.
I came here to say something along these lines. Just because someone got a good deal on eBay and so his project ended up being cheaper than a mass produced panel doesn't mean that one can mass produce panels cheaply just by buying everything on eBay to solder in your garage.
Either this guy got stuff that "fell off the back of a truck," or got lucky and paid less than what they were worth to a distressed seller. There's no good reason to believe that his experience is reproducible on any large scale. There was no innovative manufacturing process here.
Now, if he'd figured out how to make the actual cells in his garage for cheaper than we can in a proper fab, that'd be a big breakthrough, particularly if he didn't run afoul of the local environmental authorities while doing so. Alas, making solar cells generally involves such fun things as arsenic or selenium and such, not to mention industrial solvents for etching, and those aren't the friendliest chemicals to play with.
--Joe
Hmmm... Maybe tweak this?
You missed my point. If you're going to do all this stuff from scratch, it's sometimes easier to work with a higher spec part. I write homebrew video games and make homebrew cartridges for an 80s video game system, so the point of the project wasn't lost on me. :-)
And, without seeing the original website, it's hard to say how much of the software stack he did himself. From what others have said, the PICaxe comes with BASIC built in, and so it's a much more turn-key thing. The "Linaxe" link is to "linaxe.bas", so it seems likely that the OS is just the PICaxe BASIC.
Am I saying the project is pointless? No! I'm a CPU focused guy, so that's what I zeroed in on, since that's all I had to go on. (Website's slashdotted.) If it were me picking a CPU, I'd've gone with a higher spec part because it's still cheap, and I'd write all the software anyway. I've never used a PICaxe before or even heard of them. I didn't know it was set up to be programmed in BASIC by default and be a quick and easy "drop in a CPU and make it go without sweating the programming much" sort of device. If this person is content to code in BASIC, their focus is likely on something else, such as the overall case and presentation. Fine by me.
Errr, I misspoke. My recent PIC projects have been PIC24 (a 16-bit PIC) and the related dsPIC33 (also a 16-bit PIC that happens to have some add'l instructions), not PIC16. Urgl.
I have one of MikroElektronika's boards. It hasn't been a perfect experience, but it got me started quickly. You can see some of my Mad Scientist stuff here. I used the dsPIC33 to emulate video game cartridges in software. :-)
I think it's more of an "end-to-end simplicity" thing vs. raw power.
If you buy the PIC32 I mentioned, it's a powerful low-cost machine, but it's a bit like buying a crate engine, tranny and chassis to build a race car. You better be, or have access to, a competent mechanic to put it together, and you'll have your purpose-built race car.
It sounds like the PICaxe is more like buying a Camry off the lot. It's got all the accoutrements and is ready to go. Turn the key, put it in gear, and you're on the road. Good gas mileage, comfy seats, stereo, etc. But, you won't win any races with it.
Ah, I see. I guess I'm accustomed to writing for microcontrollers, so I never saw that as a barrier. I've even done a design with a related PIC part (PIC16 instead of PIC32), which is why I wondered about the specs on this PICaxe.
If it were me making this sort of laptop, I'd just write my "OS" in C and compile with GCC and be on my merry way. :-) I guess to get to the "self-hosting development" level, though, I'd be wise to get some sort of interpreted language on there, a'la the old BASIC computers of the 80s. It sounds like the PICaxe BASIC is what this has going for it?
--Joe
I don't know much about the PICaxe, but for $8 (single unit qtys) you can buy an 80MHz MIPS microcontroller with a lot going for it. This one has 32KB of onboard RAM and 512K of flash.
Basically, doodling is the human equivalent of wiggling the mouse to keep the screen saver from kicking in when you're not actually typing, just so you can see if something interesting pops up in the inbox.
You might like this then.
Tell me if you've heard this one before: "You need to set a good example for the other students."
A real knee-slapper, that one.
Anyone else notice this from the article?
Wouldn't it be something if someone trademarks this use of lithium diphosphate on targeted crystal faces as, oh, I dunno, dilithium crystals?
First, transparent aluminum, and now this!
They don't care. They don't have to. They're the Phone Company. Just ask Ernestine!
As a long time UNIX / Linux user, I must say I'm impressed.
I do find it amusing that commands I'd expect to be named "dir" and "del" are spelled "ls" and "rm", though. :-)
It definitely seems to draw heavily from the UNIX and Perl tradition, right down to $_. I will say that %{...} seems to one-up perl in the "not obvious what it does" department. Is that the PowerShell equivalent of $(...) from bash?
Makes me feel old. I've been using it for almost 17 years (since fall 1992), and I'm certain there's greybeards here that'll call me a n00b.
Traditional Pascal had fixed length strings, and the maximum length of the string was part of the type. That is, there wasn't a "string" type, but rather arrays of characters. "Array [1..80] of character" is a different type from "Array [1..100] of character". To have "variable length" strings, you needed to package these up into a record type, with the length as a separate field.
The early Microsoft BASICs stored the string length in the byte before the string, as I recall, and I believe Turbo Pascal added a variable length String type, but that came later.