Yes, but without the protections of a government regulated middleman, which is what normal exchanges have, the traders involved will be subject to extraordinary risks on those sorts of contracts (totally separate from the actual trading value of a bitcoin which itself carries extraordinary risks). Even the current Bitcoin exchanges are subject to severe carry risks (as people using one of the Chinese exchanges that pulled up stakes and disappeared along with all of their money found out recently).
I think there are a lot of people who don't really understand how the public stock or derivatives markets work and believe, falsely, that the mechanisms can be safely replicated by an unregulated entity. Frankly, it takes supreme stupidity to trust any amount of money to these businesses.
Mmm. I kinda wonder how you could possibly believe that Bitcoin is a good store of value when it's 'value' can fluctuate 50% in 2 days and when it has a trading spread of over 2% much of the time.
So far all Bitcoin has been good at is in parting fools from their money.
Depends how much you value your 'movie and music' collection. Once you take into account the fact that your HDDs have to be replaced every few years no matter what (even if powered off and sitting on a shelf), whereas your SSDs are as good as their write-wear limit.
Since movie and music collections are essentially archival data, the SSD is actually a pretty good medium for storing them long-term. You just rewrite the SSD once every few years to keep all the flash cells fresh (on top of adding new videos and music) and it will last many times longer than a HDD.
This narrows the cost factor by a lot. Take (just for comparison) a 1TB HDD for around $90 and a 1TB SSD for around $530. To be conservative lets say that's about a 6:1 cost ratio (SSD:HDD). But when you factor-in the SSDs far longer life span, even being conservative you are still talking 3 HDD replacements per SSD replacement (and more realistically it will be 6+ HDD life cycles but I'll ignore that for now).
The cost difference for your long-term archival storage is now 2:1. The SSD is still double the price, but look at what you get for that: Always on (eats very little power so you can keep it plugged in), NO wear when not writing, NO replacement hassle every few years. Throw in the need for multiple live backups and/or RAID and it becomes a no-brainer.
The write profile of the filesystem, not the write profile of the program. Programs doing small writes, including standard log-writing, will not generally wind up causing small writes to actually go to the media. The filesystem cache will collect them all together and the SSD will actually get fairly optimal writes (or be able to write-combine less optimal writes). Most modern filesystems are going to do a pretty good job of this already.
There are always exceptions, usually niche situations. For example, database updates can often wind up modifying just a few hundred bytes in a large 16KB block of data, fsync(), then randomly seek and do it somewhere else... that can create some serious problems for SSDs if the database is constantly doing random piecemeal writes (verses the simple file appends that log-file writing does), if not managed properly. Databases will have knobs that allow one to tune flushes and that should solve most of the issues people bring up... but not all.
Another common situation is improperly using a SSD to stage gigabytes of temporary data (coming in regularly) that you intend to process and then wipe / start-over. SSDs are great for archiving data that doesn't change much, and can handle a certain number of write/re-write cycles, but you don't want to fill one up then rm -rf then fill it up again continuously. That WILL wear it out.
These sorts of exceptions are not in the majority though. Nearly all consumer use (or even power-user use or unix programmer / personal-home-network use, including modest SWAP use) simply don't generate sufficient write activity to even have to worry about the SSD wear limit. Server use cases will also mostly be SSD-friendly, but there will be situations where they aren't.
It doesn't take a whole lot of brains for a good sysad to deal with it. It's virtually a non-issue in my book. We can't fix stupid sysads or IT managers, and we shouldn't try.
MLC at ~20nm is 1000-3000 or so (older MLC's using larger chip feature sizes could run in the 10000+ range). The wear indicator will probably hit zero somewhere between 1000 and 2000 erase cycles (over the full drive). It's usually conservative so it might indicate zero after ~1000 erase cycles or so but it depends, but usually the drive can continue to be written to well past 2000 erase cycles.
However, if you continue to write significantly to the drive after the wear counter reaches zero then you risk catastrophic failure above and beyond what the vendor nominally targets. Cells can wind up going bad and causing massive corruption past a certain point if left to sit a while, even if the last write & verify succeeded.
There is a lot of misinformation on SSD failure modes, mostly because people ignore what SMART tells them and run their SSDs into the ground before replacing them.
Basically it comes down to this... The drive has a pretty good idea of how worn-down the flash chips get. It will count-down the wear indicator (from SMART) from 100 to 0. At the point it reaches 0 the drive can no longer guarantee nominal operations.
If you continue writing to the drive AFTER the wear indicator has reached 0 then you CAN have catastrophic failure situations. The more you write to the drive after that point, the more likely it will happen. In many cases you can write 2x or more the amount you wrote to get from 100 to 0 and the drive will work fine, which is why people tend to ignore the wear indicator after it has hit 0. But the drive just can't guarantee that data integrity will be within reason after the wear indicator hits 0.
If you replace the drive when the wear indicator has reached zero then you are far less likely to get a catastrophic failure. Sure they can still happen... failures are not intentionally created by the drive firmware after all. But if you use the wear indicator properly you can mitigate the catastrophic failure cases by at least an order of magnitude (and probably better).
It's that simple.
--
It is also true that there have been many firmware bugs over the years. SSDs at these capacities are fairly new beasts after all. There are dozens and dozens of SSD brands (though really only three major controller chipsets). Firmware is where the differences are. The only two vendors *I* trust are Crucial and Intel and that is it... I trust them because they are clearly staying on top of their firmware upgrades.
Even with the firmware bugs I know exist on my oldest SSDs (Intel 40Grs), I haven't had any failures. In fact, at this point I have at least 30 SSDs in operation and have yet to actually see any honest-to-god failures. I am certainly more confident of newer models (for Intel and Crucial anyhow) than older ones. Firmware might have a few hicups here and there as time passes but it will generally just get better and better. Judging a current deployment based on 5-year-old distrust is stupid.
I think you're a bit confused over how normal filesystem operations are cached on a modern OS (e.g. OS X, Linux, BSDs, Solaris, etc). Even normal log writing (whether you run it through a compression program or not) on a normal non-SSD-aware filesystem is not going to result in tiny little writes to the SSD. The writes will simply wind up in the buffer cache (or equivalent) and get flushed to media when the filesystem syncer comes around every 30-60 seconds or so. The most highly fragmented case in this situation might require the SSD to flush a 128KB a dozen times each 60 seconds which doesn't even remotely wear it out. Only a complete idiot tries to fsync() a log file on each line, so baring that... it isn't an issue.
I've heard this complaint many times over the years and not one person has EVER provided any factual information as to what and how much and how often they are actually writing to the SSD. Not once.
The amount of data being written is always an issue with a SSD, but if it's being permanently stored it actually isn't the issue you think it is because the equivalent cost of storage for archival data is actually better with a SSD simply due to the SSD in write-once situation lasting forever (maybe rewrite a full drive once every 5 years or so to refresh the cells x ~1000-3000 rewrites). The SSD will easily last 25 years or longer (probably until the firmware itself degrades), whereas a HDD has to be replaced every 3-5 years whether it's off, idle, or doing work. SSDs are great for archiving stuff. They take virtually no energy when idle and can simply be left attached and powered and the only real wear occurs when you write.
For temporarily staged data... this is probably a SSDs one issue. There is a wear limit after all, so constantly rewriting the drive at a high rate will wear it out. But this is also a problem with an easy solution... since such data is usually laid down linearly and processed linearly, HDDs are still useful as a storage medium. Simpler staging of temporary data doesn't even have to use ANY media if the data trivially fits in ram... you just use a tmpfs mount and schedule a job to process the data at reasonable intervals.
In terms of swap, again you appear to be confused. Simply placing swap on a SSD is not going to wear it out. It depends heavily on how much the OS actually pages data in and out. In most consumer/home-system situations the answer will be 'not often' (relative to the SSD's wear limit). In a server situation swap is not written to under normal operating conditions at all unless someone made a major mistake. It's just there to handle DOS attacks and burst situations in order to allow the system to be tuned to utilize all of its resources as fully as possible.
For example, again a 'tmpfs' (memory filesystem) which is backed by swap can actually be VERY write-efficient since the OS isn't going to flush it to its backing media unless the system is actually under memory pressure. If one schedules things such that the system is not normally under memory pressure (which is a typical case for a server installation), then the SSD won't be worn out... but it will be available for those situations that happen every once in a while that really need it.
Oh well, I don't expect much from Slashdot posters anyway. But, honestly, these things should be obvious to people by now.
That's a joke, right? You actually believe Bitcoin is accepted and trusted by merchants? You can count the number of serious businesses trying to use bitcoin on one hand. Walmart's virtual currency is already used in far more transactions than Bitcoin ever will be.
You are staring at pretty numbers on a screen and have absolutely no sense of scale.
And as far as credit cards go, the space is getting pretty crowded already with Yahoo, Google, and others pushing into the space (after realizing that wallet apps are pretty useless without them). Lets see someone due monetary conversions to a bitcoin account with a credit card and see how long it takes them to either go bankrupt or be forced to charged significant fees to stay in business.
Bitcoin has no advantage whatsoever as a first-mover when the 'currency' is too unstable to actually be usable in the wider world of commerce.
Why would the world population want to do that when they could be using BTC2 or BTC3 or... BTC (each with a slight tweek of the algorithm) instead?
There are tons of virtual currencies already in existence, and no barrier to entry for creating more (including no barrier to entry for creating clones of Bitcoin that use a different cryptographic base).
It costs me $0 to transfer dollars to relatives electronically, bank-to-bank. No fees at all.
Also, perhaps you are unaware, but Western Union has been losing business for two decades now. Many immigrants now send money home by opening a bank account and mailing a physical ATM card to their relatives, which can cost as little as $0 if the relatives withdrawal the cash in $ (which many can), and can be as little as 1% if a currency conversion is involved.
Even using a non-network ATM typically has a fixed charge, e.g. $3/$300 = 1% charge to get a hard currency in one's pocket.
Bitcoin cannot do better (people who think they can transfer BTC for free are ignoring both the exchange spreads and the time/volatility factor).
This mechanism is no guarantee that the seller will actually get the price they programmed in. In a crash there is not likely going to be a buyer at or above the programmed-in price and the seller can't force counter-parties to buy BTC (or anything) at the desired price.
In fact this mechanism exists in the real stock market and is manipulated all the time by contrived flash crashes to force those sell points to get hit. Since the price crashes through the sell levels so quickly there are no buyers at those prices and the sales wind up going at the market and forcing the stock down even more. Even worse, enough people using this sort of mechanism can CAUSE computer-driven crashes and lose their shirts in the process.
Unlike something like Bitcoin, stocks actually do have a real intrinsic value (even if investors can't calculate it with any accuracy). Which means that you can't sell a stock into oblivion and expect it to stay there very long. In the case of flash crashes, sometimes seconds, up to a few minutes at best. People who use these sorts of orders can wind up with sold positions and a stock price that has recovered before they can react and then they are screwed.
You've hit upon the basic mechanism but you haven't taken the next logical step. The issue is what happens when the pricing goes exponential (as it has, twice now).
What happens is that people who 'break even' almost universally go back into the market with more than just the house's money. Because the value is appreciating non-linearly, going back into the market almost always means spending far more money buying back in than you ever got out before that point.
For example, people who cashed out when it was hitting $250 a few months ago are now kicking themselves. In order to buy back in, they have to spend every last drop of their previous profits plus more to obtain a 'reasonable' speculative position at the new price.
This also points to how people's view of money shifts as the market rises, particularly people who have never had a lot of money or have never handled large sums or volumes of money (via their jobs or otherwise)... basically the definition of a 'sucker'. As long as they think they are making money, it becomes like a game of monopoly. In the first round someone who made a few $hundred thought they did really well. In the second round those few $hundred feel like chump change... it takes a few $thousand to really feel that you did well.
Well, it doesn't stop there. It keeps scaling up. In the third round a person might feel that a few $tens-of-thousands is necessary to do well and that a measily few $thousand is chump change. It keeps scaling up until a person either runs out of cash or runs out of borrowing capacity... the mindset continues to scale all the way until the whole thing comes crashing down.
That's why you wind up with people bankrupted instead of people being happy that they had fun playing with the house's money after the first round or two.
There are certainly a few smart people in the Bitcoin market who know how to extract actual profit from the trading. It mostly comes down to understanding the scaling effect and NOT being tricked by it (not scaling up the investment in each successive round by more than 1/2 the profit from the previous round). There are numerous well-known methodologies and I'm certain a small but significant percentage of Bitcoin traders are doing precisely that.
People doing the above scheme are the smart ones. They are draining hard money (real dollars) from the exchange against everyone else who is continuing to lever up. In the end, real money has been removed from the exchange while the remaining participants are basically just playing musical chairs with each other. When the eventual panic occurs there is simply not enough cash left with the exchange participants to cover everyone and the value crashes into oblivion.
This is how it will play out. It is ALWAYS how it plays out. Bitcoin is not going to be an exception.
VISA is more like 1% (or less) for anyone doing real volume. Small businesses have plenty of choices for credit card transactions... even Apple is getting into the game. And besides, if you want to compare Bitcoin transaction costs against something you should be comparing against something like PayPal, not VISA.
For bitcoin on either Mt Gox or coinbase, the bid/ask spread *alone* for a small transaction is ~0.5% or so, and exceeds 1% for the types of volumes a small business would have (and that is only just recently. Just a few days ago the spread was easily over 2%). That's just the bid/ask spread, never mind any other fees.
Anyone who thinks they are doing bitcoin transactions for 'free' is smoking something.
What we have here are a whole lot of people so fixated on the hype they don't realize just how much they are getting milked.
Maybe several million dollars when purchased new, but pretty much all computing equipment depreciates to near worthlessness over a few years, not to mention the cost of power. So if you are trying to argue that bitcoin has something physical backing it then it kinda falls on its face.
Nobody in their right mind can argue that Bitcoin is a usable currency. Currencies have to be relatively stable in the short-term. Bitcoin obviously isn't even remotely stable. Not only is it not stable, but it has no mechanisms at all to make it stable.
It's the classic (and obvious) hording / tulip-mania mechanic and I think most investors know this, but greed still rules until the day the whole thing comes crashing down around people's ears.
I've read the space map work but there are several issues that make them impractical for H2. The main one is that H2 snapshots are read-write (ZFS snapshots are read-only). Secondarily, my experience from H1 is that any complicated ref-counting or space accounting can lead to hidden corruption. Even if we assumed that the media data validation mechanism (a CRC or cryptographic hash) detects all media issues, there is still the problem of software complexity introducing bugs at a higher level.
So H2 is going to use a relatively simple freemap mechanism. In fact, it is using the same dynamic radix tree for the freemap as it does for the file and directory topology. It will still roll-up tiny allocations into a somewhat chunkier granularity to reduce freemap overhead (similar to what H1 did but at a finer 1KB grain vs H1's 2MB granularity), and it will roll-up space availability hints and propagate them up the tree. And it is type-aware so it can do things like collect inode allocations together for burstability. It isn't trivialized. But it does not attempt to implement ref-counting or any complex sub-topology to keep track of who and how many own which blocks.
The actual block freeing is going to be done in the background rather than in the 'rm' path (for a COW filesystem with snapshots which are actually used regularly, there's no point trying to free blocks in real time). This will allow H2 to implement several major features such as de-duplication, writable snapshots, and so forth with far less software complexity. So the complexity of the block allocation and any block duplication becomes trivialized while the complexity of the block freeing code increases. But it's an incrementally solvable problem. I can start with a brute-force memory-bounded scan and slowly add optimizations to recognize duplication in the topology, add topology hints to improve the efficiency of the block freeing scan, and so forth.
This release removes almost all the remaining SMP contention from both critical paths and most common paths. The work continued past the release in the master branch (some additional things which were too complex too test in time for the release). For all intents and purposes the master branch no longer has any SMP contention for anything other than modifying filesystem operations (such as concurrent writing to the same file). And even those sorts of operations are mostly contention free due to the buffer cache and namecache layers.
Generally speaking what this means is that for smaller 8-core systems what contention there was mostly disappeared one or two releases ago, but larger (e.g. 48-core) systems still had significant contention when many cores were heavily resource-shared. This release and the work now in the master branch basically removes the remaining contention on the larger multi-core systems, greatly improving their scaling and efficiency.
A full bulk build on our 48-core opteron box took several days a year ago. Today it takes only 14.5 hours to build the almost 21000 packages in the FreeBSD ports tree. These weren't minor improvements.
Where it matters the most are with heavily shared resources, for example when one is doing a bulk build on a large multi-core system which is constantly fork/exec'ing, running dozens of the same process concurrently./bin/sh, make, cc1[plus], and so on (a common scenario for any bulk building system), and when accessing heavily shared cached filesystem data (a very common scenario for web servers). Under these conditions there can be hundreds of thousands of path lookups per second and over a million VM faults per second. Even a single exclusive lock in these paths can destroy performance on systems with more than 8 cores. Both the simpler case where a program such as/bin/sh or cc1 is concurrently fork/exec'd thousands to tens of thousands of times per second and the more complex case where sub-shells are used for parallelism (fork without exec)... these cases no longer contend at all.
Other paths also had to be cleaned up. Process forking requires significant pid-handling interactions to allocate PIDs concurrently, and exec's pretty much require that locks be fine-grained all the way down to the page level (and then shared at the page level) to handle the concurrent VM faults. The process table, buffer cache, and several other major subsystems were rewritten to convert global tables into effectively per-cpu tables. One lock would get 'fixed' and reveal three others that still needed work. Eventually everything was fixed.
Similarly, network paths have been optimized to the point where a server configuration can process hundreds of thousands of tcp connections per second and we can get full utilization of 10GigE nics.
And filesystem paths have been optimized greatly as well, though we'll have to wait for HAMMER2 to finish that work for modifying filesystem calls to reap the real rewards from that.
There are still a few network paths, primarily related to filtering (PF) that are serialized and need to be rewritten, but that and the next gen filesystem are the only big ticket items left in the entire system insofar as SMP goes.
Well, the last problem, at least until we tackle the next big issue. There's still cache coherency bus traffic which occurs even when e.g. a shared lock is non-contended. The code-base is now at the point where we could probably drop-in the new Intel transactional instructions and prefixes and get real gains (again, only applicable to multi-chip/multi-core solutions, not simple 8-thread systems). It should be possible to bump fork/exec and VM fault performance on shared resources from their current very high levels right on through the stratosphere and into deep space. Maybe I'll make a GSOC out of it next year.
The filesystem work on HAMMER2 (the filesystem successor to HAMMER1) continues to progress but it wasn't ready for even an early alpha
With Intel's 14nm so close, and 10nm production in another year or so, they need to use all that chip area for something that doesn't necessarily generate a ton of heat. RAM is the perfect thing. Not only is the power consumption relatively disconnected from the size and density of the cache, but not having to go off-chip for a majority of memory operations means that the external dynamic ram can probably go into power savings mode for most of its life, reducing the overall power consumption of the device.
Happens to me all the time on ALL my android devices. Totally non-deterministic. Sometimes my Nexus 7 (2012) can sit with the display turned off for several days without losing too much battery, other times I turn it off (display off) and it discharges overnight and is dead in the morning. Happens to both my android phones too. I'm not forgetting to turn off Pandora either.
Sometimes my phone is 'hot' just sitting in my pocket with the screen off. Sometimes it is 'cold'. When it's hot it's obviously eating power doing something, despite the display being turned off. It's totally random when this happens... usually the longer I leave the phone between reboots the more likely it is to get into that state. VERY annoying. NO services are running (nothing in the service bar at the top). Doesn't matter. Still random hot or cold.
Doesn't happen to any of my Apple devices. If I leave an Apple device turned off (sleep mode that is), it retains its battery level and drains at a very slow and highly deterministic rate. If I turn off my iPhone (and I'm not playing music on it), it goes to sleep. Always.
Honestly I don't understand why Google thinks this is ok. It's an obvious competitive advantage for Apple when its devices don't kill their battery and Android devices do.
No no, resistance has nothing to do with it. The USB charger's output is current limited, which means that if the device tries to pull more current than the charger is programmed for, the charger's output voltage will drop. That is, the output will be limited to (for example) 500mA or 1A or 1.5A or whatever and if the device tries to pull more the output will STILL be limited to that value and the voltage will drop from 5V to compensate.
Smart devices can usually ignore the USB resistor-based programming pins (which run to different standards) and simply pull the charger's output down from 5V to 4V or something like that and measure the current (up to a reasonable limit managed by the device, of course), and figure out how much they can pull from the charger based on that.
Stupid devices will either not probe what the charger can actually do or will make assumptions based on the resistor-programmed pins (the one that has multiple standards) and not be able to handle the case where they guess wrong and crow-bar the charger's output by trying to pull too much current.
None of this has anything to do with the resistance of the wires inside or outside the charger.
Two-prong chargers just synthesize a ground. Well, there are two grounds actually... one for the AC side and one for the output side. On the AC side its the average of the AC sine wave between the two prongs taken off the middle of the rectifier. The charger's output is traditionally isolated with a transformer (a small transformer on the output of the switching power supply instead of a big one on the input), which isolates the output and also handles the flyback function for the switching power supply. The feedback circuit is traditionally isolated with an opto-isolator.
So the output side's ground is separate and isolated from the input side's synthesized ground. Which means that the output's ground will float to whatever it is connected to (which is what you want it to do).
The difference between the input side's ground (which is completely internal to the charger) and the output side's ground (which is exposed via the USB connector) is called the common-mode voltage differential. Obviously there are limitations since too much of a differential between the two grounds will cause arcing crossing the physical gap and/or transformer insulation. Most circuits are designed with insulation and gaps large enough to handle at least 600V of common mode.
(Common mode can be experienced directly by touching the 'ground' of a coax cable from your cable provider or touching phone wires whos 'ground' is the C.O. several miles away. The tingling you are feeling is anywhere from 60V to ~300V of common mode difference between the ground where the signal was generated and the ground your body has floated to... typically closer to the ground that your home is anchored to).
What's happening there is that the phone is crow-baring the charger down to under 2V and then mis-interpreting its own voltage sensor (on the phone) thinking that the charger is connecting and disconnecting. Might also be tripping the short-circuit detector on the charger and causing it to cycle.
That's a problem with the phone. No phone should crow-bar the 5V the USB outlet provides, particularly not one that outputs >1A. (This is using your description of the charger being hot). All USB power sources are current-limited and the devices being charged have to deal with that properly.
I have a multitude of Apple and Android devices and a multitude of Apple and non-Apple usb chargers and power sources, and also have a little non-Apple dongle charger in the car in the front.
It all works just fine. Apple might have weird charging cables but they still have usb on one end and they've worked with the dozen or so different usb charging sources I've got in the house and in the car.
Most USB chargers only throw out 2-5W. It's gonna take a while to charge-up Apple's big batteries with one of those but it will still work just fine.
Slashdot Mirror
Turns out that wasn't true. The Bitcoin had to be converted to cold hard cash first. Nor was the article about the Tesla being sold for bitcoin.
-Matt
Minus the taxes you owe for the capital gain.
-Matt
Yes, but without the protections of a government regulated middleman, which is what normal exchanges have, the traders involved will be subject to extraordinary risks on those sorts of contracts (totally separate from the actual trading value of a bitcoin which itself carries extraordinary risks). Even the current Bitcoin exchanges are subject to severe carry risks (as people using one of the Chinese exchanges that pulled up stakes and disappeared along with all of their money found out recently).
I think there are a lot of people who don't really understand how the public stock or derivatives markets work and believe, falsely, that the mechanisms can be safely replicated by an unregulated entity. Frankly, it takes supreme stupidity to trust any amount of money to these businesses.
-Matt
Mmm. I kinda wonder how you could possibly believe that Bitcoin is a good store of value when it's 'value' can fluctuate 50% in 2 days and when it has a trading spread of over 2% much of the time.
So far all Bitcoin has been good at is in parting fools from their money.
-Matt
Depends how much you value your 'movie and music' collection. Once you take into account the fact that your HDDs have to be replaced every few years no matter what (even if powered off and sitting on a shelf), whereas your SSDs are as good as their write-wear limit.
Since movie and music collections are essentially archival data, the SSD is actually a pretty good medium for storing them long-term. You just rewrite the SSD once every few years to keep all the flash cells fresh (on top of adding new videos and music) and it will last many times longer than a HDD.
This narrows the cost factor by a lot. Take (just for comparison) a 1TB HDD for around $90 and a 1TB SSD for around $530. To be conservative lets say that's about a 6:1 cost ratio (SSD:HDD). But when you factor-in the SSDs far longer life span, even being conservative you are still talking 3 HDD replacements per SSD replacement (and more realistically it will be 6+ HDD life cycles but I'll ignore that for now).
The cost difference for your long-term archival storage is now 2:1. The SSD is still double the price, but look at what you get for that: Always on (eats very little power so you can keep it plugged in), NO wear when not writing, NO replacement hassle every few years. Throw in the need for multiple live backups and/or RAID and it becomes a no-brainer.
I'm sold. That makes it worth it.
-Matt
The write profile of the filesystem, not the write profile of the program. Programs doing small writes, including standard log-writing, will not generally wind up causing small writes to actually go to the media. The filesystem cache will collect them all together and the SSD will actually get fairly optimal writes (or be able to write-combine less optimal writes). Most modern filesystems are going to do a pretty good job of this already.
There are always exceptions, usually niche situations. For example, database updates can often wind up modifying just a few hundred bytes in a large 16KB block of data, fsync(), then randomly seek and do it somewhere else... that can create some serious problems for SSDs if the database is constantly doing random piecemeal writes (verses the simple file appends that log-file writing does), if not managed properly. Databases will have knobs that allow one to tune flushes and that should solve most of the issues people bring up... but not all.
Another common situation is improperly using a SSD to stage gigabytes of temporary data (coming in regularly) that you intend to process and then wipe / start-over. SSDs are great for archiving data that doesn't change much, and can handle a certain number of write/re-write cycles, but you don't want to fill one up then rm -rf then fill it up again continuously. That WILL wear it out.
These sorts of exceptions are not in the majority though. Nearly all consumer use (or even power-user use or unix programmer / personal-home-network use, including modest SWAP use) simply don't generate sufficient write activity to even have to worry about the SSD wear limit. Server use cases will also mostly be SSD-friendly, but there will be situations where they aren't.
It doesn't take a whole lot of brains for a good sysad to deal with it. It's virtually a non-issue in my book. We can't fix stupid sysads or IT managers, and we shouldn't try.
-Matt
MLC at ~20nm is 1000-3000 or so (older MLC's using larger chip feature sizes could run in the 10000+ range). The wear indicator will probably hit zero somewhere between 1000 and 2000 erase cycles (over the full drive). It's usually conservative so it might indicate zero after ~1000 erase cycles or so but it depends, but usually the drive can continue to be written to well past 2000 erase cycles.
However, if you continue to write significantly to the drive after the wear counter reaches zero then you risk catastrophic failure above and beyond what the vendor nominally targets. Cells can wind up going bad and causing massive corruption past a certain point if left to sit a while, even if the last write & verify succeeded.
-Matt
There is a lot of misinformation on SSD failure modes, mostly because people ignore what SMART tells them and run their SSDs into the ground before replacing them.
Basically it comes down to this... The drive has a pretty good idea of how worn-down the flash chips get. It will count-down the wear indicator (from SMART) from 100 to 0. At the point it reaches 0 the drive can no longer guarantee nominal operations.
If you continue writing to the drive AFTER the wear indicator has reached 0 then you CAN have catastrophic failure situations. The more you write to the drive after that point, the more likely it will happen. In many cases you can write 2x or more the amount you wrote to get from 100 to 0 and the drive will work fine, which is why people tend to ignore the wear indicator after it has hit 0. But the drive just can't guarantee that data integrity will be within reason after the wear indicator hits 0.
If you replace the drive when the wear indicator has reached zero then you are far less likely to get a catastrophic failure. Sure they can still happen... failures are not intentionally created by the drive firmware after all. But if you use the wear indicator properly you can mitigate the catastrophic failure cases by at least an order of magnitude (and probably better).
It's that simple.
--
It is also true that there have been many firmware bugs over the years. SSDs at these capacities are fairly new beasts after all. There are dozens and dozens of SSD brands (though really only three major controller chipsets). Firmware is where the differences are. The only two vendors *I* trust are Crucial and Intel and that is it... I trust them because they are clearly staying on top of their firmware upgrades.
Even with the firmware bugs I know exist on my oldest SSDs (Intel 40Grs), I haven't had any failures. In fact, at this point I have at least 30 SSDs in operation and have yet to actually see any honest-to-god failures. I am certainly more confident of newer models (for Intel and Crucial anyhow) than older ones. Firmware might have a few hicups here and there as time passes but it will generally just get better and better. Judging a current deployment based on 5-year-old distrust is stupid.
-Matt
I think you're a bit confused over how normal filesystem operations are cached on a modern OS (e.g. OS X, Linux, BSDs, Solaris, etc). Even normal log writing (whether you run it through a compression program or not) on a normal non-SSD-aware filesystem is not going to result in tiny little writes to the SSD. The writes will simply wind up in the buffer cache (or equivalent) and get flushed to media when the filesystem syncer comes around every 30-60 seconds or so. The most highly fragmented case in this situation might require the SSD to flush a 128KB a dozen times each 60 seconds which doesn't even remotely wear it out. Only a complete idiot tries to fsync() a log file on each line, so baring that ... it isn't an issue.
I've heard this complaint many times over the years and not one person has EVER provided any factual information as to what and how much and how often they are actually writing to the SSD. Not once.
The amount of data being written is always an issue with a SSD, but if it's being permanently stored it actually isn't the issue you think it is because the equivalent cost of storage for archival data is actually better with a SSD simply due to the SSD in write-once situation lasting forever (maybe rewrite a full drive once every 5 years or so to refresh the cells x ~1000-3000 rewrites). The SSD will easily last 25 years or longer (probably until the firmware itself degrades), whereas a HDD has to be replaced every 3-5 years whether it's off, idle, or doing work. SSDs are great for archiving stuff. They take virtually no energy when idle and can simply be left attached and powered and the only real wear occurs when you write.
For temporarily staged data... this is probably a SSDs one issue. There is a wear limit after all, so constantly rewriting the drive at a high rate will wear it out. But this is also a problem with an easy solution... since such data is usually laid down linearly and processed linearly, HDDs are still useful as a storage medium. Simpler staging of temporary data doesn't even have to use ANY media if the data trivially fits in ram... you just use a tmpfs mount and schedule a job to process the data at reasonable intervals.
In terms of swap, again you appear to be confused. Simply placing swap on a SSD is not going to wear it out. It depends heavily on how much the OS actually pages data in and out. In most consumer/home-system situations the answer will be 'not often' (relative to the SSD's wear limit). In a server situation swap is not written to under normal operating conditions at all unless someone made a major mistake. It's just there to handle DOS attacks and burst situations in order to allow the system to be tuned to utilize all of its resources as fully as possible.
For example, again a 'tmpfs' (memory filesystem) which is backed by swap can actually be VERY write-efficient since the OS isn't going to flush it to its backing media unless the system is actually under memory pressure. If one schedules things such that the system is not normally under memory pressure (which is a typical case for a server installation), then the SSD won't be worn out... but it will be available for those situations that happen every once in a while that really need it.
Oh well, I don't expect much from Slashdot posters anyway. But, honestly, these things should be obvious to people by now.
-Matt
That's a joke, right? You actually believe Bitcoin is accepted and trusted by merchants? You can count the number of serious businesses trying to use bitcoin on one hand. Walmart's virtual currency is already used in far more transactions than Bitcoin ever will be.
You are staring at pretty numbers on a screen and have absolutely no sense of scale.
And as far as credit cards go, the space is getting pretty crowded already with Yahoo, Google, and others pushing into the space (after realizing that wallet apps are pretty useless without them). Lets see someone due monetary conversions to a bitcoin account with a credit card and see how long it takes them to either go bankrupt or be forced to charged significant fees to stay in business.
Bitcoin has no advantage whatsoever as a first-mover when the 'currency' is too unstable to actually be usable in the wider world of commerce.
-Matt
Why would the world population want to do that when they could be using BTC2 or BTC3 or ... BTC (each with a slight tweek of the algorithm) instead?
There are tons of virtual currencies already in existence, and no barrier to entry for creating more (including no barrier to entry for creating clones of Bitcoin that use a different cryptographic base).
-Matt
It costs me $0 to transfer dollars to relatives electronically, bank-to-bank. No fees at all.
Also, perhaps you are unaware, but Western Union has been losing business for two decades now. Many immigrants now send money home by opening a bank account and mailing a physical ATM card to their relatives, which can cost as little as $0 if the relatives withdrawal the cash in $ (which many can), and can be as little as 1% if a currency conversion is involved.
Even using a non-network ATM typically has a fixed charge, e.g. $3/$300 = 1% charge to get a hard currency in one's pocket.
Bitcoin cannot do better (people who think they can transfer BTC for free are ignoring both the exchange spreads and the time/volatility factor).
-Matt
This mechanism is no guarantee that the seller will actually get the price they programmed in. In a crash there is not likely going to be a buyer at or above the programmed-in price and the seller can't force counter-parties to buy BTC (or anything) at the desired price.
In fact this mechanism exists in the real stock market and is manipulated all the time by contrived flash crashes to force those sell points to get hit. Since the price crashes through the sell levels so quickly there are no buyers at those prices and the sales wind up going at the market and forcing the stock down even more. Even worse, enough people using this sort of mechanism can CAUSE computer-driven crashes and lose their shirts in the process.
Unlike something like Bitcoin, stocks actually do have a real intrinsic value (even if investors can't calculate it with any accuracy). Which means that you can't sell a stock into oblivion and expect it to stay there very long. In the case of flash crashes, sometimes seconds, up to a few minutes at best. People who use these sorts of orders can wind up with sold positions and a stock price that has recovered before they can react and then they are screwed.
-Matt
You've hit upon the basic mechanism but you haven't taken the next logical step. The issue is what happens when the pricing goes exponential (as it has, twice now).
What happens is that people who 'break even' almost universally go back into the market with more than just the house's money. Because the value is appreciating non-linearly, going back into the market almost always means spending far more money buying back in than you ever got out before that point.
For example, people who cashed out when it was hitting $250 a few months ago are now kicking themselves. In order to buy back in, they have to spend every last drop of their previous profits plus more to obtain a 'reasonable' speculative position at the new price.
This also points to how people's view of money shifts as the market rises, particularly people who have never had a lot of money or have never handled large sums or volumes of money (via their jobs or otherwise)... basically the definition of a 'sucker'. As long as they think they are making money, it becomes like a game of monopoly. In the first round someone who made a few $hundred thought they did really well. In the second round those few $hundred feel like chump change... it takes a few $thousand to really feel that you did well.
Well, it doesn't stop there. It keeps scaling up. In the third round a person might feel that a few $tens-of-thousands is necessary to do well and that a measily few $thousand is chump change. It keeps scaling up until a person either runs out of cash or runs out of borrowing capacity... the mindset continues to scale all the way until the whole thing comes crashing down.
That's why you wind up with people bankrupted instead of people being happy that they had fun playing with the house's money after the first round or two.
There are certainly a few smart people in the Bitcoin market who know how to extract actual profit from the trading. It mostly comes down to understanding the scaling effect and NOT being tricked by it (not scaling up the investment in each successive round by more than 1/2 the profit from the previous round). There are numerous well-known methodologies and I'm certain a small but significant percentage of Bitcoin traders are doing precisely that.
People doing the above scheme are the smart ones. They are draining hard money (real dollars) from the exchange against everyone else who is continuing to lever up. In the end, real money has been removed from the exchange while the remaining participants are basically just playing musical chairs with each other. When the eventual panic occurs there is simply not enough cash left with the exchange participants to cover everyone and the value crashes into oblivion.
This is how it will play out. It is ALWAYS how it plays out. Bitcoin is not going to be an exception.
-Matt
VISA is more like 1% (or less) for anyone doing real volume. Small businesses have plenty of choices for credit card transactions... even Apple is getting into the game. And besides, if you want to compare Bitcoin transaction costs against something you should be comparing against something like PayPal, not VISA.
For bitcoin on either Mt Gox or coinbase, the bid/ask spread *alone* for a small transaction is ~0.5% or so, and exceeds 1% for the types of volumes a small business would have (and that is only just recently. Just a few days ago the spread was easily over 2%). That's just the bid/ask spread, never mind any other fees.
Anyone who thinks they are doing bitcoin transactions for 'free' is smoking something.
What we have here are a whole lot of people so fixated on the hype they don't realize just how much they are getting milked.
-Matt
Maybe several million dollars when purchased new, but pretty much all computing equipment depreciates to near worthlessness over a few years, not to mention the cost of power. So if you are trying to argue that bitcoin has something physical backing it then it kinda falls on its face.
Nobody in their right mind can argue that Bitcoin is a usable currency. Currencies have to be relatively stable in the short-term. Bitcoin obviously isn't even remotely stable. Not only is it not stable, but it has no mechanisms at all to make it stable.
It's the classic (and obvious) hording / tulip-mania mechanic and I think most investors know this, but greed still rules until the day the whole thing comes crashing down around people's ears.
-Matt
I've read the space map work but there are several issues that make them impractical for H2. The main one is that H2 snapshots are read-write (ZFS snapshots are read-only). Secondarily, my experience from H1 is that any complicated ref-counting or space accounting can lead to hidden corruption. Even if we assumed that the media data validation mechanism (a CRC or cryptographic hash) detects all media issues, there is still the problem of software complexity introducing bugs at a higher level.
So H2 is going to use a relatively simple freemap mechanism. In fact, it is using the same dynamic radix tree for the freemap as it does for the file and directory topology. It will still roll-up tiny allocations into a somewhat chunkier granularity to reduce freemap overhead (similar to what H1 did but at a finer 1KB grain vs H1's 2MB granularity), and it will roll-up space availability hints and propagate them up the tree. And it is type-aware so it can do things like collect inode allocations together for burstability. It isn't trivialized. But it does not attempt to implement ref-counting or any complex sub-topology to keep track of who and how many own which blocks.
The actual block freeing is going to be done in the background rather than in the 'rm' path (for a COW filesystem with snapshots which are actually used regularly, there's no point trying to free blocks in real time). This will allow H2 to implement several major features such as de-duplication, writable snapshots, and so forth with far less software complexity. So the complexity of the block allocation and any block duplication becomes trivialized while the complexity of the block freeing code increases. But it's an incrementally solvable problem. I can start with a brute-force memory-bounded scan and slowly add optimizations to recognize duplication in the topology, add topology hints to improve the efficiency of the block freeing scan, and so forth.
-Matt
This release removes almost all the remaining SMP contention from both critical paths and most common paths. The work continued past the release in the master branch (some additional things which were too complex too test in time for the release). For all intents and purposes the master branch no longer has any SMP contention for anything other than modifying filesystem operations (such as concurrent writing to the same file). And even those sorts of operations are mostly contention free due to the buffer cache and namecache layers.
Generally speaking what this means is that for smaller 8-core systems what contention there was mostly disappeared one or two releases ago, but larger (e.g. 48-core) systems still had significant contention when many cores were heavily resource-shared. This release and the work now in the master branch basically removes the remaining contention on the larger multi-core systems, greatly improving their scaling and efficiency.
A full bulk build on our 48-core opteron box took several days a year ago. Today it takes only 14.5 hours to build the almost 21000 packages in the FreeBSD ports tree. These weren't minor improvements.
Where it matters the most are with heavily shared resources, for example when one is doing a bulk build on a large multi-core system which is constantly fork/exec'ing, running dozens of the same process concurrently. /bin/sh, make, cc1[plus], and so on (a common scenario for any bulk building system), and when accessing heavily shared cached filesystem data (a very common scenario for web servers). Under these conditions there can be hundreds of thousands of path lookups per second and over a million VM faults per second. Even a single exclusive lock in these paths can destroy performance on systems with more than 8 cores. Both the simpler case where a program such as /bin/sh or cc1 is concurrently fork/exec'd thousands to tens of thousands of times per second and the more complex case where sub-shells are used for parallelism (fork without exec)... these cases no longer contend at all.
Other paths also had to be cleaned up. Process forking requires significant pid-handling interactions to allocate PIDs concurrently, and exec's pretty much require that locks be fine-grained all the way down to the page level (and then shared at the page level) to handle the concurrent VM faults. The process table, buffer cache, and several other major subsystems were rewritten to convert global tables into effectively per-cpu tables. One lock would get 'fixed' and reveal three others that still needed work. Eventually everything was fixed.
Similarly, network paths have been optimized to the point where a server configuration can process hundreds of thousands of tcp connections per second and we can get full utilization of 10GigE nics.
And filesystem paths have been optimized greatly as well, though we'll have to wait for HAMMER2 to finish that work for modifying filesystem calls to reap the real rewards from that.
There are still a few network paths, primarily related to filtering (PF) that are serialized and need to be rewritten, but that and the next gen filesystem are the only big ticket items left in the entire system insofar as SMP goes.
Well, the last problem, at least until we tackle the next big issue. There's still cache coherency bus traffic which occurs even when e.g. a shared lock is non-contended. The code-base is now at the point where we could probably drop-in the new Intel transactional instructions and prefixes and get real gains (again, only applicable to multi-chip/multi-core solutions, not simple 8-thread systems). It should be possible to bump fork/exec and VM fault performance on shared resources from their current very high levels right on through the stratosphere and into deep space. Maybe I'll make a GSOC out of it next year.
The filesystem work on HAMMER2 (the filesystem successor to HAMMER1) continues to progress but it wasn't ready for even an early alpha
DDR3 (dram in general) can burst quickly but full random accesses are very slow in comparison.
-Matt
With Intel's 14nm so close, and 10nm production in another year or so, they need to use all that chip area for something that doesn't necessarily generate a ton of heat. RAM is the perfect thing. Not only is the power consumption relatively disconnected from the size and density of the cache, but not having to go off-chip for a majority of memory operations means that the external dynamic ram can probably go into power savings mode for most of its life, reducing the overall power consumption of the device.
-Matt
Happens to me all the time on ALL my android devices. Totally non-deterministic. Sometimes my Nexus 7 (2012) can sit with the display turned off for several days without losing too much battery, other times I turn it off (display off) and it discharges overnight and is dead in the morning. Happens to both my android phones too. I'm not forgetting to turn off Pandora either.
Sometimes my phone is 'hot' just sitting in my pocket with the screen off. Sometimes it is 'cold'. When it's hot it's obviously eating power doing something, despite the display being turned off. It's totally random when this happens... usually the longer I leave the phone between reboots the more likely it is to get into that state. VERY annoying. NO services are running (nothing in the service bar at the top). Doesn't matter. Still random hot or cold.
Doesn't happen to any of my Apple devices. If I leave an Apple device turned off (sleep mode that is), it retains its battery level and drains at a very slow and highly deterministic rate. If I turn off my iPhone (and I'm not playing music on it), it goes to sleep. Always.
Honestly I don't understand why Google thinks this is ok. It's an obvious competitive advantage for Apple when its devices don't kill their battery and Android devices do.
-Matt
No no, resistance has nothing to do with it. The USB charger's output is current limited, which means that if the device tries to pull more current than the charger is programmed for, the charger's output voltage will drop. That is, the output will be limited to (for example) 500mA or 1A or 1.5A or whatever and if the device tries to pull more the output will STILL be limited to that value and the voltage will drop from 5V to compensate.
Smart devices can usually ignore the USB resistor-based programming pins (which run to different standards) and simply pull the charger's output down from 5V to 4V or something like that and measure the current (up to a reasonable limit managed by the device, of course), and figure out how much they can pull from the charger based on that.
Stupid devices will either not probe what the charger can actually do or will make assumptions based on the resistor-programmed pins (the one that has multiple standards) and not be able to handle the case where they guess wrong and crow-bar the charger's output by trying to pull too much current.
None of this has anything to do with the resistance of the wires inside or outside the charger.
-Matt
Two-prong chargers just synthesize a ground. Well, there are two grounds actually... one for the AC side and one for the output side. On the AC side its the average of the AC sine wave between the two prongs taken off the middle of the rectifier. The charger's output is traditionally isolated with a transformer (a small transformer on the output of the switching power supply instead of a big one on the input), which isolates the output and also handles the flyback function for the switching power supply. The feedback circuit is traditionally isolated with an opto-isolator.
So the output side's ground is separate and isolated from the input side's synthesized ground. Which means that the output's ground will float to whatever it is connected to (which is what you want it to do).
The difference between the input side's ground (which is completely internal to the charger) and the output side's ground (which is exposed via the USB connector) is called the common-mode voltage differential. Obviously there are limitations since too much of a differential between the two grounds will cause arcing crossing the physical gap and/or transformer insulation. Most circuits are designed with insulation and gaps large enough to handle at least 600V of common mode.
(Common mode can be experienced directly by touching the 'ground' of a coax cable from your cable provider or touching phone wires whos 'ground' is the C.O. several miles away. The tingling you are feeling is anywhere from 60V to ~300V of common mode difference between the ground where the signal was generated and the ground your body has floated to... typically closer to the ground that your home is anchored to).
-Matt
What's happening there is that the phone is crow-baring the charger down to under 2V and then mis-interpreting its own voltage sensor (on the phone) thinking that the charger is connecting and disconnecting. Might also be tripping the short-circuit detector on the charger and causing it to cycle.
That's a problem with the phone. No phone should crow-bar the 5V the USB outlet provides, particularly not one that outputs >1A. (This is using your description of the charger being hot). All USB power sources are current-limited and the devices being charged have to deal with that properly.
-Matt
I have a multitude of Apple and Android devices and a multitude of Apple and non-Apple usb chargers and power sources, and also have a little non-Apple dongle charger in the car in the front.
It all works just fine. Apple might have weird charging cables but they still have usb on one end and they've worked with the dozen or so different usb charging sources I've got in the house and in the car.
Most USB chargers only throw out 2-5W. It's gonna take a while to charge-up Apple's big batteries with one of those but it will still work just fine.
-Matt