Really? I'm curious, let's say I have an SSD. I write block 0. The SSD controller, being the affable chap that it is, happily puts that in some cell somewhere on the device. I write block 0 again. The SSD controller, still being quite affable, knows that if it keeps rewriting the same cell the cell will fail in time. So it remaps block 0 to some other cell. I turn off the power. Turn it back on. Then I ask my SSD controller to read me back block 0. Where does it get the data from? The first cell I wrote to or the second cell? For correct functioning that's going to be the second cell. How does it know? Perhaps it writes a table of block->cell mappings.
It has a table. It maps an LBA, i.e. a sector number to a physical address.
And that table is stored where? In flash memory perhaps. Now that bit of flash memory is going to get the hell written out of it. In fact that bit will get a write for every remapping that the controller does. And what is the life time of that bit of memory?
I'm actually serious about this. I've never met anyone who could explain to my what that doesn't happen.
If you invert the table, you can store it in flash. So when you write LBA 0 to block 342 you mark that as containing block 0. When block 0 is rewritten you write it to block 567 and mark block 342 as obsolete. This has the handy property that you only need to update the table when you write a sector. You need to garbage collect the obsolete sectors.
So you effectively have a table such that table[physical address]=LBA, which is obviously non optimal for data access - you'd need to do a linear search for every write or read.
Some drives will scan at startup and build a table in RAM so that ram_table[LBA]=physical address but this will need a lot of RAM
Others will write it to flash. But the ones that write it into flash will need to keep moving it around. E.g. one possibility is to use unused LBAs (I've seen negative LBAs used for this) for the mapping table. If you do that you can keep a list of the physical blocks containing the mapping table in RAM. This is likely to be fairly compact. A 4 byte integer in RAM can tell you where a page of the mapping table is, and that page gives you the addresses of say 2048/4 sectors, or 1MB of data. You could easily have enough RAM in the controller to keep track of the list of pages in the mapping table. Of course the drawback to this scheme is that you need to rewrite two pages in flash for every write - one for the data and one for the mapping table.
Now you have a scheme like this. When reading a sector you look in ram to find the relevant page of the mapping table, read the mapping table (of course you can have a RAM cache for the most frequently used pages - which interestingly means that SSDs do have an analogue of seek delays - the first access to a new part of the disk will require an extra page read) and then read the data.
Now of course I've glossed over a bit of subtlety here - the page size of the flash is bigger than 512 bytes, typically 2048 bytes. You can emulate 512 bytes by doing read/modify write cycles, or (better) batch up multiple 512 byte writes into one or more sectors. To make it fast you need to aim to be writing to multiple chips in parallel - probably at least 8. So maximum write speed will only happen when writing in big chunks.
Most likely SSDs will run better with a bigger cluster size. There's even an argument for increasing the sector size.
Those AMD flashes with 1 million write cycles were probably NOR flash. NAND flash is typicall 100,000 cycles for SLC and 10,000 cycles for MLC. Most consumer SSDs use MLC because it is cheaper.
So you have to make a choice between "a floppy is much likely to be readable in any floppy drive than a CD/DVD in a random CD/DVD drive" and "no fucking burning".
Well yeah. But I said writeable optical media can do most of what a floppy does, not all. Actually I can live with having to use Nero to burn stuff.
Well to be fair most of that you can do with a CD or DVD -R or -RW. There were even various attempts to make drag and drop work - UDF and Mount Rainier and even DVD-RAM, though I still use ISO because it's compatible with everything.
El Torito booting should work on pretty much any machine now - it's a lot less hit and miss than booting off USB.
Plus a lot of people can make up plausible sounding bullshit and get modded up for it.
Re:Buying ARM for a leg?
on
Apple To Buy ARM?
·
· Score: 2, Informative
Except that unfortunately Apple doesn't have the market share necessary for anti trust to kick in. A court would have do declare them a monopoly for this to happen a la Microsoft. And they could do a lot of damage before this becomes possible.
Plus Flash doesn't run efficiently on anything other than Windows anyway. Flash on OSX is dramatically slower and takes up twice as many CPU cycles to play videos or animations as on Windows running on identical hardware (and by twice as many, I mean like 20-80% of CPU cycles on two cores, just to play a single, non-HD video).
Well if you listen to Adobe Flash takes more CPU time on the OSX because OSX doesn't provide a suitable API to play hardware accelerated video.
From what I can tell the reason Windows does is because Microsoft arranges meetings between their engineers and those from important third parties. So most likely hardware acceleration is something that Adobe has been consulted about while the API was being designed. At least thats how DirectX has evolved.
Seems like if Apple wants third parties to produce software for their platforms - and right now that is actually not clear - they should do the same rather than pushing out APIs and tools they don't want or can't use and then declaring them a Public Enemy for producing code that performs badly.
I haven't found a huge pushback against relatively unobtrusive ads that are reasonably tasteful, especially if the site owner explains why they were introduced
Now block.png will be displayed under the ads. Make sure it is the same size as the ad frame, and explains why you have adverts. If they use Adblock, they will see it and hopefully turn it off for your site.
Or, if you have a sick sense of humour explain how your kids are crying because they are hungry, and they are hungry because you can't buy them food and that is because of decreased ad revenue so you have to beat them. Maybe make a faux ad with pictures of crying children.
I particularly like the way the name ACTA sounds like a gansta version of Actor when it's Hollywood that bought it. Guess all those donations to the Democrats are now starting to pay off.
The music lobby is even more extreme. Bono said that China's censorship shows it is possible to stop file sharing. Maybe we'll see a RAPPA act that forces ISPs to do deep packet inspection to block torrents.
Yeah but the whole CPU core including those tricks is a small percentage of die area. Look at any CPU and it will be mostly cache. As someone puts it here
http://www.edn.com/blog/920000692/post/370042437.html 1. The claim that the instruction decoder on the Atom is huge is nothing more than a straw man. While this sort of claim might have been somewhat accurate 20 years ago, instruction decoders are tiny compared to the rest of a processor with today's designs. Atom's decoder is almost nothing compared to other parts of the processor, which mostly consists of caches by this point (like all modern processors used as CPUs). I have no special knowledge because I don't work for Intel, but there's a die photo of Intel’s Atom processor in the April 7, 2008 article on the Atom by Tom Halfhill ("Intel’s Tiny Atom") in The Microprocessor Report. The die photo outlines the processor’s main blocks, including the FEC (front-end cluster), which includes the instruction decoder, branch predictor, I cache, prefetch buffers, and instruction TLB. The entire FEC consumes about 10% of the die (that’s a quick eyeball estimate) and the instruction decoder is a small portion of that 10%. The very visible, regular features of the I cache, prefetch buffers, and TLB constitute most of the area devoted to the FEC. Put the instruction decoder down as consuming a mere 1-2% of the Atom's real estate.
You mention self modifying code. SMP machines need to bus snoop anyway - handling x86 code semantics means you need to snoop on data writes from the processor into its own instruction scheme.
Still it has to be correct but it doesn't need to be fast. Basically the CPU has to catch any hint of this and flush caches. So in practice self modifying code will run very slowly and thus be rather uncommon.
It's like all x86-isms. Yes some nasty stuff is legal and a CPU must support it. However it is not common and performance critical code won't do it. Which explains why only a few percent of the die is used. Most of the die is used for cache, and that is not wasted by any reasonable definition.
a content filter (to keep Joe Sixpack in Receiving from ogling at boobs, then Jane Nubile from HR sees it and then promptly files a sexual harassment lawsuit when she sees it). NAC devices (to enforce presence of antivirus utilities likely forced per agreements), equipment to log packets (ACTA will force all ISPs and carriers to log *every* packet across their network for 7 years. Not headers. Entire packets).
I always follow the Intensive Poulty Farming Best Practices. Both Joe and Jane are thus spayed, declawed, detoothed and lobotomised before entering the cubicle farm. Thus they have no interest in boobs and or of concepts like "sexual harassment".
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
I had this problem too. Asus have a bunch of suppliers of adapters. Delta are good, the others are bad. If you have a bad adapter the thermal fuse will trip when you plug it in - you can reset it by putting it in the fridge. Best solution is to get Asus to swap your adapter for one made by Delta Electronics
Slashdot Mirror
Free Tibet?
Offer only valid when purchasing another Tibet at the normal price.
In the distant future people will be complaining about the people who complained about the people who complained about twitter's sock puppets.
Really? I'm curious, let's say I have an SSD. I write block 0. The SSD controller, being the affable chap that it is, happily puts that in some cell somewhere on the device. I write block 0 again. The SSD controller, still being quite affable, knows that if it keeps rewriting the same cell the cell will fail in time. So it remaps block 0 to some other cell. I turn off the power. Turn it back on. Then I ask my SSD controller to read me back block 0. Where does it get the data from? The first cell I wrote to or the second cell? For correct functioning that's going to be the second cell. How does it know? Perhaps it writes a table of block->cell mappings.
It has a table. It maps an LBA, i.e. a sector number to a physical address.
And that table is stored where? In flash memory perhaps. Now that bit of flash memory is going to get the hell written out of it. In fact that bit will get a write for every remapping that the controller does. And what is the life time of that bit of memory?
I'm actually serious about this. I've never met anyone who could explain to my what that doesn't happen.
If you invert the table, you can store it in flash. So when you write LBA 0 to block 342 you mark that as containing block 0. When block 0 is rewritten you write it to block 567 and mark block 342 as obsolete. This has the handy property that you only need to update the table when you write a sector. You need to garbage collect the obsolete sectors.
So you effectively have a table such that table[physical address]=LBA, which is obviously non optimal for data access - you'd need to do a linear search for every write or read.
Some drives will scan at startup and build a table in RAM so that ram_table[LBA]=physical address but this will need a lot of RAM
Others will write it to flash. But the ones that write it into flash will need to keep moving it around. E.g. one possibility is to use unused LBAs (I've seen negative LBAs used for this) for the mapping table. If you do that you can keep a list of the physical blocks containing the mapping table in RAM. This is likely to be fairly compact. A 4 byte integer in RAM can tell you where a page of the mapping table is, and that page gives you the addresses of say 2048/4 sectors, or 1MB of data. You could easily have enough RAM in the controller to keep track of the list of pages in the mapping table. Of course the drawback to this scheme is that you need to rewrite two pages in flash for every write - one for the data and one for the mapping table.
Now you have a scheme like this. When reading a sector you look in ram to find the relevant page of the mapping table, read the mapping table (of course you can have a RAM cache for the most frequently used pages - which interestingly means that SSDs do have an analogue of seek delays - the first access to a new part of the disk will require an extra page read) and then read the data.
Now of course I've glossed over a bit of subtlety here - the page size of the flash is bigger than 512 bytes, typically 2048 bytes. You can emulate 512 bytes by doing read/modify write cycles, or (better) batch up multiple 512 byte writes into one or more sectors. To make it fast you need to aim to be writing to multiple chips in parallel - probably at least 8. So maximum write speed will only happen when writing in big chunks.
Most likely SSDs will run better with a bigger cluster size. There's even an argument for increasing the sector size.
Those AMD flashes with 1 million write cycles were probably NOR flash. NAND flash is typicall 100,000 cycles for SLC and 10,000 cycles for MLC. Most consumer SSDs use MLC because it is cheaper.
So you have to make a choice between "a floppy is much likely to be readable in any floppy drive than a CD/DVD in a random CD/DVD drive" and "no fucking burning".
Well yeah. But I said writeable optical media can do most of what a floppy does, not all. Actually I can live with having to use Nero to burn stuff.
Well to be fair most of that you can do with a CD or DVD -R or -RW. There were even various attempts to make drag and drop work - UDF and Mount Rainier and even DVD-RAM, though I still use ISO because it's compatible with everything.
El Torito booting should work on pretty much any machine now - it's a lot less hit and miss than booting off USB.
Plus a lot of people can make up plausible sounding bullshit and get modded up for it.
Except that unfortunately Apple doesn't have the market share necessary for anti trust to kick in. A court would have do declare them a monopoly for this to happen a la Microsoft. And they could do a lot of damage before this becomes possible.
Plus Flash doesn't run efficiently on anything other than Windows anyway. Flash on OSX is dramatically slower and takes up twice as many CPU cycles to play videos or animations as on Windows running on identical hardware (and by twice as many, I mean like 20-80% of CPU cycles on two cores, just to play a single, non-HD video).
Well if you listen to Adobe Flash takes more CPU time on the OSX because OSX doesn't provide a suitable API to play hardware accelerated video.
From what I can tell the reason Windows does is because Microsoft arranges meetings between their engineers and those from important third parties. So most likely hardware acceleration is something that Adobe has been consulted about while the API was being designed. At least thats how DirectX has evolved.
Seems like if Apple wants third parties to produce software for their platforms - and right now that is actually not clear - they should do the same rather than pushing out APIs and tools they don't want or can't use and then declaring them a Public Enemy for producing code that performs badly.
Anonymous Coward to Bad Mod : I will break you!
I haven't found a huge pushback against relatively unobtrusive ads that are reasonably tasteful, especially if the site owner explains why they were introduced
Wrap the ad code in a div with this style.
Now block.png will be displayed under the ads. Make sure it is the same size as the ad frame, and explains why you have adverts. If they use Adblock, they will see it and hopefully turn it off for your site.
Or, if you have a sick sense of humour explain how your kids are crying because they are hungry, and they are hungry because you can't buy them food and that is because of decreased ad revenue so you have to beat them. Maybe make a faux ad with pictures of crying children.
I particularly like the way the name ACTA sounds like a gansta version of Actor when it's Hollywood that bought it. Guess all those donations to the Democrats are now starting to pay off.
The music lobby is even more extreme. Bono said that China's censorship shows it is possible to stop file sharing. Maybe we'll see a RAPPA act that forces ISPs to do deep packet inspection to block torrents.
It's ignoring the fact that 90-99% of die area on any modern CPU is a cache of some sort - i.e. instruction or data, or a TLB, or an branch predictor.
Yeah but the whole CPU core including those tricks is a small percentage of die area. Look at any CPU and it will be mostly cache. As someone puts it here
http://www.edn.com/blog/920000692/post/370042437.html
1. The claim that the instruction decoder on the Atom is huge is nothing more than a straw man. While this sort of claim might have been somewhat accurate 20 years ago, instruction decoders are tiny compared to the rest of a processor with today's designs. Atom's decoder is almost nothing compared to other parts of the processor, which mostly consists of caches by this point (like all modern processors used as CPUs). I have no special knowledge because I don't work for Intel, but there's a die photo of Intel’s Atom processor in the April 7, 2008 article on the Atom by Tom Halfhill ("Intel’s Tiny Atom") in The Microprocessor Report. The die photo outlines the processor’s main blocks, including the FEC (front-end cluster), which includes the instruction decoder, branch predictor, I cache, prefetch buffers, and instruction TLB. The entire FEC consumes about 10% of the die (that’s a quick eyeball estimate) and the instruction decoder is a small portion of that 10%. The very visible, regular features of the I cache, prefetch buffers, and TLB constitute most of the area devoted to the FEC. Put the instruction decoder down as consuming a mere 1-2% of the Atom's real estate.
You mention self modifying code. SMP machines need to bus snoop anyway - handling x86 code semantics means you need to snoop on data writes from the processor into its own instruction scheme.
Still it has to be correct but it doesn't need to be fast. Basically the CPU has to catch any hint of this and flush caches. So in practice self modifying code will run very slowly and thus be rather uncommon.
It's like all x86-isms. Yes some nasty stuff is legal and a CPU must support it. However it is not common and performance critical code won't do it. Which explains why only a few percent of the die is used. Most of the die is used for cache, and that is not wasted by any reasonable definition.
a content filter (to keep Joe Sixpack in Receiving from ogling at boobs, then Jane Nubile from HR sees it and then promptly files a sexual harassment lawsuit when she sees it). NAC devices (to enforce presence of antivirus utilities likely forced per agreements), equipment to log packets (ACTA will force all ISPs and carriers to log *every* packet across their network for 7 years. Not headers. Entire packets).
I always follow the Intensive Poulty Farming Best Practices. Both Joe and Jane are thus spayed, declawed, detoothed and lobotomised before entering the cubicle farm. Thus they have no interest in boobs and or of concepts like "sexual harassment".
Manually editing text is time-consuming, fatiguing and error prone. Have a tool to automate that sort of thing is one of the fundamental reasons for having computers in the first place.
There's a great tool called vi.
"Windows Me? - Does this mean 'Windows' is now a verb?"
No, Java Enterprise Web System I believe. I see a lot of self parodic posts blaming that API for all manner of implausible ills.
Well yeah, but it would still be cruel to teach it in University.
At least they don't teach about how to quickly Alt Tab from slashdot to your three day old half completed TPS report when the boss walks by.
I had this problem too. Asus have a bunch of suppliers of adapters. Delta are good, the others are bad. If you have a bad adapter the thermal fuse will trip when you plug it in - you can reset it by putting it in the fridge. Best solution is to get Asus to swap your adapter for one made by Delta Electronics
http://forum.eeeuser.com/viewtopic.php?id=73638&p=4
IANAL but IIRC only people with souls are allowed in UK courts.
My Asus 1005HA can manage 9 hours of battery life. The newer, Pineview based 1005PE does even better.
http://www.engadget.com/2009/12/21/asus-eee-pc-1005pe-review/
But then Anders Hejlsberg will have him encased in carbonite and mounted on his office wall as a trophy.
Yeah but he doesn't have a freezer full of Whoppers