If you're running Firefox 3.5 or Safari 4, take a look at the "benchmark"/technology demo I just put up. [Safari 4 compatibility added based upon the great comment submitted by Oliver]
It's a modified variant of the SunSpider benchmark that I've written about before (in less than flattering terms), which I heavily altered to utilize the remarkable new Web Worker functionality you can now explore in Firefox 3.5. If you're really analyzing performance, be sure to disable Firebug as it significantly impacts the results.
Web Workers, a standardization of a feature of Google Gears, are a remarkably simple method of multi-threading JavaScript, not just to get it out of the UI thread — where it can be very detrimental to the user experience as the interface freezes while a script runs — but also to scale across multiple CPUs and cores on modern PCs, which while seemingly a ridiculous notion ("but it's just JavaScript! Multithreading?") is becoming a real concern as the JavaScript engines continue to advance and the usage and scope of the language and related technologies continue to expand.
Through a simple, synchronized message passing system and a minimalist API, the Web Workers model lends itself to robust, elegant code that isn't as prone to classic multi-threading pitfalls. While not a part of the current instantiations, in a theoretical implementation there is no reason why web workers couldn't be located on entirely different machines, given that each worker is essentially an isolated runtime, sharing very little (the navigator properties and some basic security info for things like enforcing XmlHttp restrictions), communicating via serialized messages.
The benchmark/technology demo is operational in Chrome, Opera, and Internet Explorer, but only if you change Web Workers to 0. In that case it is sequentially running the set of tests in the main thread, as JavaScript has traditionally been run. I didn't intend for this to be used for cross-browser comparisons, even if I resort to presenting just such a comparison at the end of this entry, and instead the focus is really on the technology, so the real "power" is seen once you start to turn up the web worker dial, all the way to 11.
Web worker multithreading isn't limited to Firefox 3.5. Oliver left a comment pointing to a Safari-ready variant he threw up, so I modified the test accordingly (the difference being that when Safari implemented it, it didn't intrinsically include JSON encoding, so your caller and receiver had to do that themselves). I didn't realize that Safari had covered this ground, though it isn't shocking given how rapidly that browser has been advancing.
With one web worker, the UI remains fully responsive to user interaction, which is an experience quite unlike what was seen at 0 (where the browser essentially locks up during the run), and the actual run itself suffers little for the isolation. On a quad-core CPU, the CPU usage during the duration of the test cycle fluctuates around approximately 25%.
At two web workers, the individual tests take slightly longer to run, however the actual completion and pace of the tests in the whole is greatly improved. Not quite a halving of the runtime, but not too far off. Two cores are saturated during the duration of the test.
At three web workers, three of the cores are filled with work, and the total elapsed time improves somewhat, albeit not by the ratio that correlates with the 50% increase in computation power.
At four web workers, we've tapped out the parallelism and despite all four cores being saturated for most of the duration, the total runtime actually suffers slightly. Going above four doesn't cost much, but it also brings no real gain (beyond possible algorithm gain isolated various parts of the application).
You can also run a mode where instead of running a modified js directly in the worker thread, the code is passed as a string parameter, eval'd into a function reference, and the function is run. There are some interesting observations to be observed by this test, such as the lack of tracemonkey loop optimizations on eval'd code (see bitwise-and in particular. It suffers dramatically when run as an eval'd function relative to running as literal JavaScript). This surprised me as the eval merely instantiates a function in the current context, but doesn't run it, yet the performance penalty remains because it was sourced from an eval.
Here are some results for 1-8 threads, running 10 cycles of each test, gathering the total elapsed time in Safari 4 and Firefox 3.5 RC2. This was run on a quad-core Q9400 machine, and of course your mileage will vary. While it is evident that Firefox 3.5 is using more of the available processing power as you move past 1 thread, with it increasing from 25%, 50%, 75%, to 100% at 1, 2, 3, and 4 threads respectively, it doesn't fully benefit from the additional resources, yielding a greatly diminished rate of return. Safari, on the other hand, already started with a considerable lead, and it pulled away with each thread up to the optimal 4, really hitting its stride.
I'll add some charts and the like to this entry later, but just thought I'd drop a line on that demo of a very promising technology that will soon see fairly robust deploymet (one huge benefit of Firefox -- shared by Chrome and Opera -- is that the uptake rate for new versions is extremely high).
This entry is just a lead-in to the next entry that'll be about an exciting technology in Firefox 3.5. I didn't want to bloat up that entry with my parentheticals and rants, so just wanted to get that out of the way here.
Have you tried out Firefox 3.5 yet? It’ll happily install side-by-side, so there’s very little risk giving it a spin.
While currently a Release Candidate, it is already supported by most popular add-ins, such as Firebug and Adblock Plus, and brings a bounty of new functionality, more comprehensive emerging standards support, all while improving performance.
Performance has never been Firefox’s strong suit. While some incorrectly believe that Firefox has just recently been overtaken by upstarts like Webkit and its bastard child Chrome – the lore being that Firefox’s creaky “old” legacy code is not as nimble as the newer projects – the truth is that Firefox has always been a performance laggard compared to all but Internet Explorer.
It has always used more memory, done things more slowly, with benchmarking and resource consumption metrics that seldom earned it praise. The history of Firefox (aka Mozilla Suite, Phoenix and Firebird) is a tortured legacy littered with complaints about slow start-up times, a slow page layout engine, massive memory consumption, and middling JavaScript performance.
These are the costs of building on the XUL abstraction, along with some expensive add-on scaffolding. The ability for an add-on to dramatically change the behaviour of the browser (all from within a world of JavaScript and chrome) isn’t just an accidental happenchance, but instead is the result of considered, pervasive design choices.
If a small footprint and snappy response were the keys to success, Opera would have taken the market by storm given that it’s been evangelizing and focusing on that pursuit, to a great degree of technical success and leadership, for well over a decade now. Yet most users care more about a slightly better bookmark manager than they do about even magnitude differences in JavaScript performance.
But performance does matter. As web applications grow richer and more elaborate, the weakest of the contenders will get pushed out of the race. Already web applications like Slashdot and Facebook are getting unpleasant with a few of the current contenders, yet some of the new features of standards like HTML 5 promise dramatic new functionality that will completely blow the top off of the domain restrictions of the browser world.
So with recent releases the Firefox crew has reduced the toll you have to pay for these architectural choices, and through a lot of hard work it’s getting to be a memory lightweight, as far as web browsers go, and performance has improved across the board, sometimes dramatically.
And to sidetrack for a moment about a personal peeve, let me kick down the frequent whiners’ complaint that it’s “just a web browser”. Every time someone make such an ignorant, misinformed statement -- usually during some entitled complaint about resource consumption on their obsolete PC -- I think a universe blinks out of existence in some alternate reality.
There is very likely nothing that you do on your PC that is as rich and complex as the things that you’re doing right now just browsing the web. It’s isn’t “just a web browser”, it should be “I can’t believe how much is happening for me to loll around on the web for a bit!”.
It’s hard to believe that Slashdot has been around for over a decade.
Taking a couple of paragraphs to reminisce, I signed up for a Slashdot account not long after the site opened for business. Following my normal tradition at the time, I suffixed my newly created account with the two-digit year of creation, in that case 98. It was an easy way to choose account names that were less likely to be rejected as already in use.
I didn't imagine that I'd be using the same account over a decade later, so now I have a nick that makes me look like I’m pretending to be an eleven year old (if you ignore the 4-digit user ID, it is conceivable that an eleven year old might visit Slashdot).
I didn’t join the ranks of Slashdot to cheerlead Linux and open source, despite it being the overwhelming direction of the site at the time.
My intentions were much less idealistic.
I actually signed up to troll a co-worker: a
Linux-loving long-haired hippy named Warren Postma.
The guy was always going on about the greatness of open source software and the
related initiatives, about the evils of Microsoft and closed-source, and so on, and
of course he was an early fan of Slashdot.
[Over time I came to appreciate that much of what he had to say was right on the money, and in reality he was one of the best developers I’ve had the pleasure of working with.
And he wasn’t really long-haired or a hippy, though maybe my perception imagined him that way at the time, what with all the free-software rhetoric]
That was an era when being up on the latest meme was a lot more difficult, so a site like Slashdot was a welcome source, allowing you to knowingly declare that you'd already seen the dancing baby when a less-connected co-worker gets it emailed to them and comes over acting all connected-like. Though to be fair Slashdot came a little late to give a heads up of the dancing baby craze, but it was there for All Your Base Natalie Portman hot grits, though along the way to enlightment came some less appealing memes involving tubs and goats.
Slashdot no longer fills the industry-dominating position that it once did (where being "Slashdotted" was a term used in the mainstream press) — I suspect it has more to do with its competitors pandering to the common, all degrading eventually to funny pictures, "facepalms" and non-stop political posturing and claims of oppression, with sites like Digg and later Reddit escaping from the technology ghetto, while Slashdot remained chained to its original niche — but it often still has interesting and elucidating discussions throughout its comments, even if the UI of the site continues to grow worse with every passing month. Seriously, guys, the endless page thing was demonstrastably lame on DZone, so why did you think it was a good idea?
So during a moment of mental relaxation yesterday I thought I’d see what was up in the world of /., where the top story at the time detailed a congressman’s bill to “Ban ISP caps”. I found the submission hard to believe, so I RTFA to find that it had been very poorly interpreted.
What the congressman really proposed is more of a fee oversight body similar to those that many utilities have to work within.
Here in Canada the monopoly phone companies, for instance,
have to apply to the CRTC every time they want to change fees (whether to
increase or decrease) or service levels, justifying why they need to make those
changes. Of course they’ve always been grotesquely profitable, and seldom get
denied their desires (except, humorously, when it came to reducing fees to
compete better against new upstarts), but just pretend that such bureaucracies make
them more competitive or accountable or economical or something.
So I posted a comment saying that the summary was inaccurate. I also tossed in a little aside about utilities, drawing from the congressman and the submission’s analogy comparing ISPs with utilities, speculating that soon ISPs might just switch to a pure consumption model more analogous with the utilities that they are being compared to, saying "I don't get carte blanche from the electric company to use it all for free, complaining that "they provide 20A to the house so I should be able to use 20A around the clock for free!"."
I touched a sore spot, which I have to confess to doing intentionally. Sometimes I can’t help but troll a bit, and given that it’s a pretty common position on sites like Slashdot that it is a basic human right to torrent a pipe full around the clock, I thought I’d pick that scab a bit.
I got the typical “the bits are free and the man is just keeping us down.” variety of responses, including my favourite.
Anyone who is comparing ISPs and bandwidth to other utilities such as electricity, water, or anything tangible should simply stop posting… immediately. The Internet is not a series of tubes, your comparisons are invalid, and you are ignorant.
Please cease in the proliferation of these ludicrous analogies.
Ignoring that the utility analogy came directly from the congressman himself, this comment has made me personally invested in this spurious analogy, so now I must embrace it with vigour.
And, for that matter, the internet is effectively a series of tubes, as fun as it might have been to point and laugh at Mr. Stevens. Those tubes have a finite capacity, and if you want to push more through, you have to lay more or “wider” tubes.
Conceptually it isn’t all that different from a power or water network, where many of the same circuit principals apply.
And those “tubes” didn’t magically appear from nowhere. They aren’t public infrastructure. The internet isn’t free. Bandwidth isn’t free. Throughput isn’t free. All of it costs money to lay and service, and as demands grow, there is the capital required to increase capacity.
So let’s go back to the electricity analogy (even though I had no intention to draw it out so literally, I’m invested now).
Back to the responses again, a less stupid one said:
The total amount of power you use in a month directly affects the amount of fuel a power utility has to burn, or the amount of water you consumer affects how much water the utility has to treat. Bits on a connection aren't like that. If you don't use a bit on their fibre link to the backbone, that doesn't leave them with an extra bit, and if you use a bit, the next one is coming at the same time and same cost anyway.
Fair point. When you use electricity, the variable costs increase. When you use water they have to buy a little more chlorine and pay the electric company to run the pumps.
Yet here in Ontario most of my electricity comes from either hydro-electric (our power company was historically called “Ontario Hydro”, causing confusion for decades as children tried to understand why the power company was effectively named Ontario Water), or nuclear.
The variable costs with either are a small percentage of the total cost to operate those services, and instead the vast majority of the cost comes in the form of capital expenditure – what they had to build and maintain to handle the current load, and to handle tomorrow’s load.
Most of the “conservation” efforts – incremental and accelerated fees for heavy consumers, and rebates for power saving appliances and technologies — have been aimed at avoiding exceeding the gross capacity of the system right now, because the next step will cost billions, and it’s not to buy a few more fuel rods.
Nuclear power plants and giant dam projects don’t come cheap; nor does building a water purification system to service a city of 200,000. It’s one of those perverse situations where if demand dropped significantly, they’d actually have to increase costs.
To wring every last bit of ridiculousness out of this analogy, imagine that you live in a village of 100 people and @Tesla just twittered about a cool new tech called electricity.
Hyped about the latest fad, you get a bank loan and put up a wind generator, connecting it to anyone willing to pay an even split of the costs (a loan you amortized to get paid off just as the turbine needs replacement, plus basic maintenance and upkeep).
Your new turbine is spinning around the clock (it’s a very windy valley near the ocean), putting out a constant 100kW, and everyone is enjoying their 1kW space heater, all paying their 1/100th cost.
Every now and then someone turns on a hairdryer, but it balances out because other people sometimes turn off their space heater, and in the end the load can be handled due to its natural distribution.
But then someone decides that they’d also like to run their 5kW back massager around the clock – you did say that electricity could be used around the clock, and the wind is free, right? — so they crank it up and your system starts to suffer brownouts and everyone suffers.
You face some tough choices: You can either put a 1kW limit on everyone (“dedicated” capacity), which would be unfortunate given that most of your customers benefit from sporadically spiking their load while they use their motorized hair curler, or you can start charging or limiting only the outliers, maybe targeting the growing trend of back massagers specifically, putting limiters on that specific use of your power.
Or you can add capacity.
So you decide to do the latter in the most cost-effective way, arranging a power sharing agreement with a neighbouring village: When you have left over capacity you send it to them, and they do the same in return.
It all balances out, and everything is fine in the world again, and that one customer gets to enjoy his back massager, essentially freeloading on the standard customer load.
But then another user decides that he, too, might as well get a back massager. And then another. And then another.
The neighbouring village starts rethinking the power sharing agreement because it is no longer serving both partners equally. They demand either payment for their inconvenience, or they’re going to sever the line.
So now, despite the fact that there is “no cost” for each incremental kW, the village is faced with a massive capital (or loan servicing) cost of putting up another wind turbine.
This is grossly simplified, as analogies often are (and there are countless similar scenarios, from toll roads to bridges to movie rentals…this is like beginner economics, but so many are so blissfully ignorant of it), but there are a lot of parallels with internet backbones, where end-users are getting 10Mbps connections to a grossly oversold network at a heavily discounted price. Any delusion that there’s some 10Mbps dedicated channel available for every subscriber is absurd. Go and buy a commercial dedicated T1 at 1/6th the speed and see how the pricing stacks up.
Consider that my little suburban town has about 50,000 high speed customers, all with 10Mbps service. If we all used our throughput, this single town would be a 400Gbps load on the network. Try laying a 400Gbps city wide network, much less province wide, much less country wide, much less continent wide, much less…that is an enormously expensive proposition.
This is the reality of the internet today. Maybe the backbones should be a public bit of infrastructure, with massive, limitless pipes from coast to coast, but that isn’t currently the case. If people want to argue for that – I think a next generation, coast-to-coast Canada backbone would be a great project for some of those stimulus billions — then they should argue for that.
Things are getting better. There are billions of dollars constantly being spent improving the backbone of the net (YouTube and Hulu today alone today account for more traffic than the entire backbone could handle in 2000), and I’m sure in a few years we’ll all being using our 1Gbps connections to play a live-streamed 1080p never-obsolete video game system.
I have no desire to defend ISPs, or to support some of the various tactics they have pursued (traffic shaping, for instance, is not at all justifiable, nor should a carrier care or restrict which sites you visit, trying to monetize the fact that you visit Hulu, or trying to extort Google. Restrict or charge based on the throughput, not specific uses of it that should be none of your concern), but some of the rhetoric on this topic is just so absurdly ridiculous, and can only be drawn from the delusions of self-serving fantasy.
The denial of the reality of overselling and fair use is how we end up with traffic shaping, or stupid constraints like cellular carriers refusing to allow uses like tethering (which is because they rely upon most of their customers not using their "alloted" throughput, and tethering would completely throw off that assumption. I'd rather they base all of it around actual usage and cease trying to indirectly massage usage through unnecessary secondary restrictions and throttles.
The standard tripe about how one’s usage somehow only ever uses excess capacity (is there some “only if available” NoQuality-of-Service bit?), where people assume that their actions somehow exist in a vacuum of inconsequence, unbound by the limits or constraints of anyone else, offends common sense.
Update: This case has purportedly had a tragic, very sad outcome. From the little the police have released — they have been extremely tight-lipped — it sounds like the grainy couple of frames from the high school camera up the street were the roots of this entire case (which led them to a suspect, who then led them to a Home Depot video from a city 70km away), without which...who knows where they would be today, or how many more victims the culprits would have claimed. I remain more convinced than ever of the incredible value of pervasive, decentralized monitoring.
Eight year old Victoria Stafford went missing from the nearby town of Woodstock on April 8th. She had left her school at the end of the day, starting the short walk home alone, but purportedly never made it.
Video from a high school up the street (see the enhanced version as well), discovered the next day, shows Victoria walking with a thus far unidentified female (a sketch, purportedly based upon a witness account, has been released. Given the sudden appearance of this supposed witness account two weeks later, it seems to be an attempt by the police to put a little pressure on a suspect to see if they break or make a panicky misstep).
The town in question, Woodstock, Ontario, sits on a major highway that goes from Windsor to Toronto and Montreal and beyond, with a nearby branch going to the Buffalo area. It seems noteworthy that Victoria’s public school is a very short distance from an onramp.
I find this case distressing. These things generally don’t turn out well.
Whether the abduction is real or not (there’s a general cynicism about cases like this because of vile, murderous sociopaths creating a cry wolf situation, leading many to automatically disbelieve), it usually forebodes very bad things.
Of all of the video cameras that blanket our society, the best they’ve got — at least that they’ve publicly announced — is the single grainy video from the high school (see the graphic I made of approximately the zone covered by this video, as determined by correlating landmarks with satellite imagery.) There were lots of people around, but history has shown time and time again that people are really, really terrible witnesses of anything, and that seemed to have held true in this case.
Who is the woman in the video? Apparently no one knows.
This has me thinking about pervasive, distributed monitoring. Where in time of need – like an incident like this (yes, “think of the children”) – swarm media and electronic capture can be combined to zero in on the truth. Preferrably in a way that utilizes the enormous talent and load distribution of the public.
High definition video capture is becoming dirt cheap. Solid state storage is rapidly evolving.
I’m not talking about the Big Brother 1984-style of central government monitoring, with the endless pitfalls and abuses that entails, but rather a situation where almost incidentally most everything is recorded by the public using a distributed array of devices.
It seems inevitable, for instance, that in just a few years every car on the road will have forward and rear facing cameras. The former is already in place on most police vehicles (helping to keep police in line as much as to capture public malfeasance), and the latter is making inroads on large vehicles that are prone to backing over people and things.
Video retention will inevitably come next, under the auspices of road safety (similar to how your car is ready and willing to rat on you for speeding if you get in an accident). Soon it won’t be an option, but will be a legal requirement for using the roads.
“Sorry, bub, but your car’s video system clearly shows you blowing through that red light. The other guy’s video system shows that he was in the right.”
99.999% of the time the video loops over and is erased and inconsequential and irrelevant, but every now and then it serves an important purpose in getting to the truth.
Imagine, for instance, that they could put out a call for anyone who drove down that street or that neighbourhood in the time period in question (presuming they don't already know from telemetrics via systems like OnStar, again soon to be the legal norm as every road becomes a toll road with vehicle self-reporting), from which they got a number of different time and position videos.
Videos of vehicles parked in the vicinity. Of the woman in the white coat waiting.
Add the video capture on private buildings of all sorts (homes, businesses, parking lots, etc). Merge it all together into a exhaustively documented, fact-based accounting of what happened.
Cellphones of course play a part as well.
SELECT subscriber_name, subscriber_phone_number FROM CellPhoneGPSRecords
WHERE SampleTime BETWEEN 'April 8th, 2009 3:30pm' AND 'April 8th, 2009 4:30pm' AND DistanceFromM(Victoria’s School)<500
Someone premeditating a crime would likely leave their cell phone at home (though I would wager that the woman in the white coat probably had one on her), or disable it in some way, but it would nonetheless allow the net of discovery to close in on the truth. The lack of certain data is often indicative.
Say to contact a guy in the area (via text message of course) and find out that he was in the neighbourhood taking pictures of doors, and wouldn’t you know it but he happened to have one that has a suspect matching the description walking towards the crime scene 9 minutes before the crime.
That’s if you even need to contact him. Maybe he uploaded his GPS-and-time-tagged photos to Flickr, and a police investigation entails a photo search, again drawing from the enormous distributed capture that happens every day.
It is neither a utopia nor a dystopia, but I think pervasive, distributed, decentralized recording and archiving will be a good thing for society.
We recently decided to beef up a solution's storage platform. What would have been a simple process just a few months earlier — select a storage subsystem, whether it be NAS, SAN, or DAS, and then populate it with a bundle of drives to meet the performance and space needs — became a serious quandary. We're still in limbo, unsure what to do.
Should we bother paying out big dollars for arrays of magnetic drives, or should we push the envelope and go with an array of SSDs? Should we wait a while? Will our vendors and the storage systems support this technology? Will existing products make optimal use of it? Will the SSDs burn out under our usage models?
Dell, for instance, still has nary a mention of SSDs in their servers and storage products site. Their reps still telling you that SSDs are unsupported.
Yet the evidence is obvious that in the year ahead SSDs are going to absolutely annihilate the existing field of storage vendors. Suddenly "outsiders" like Intel (now really known for storage products) and Fusion-Io are the leaders, making the existing market look like a bunch of chumps. Paying big dollars for a large array of magnetic drives seems like a choice that will certainly yield some serious buyer's regret a few months down the line.
SSDs change everything.
In a similar way, the extraordinary advances in JavaScript over the past year have completely changed the scope of what a "web application" could entail, and we as developers still haven't fully come to realize what this means. Opera, Webkit, Tracemonkey, and now, jumping to a big lead, the supercharged V8 engine of Chrome 2 (I have some serious misgivings about Google's browser given that it's the product of an ad company, but it is uncontestably becoming a real contender. I will warn that on the Chrome download page linked before this parenthetical aside, they put the agreement to send...cough...anonymous statistics in exactly the position where people have habitually learned to click to agree to the ToS), the advances have been truly spectacular.
Exciting times ahead. These innovations aren't simply evolutionary, but change the scope and rules of the game.
We have a number of network devices at play in my household.
I have my work machines. My wife has her laptop. My kids have their PCs.
Family and friends that comes to visit connect their iPhones and laptops to our 802.11g/n.
We have shared media that we play on devices like the Xbox 360 and PCs over protocols like uPnP, DAAP and SMB. We have shared files, such as financial info, that we need to access from any machine, all while confident that they remain as secure as we want them to be.
We do VPNing from remote locations like coffee shops to access files and media. We have a shared printer.
To optimize this situation without leaving my power guzzling pig of a PC on around the clock (I’ve setup and torn down a number of home servers over the years, all the ways back to a FreeBSD-based device in the mid-90s that also doubled as a firewall), a while back I bought a Synology DS-106j NAS unit and dropped it on the network, deciding on it after looking at some Windows Home Server products, finding them overpriced and uncompelling (not least because of concern about licensing and DRM BS.)
One of the selling points of this ~$200 unit (to which you add whatever 3.5” hard drive fits your fancy) was the gigabit network port. To me that implied that it must be capable of at least keeping a 100Mbps pipe saturated with goodness.
I also liked that it gently sipped power (13W or so with the hard drive), allaying any guilty about leaving it on around the clock.
The Synology unit is fantastic in many ways.
It has a fantastic interface. It is rock solid (zero downtime with it) and is very feature rich, with several free “firmware” updates since I purchased it adding a number of new features and interface improvements. It is easy to setup and use, and to a superficial degree secure. It comes with great desktop software for common tasks like backing up (and versioning) files on your Windows machines. You can offload torrent downloading to it if you’re into that sort of thing.
But the hardware seems to be underpowered. The 200Mhz MPC8241 CPU that powers it can’t deliver on the extensive feature list, in my opinion.
The 1Gbps network port turned out to be brave talk that it couldn’t back up with action. Normal SMB/CIFS (the protocol that Windows utilizes to access network file shares) averaged about 2.5MB/second throughput with the device, which factoring in overhead is around 22Mbps, leaving plenty of headroom before it hit the limits of even a lowly 100Mbps network.
I got it up to 8MB/second or so by turning off all of the features like media sharing, and then disabling all security on the share and enabling guest access – it seems that access control security significantly adds to the computational burden – but that isn’t a viable day-to-day option so I had to revert and it was back to 2.5MB/second. FTP was a little better, but was still way below expectations given that the same hard drive got a rough 40MB/second from a direct-attached USB 2 enclosure.
Given that I am now downloading from the web at large at 1.1MB/second, this seemed silly. As we’ve started to amass monstrous AVCHD video files of a GB or more from the home video camera (the latest GB or so features my youngest son herding some chickens that had escaped from their pen at a local farmhouse), it was getting unsustainable.
Synology is now selling a purportedly faster unit, but given that I saw much lower real-world speeds than what they graph for the old unit, and their new unit really doesn’t do that much better anyways, it didn’t compel me to upgrade. Many competitive low end home NAS devices have reportedly similar performance in the wild.
And it isn’t just waiting while moving large files or having SyncBack jobs run. Navigating the music directory from a uPnP client made it obvious that the slowness impacted all activities, with basic operations having intolerable delays. Attaching to its network shares from client PCs inexplicably had multi-second waits before responding.
Then again, I’m the guy who thinks that the biggest crisis in the electronics world is the excessive lag before DVD players will eject a disc, so maybe I’m an outlier, but it seemed like a pretty big weakness of what would otherwise be a great product.
It really bothers me when units doing tens or hundreds or thousands of millions of operations per second take perversely long times to do simple things.
On the bright side, the small dimensions of the enclosure made it easy to find it a home, but it also had the S.M.A.R.T. monitoring of the hard drive complaining about borderline heat incessantly. And the printer sharing never worked properly, but given the endless variety of printers I won’t blame that on the NAS unit.
So I decided that it’s time to replace the device, with the following criteria for its successor.
Local RAID isn’t important to me, as availability isn’t a primary consideration (and multiple drives go contrary to power conservation / heat reduction goals, and generally increase maintenance.) Every file that is on the unit always exists on at least one other drive on a separate system, so if the drive died I could quickly rebuild and repopulate and life would be grand again. And it is vastly more likely that two drives in one unit would catastrophically fail than it is that two drives in physically separated devices would fail, especially when the separation between can be thousands of kilometres.
Nor do I want this to function as a media station, which I consider an entirely different function, with an entirely different requirements list. I don’t need or want HDMI output, blu-ray decoding computational power, 3D offloading, a MAME box, or anything of that sort. That’s a different project, with a different set of goals.
After looking at the available market options of targeted NAS devices, and hardware solutions like Shuttle computers, I decided to have a little fun and build my own (in the minimalist stick-some-lego-like pieces together way that is "building" a PC), so I grabbed a couple of components.
<$200 for the “NAS enclosure” part, then $127 for a good hard drive with room to grow. Pretty inexpensive, and would probably even make a decent internet appliance, which presumably is the intended use of the motherboard/CPU combo.
Putting it together was a snap, with dutiful oversight from my children, followed by a quick flash to the latest BIOS release.
I installed Ubuntu 8.10 Server from a USB stick (I considered installing FreeNAS, but decided that I wanted something a bit more custom), after which I discovered that the hard drive wasn’t set to bootable and the system wouldn’t boot without the USB key, so I had to boot with the key and use parted to manually set the sda device to the boot device, after which the USB key was no longer necessary.
Installation complete, I stashed it away, sans keyboard or mouse or monitor connection (which it makes no complaints about, happily existing without head, keys or mouse), and access since has been via putty. A magical source and destination of media and files, out of sight and hopefully usually out of mind.
I installed Samba (during the OS install by choosing the file server option), created the users and groups and perms, added some shares, and started accessing it from my workstation. It was all very easy and straightforward, including even setting up AppArmor to enforce mode against the Samba services, adding a small additional guarantee of security.
I started the first file move, ready to witness some low-cost awesomeness.
11MB / second to write to it, averaged out over the copy of a GB sized video file. I got about the same speed reading back from it.
Pretty good compared to 2.5MB/second (and now I had much better security granularity than I had before, on a much more versatile platform), but not quite what I was expecting. Awesomeness not witnessed.
The hard drive isn’t the fastest of the bunch, but it’s still very decent.
I’m far from an expert when it comes to Linux (or more generally Unix) systems, seemingly achieving some small level of localized expertise at intervals in my career, but then the solutions simply work and I don’t have to touch them again, so the knowledge rusts and each time I return I feel like I'm a Linux virgin (who would have ever thought that Linux and virgin would used in the same sentence?) It is similar to my proficiencies with Perl or the equally obtuse Powershell, where I put together very decent solutions, but then several months later look in disbelief that I actually wrote the code that now looks foreign.
Nonetheless, I quickly determined that the network adapter was auto-negotiating itself incorrectly to 100Mbps, and 11MB/second is about the max you could achieve over such a link.
After a quick bit of searching, I added ethtool -s eth0 speed 1000 duplex full
autoneg off to my interfaces file (after validating that it worked at
the command line). It was now at full 1Gbps glory.
So I performed the file test again.
47MB / second to write to it. 55MB / second to read back from it.
Sweet! That isn’t that far off of local storage, and is entirely with the acceptable zone. It was achieved on a $200 host device. File sharing is hardly the most demanding application nowadays, but I was happy to get something much more usable.
Just to take a side trail here for a moment, I just wanted to mention that Linux, and the evolution and progress of it and related projects, really is amazing. It is astounding that such a solution evolved the way it did. Even people who don’t think they benefit from it regularly use devices run on the OS. The amount of functionality and technology available, including the source so you can roll your own, truly is remarkable. Linux didn’t start this movement, and projects like FreeBSD, sendmail and prior initiatives blazed a successful trail before Linux really took off, but it is the most evident element of that development model.
Back to setting up the homebrew NAS, virtually every step of the way I had to consult the wizard, Mr. Google, but at least the answer was usually only a page 1 or 2 hit away (though Google Groups has taken a perilous dive into close-to-uselessness, and proved of little use.)
To this point I still haven’t had luck finding a good uPnP server for the device. uShare simply didn’t work. Mediatomb inexplicably doesn’t work with the xbox360, and even if it did the fact that its anonymous web user interface has the default behaviour of exposing your entire file system makes me question the wisdom of the developers.
Various other projects didn’t fit the bill or didn’t work for me, and most seemed to have been abandoned.
I thought I’d try the MythTV backend, as it is purported to double as an uPnP AV mediaserver, to find that it bizarrely needs an X server running and an X client on the other end just to perform the setup. I decided to purge it from the system to find it wouldn’t uninstall due to /dev/.static/dev being mounted read only. I found a workaround involving stopping and starting udev, which remounted it as read/write, but at that point the damage was apparently done, and it refused to gracefully leave the system.
So I went MythTV huntin’, committing a moronic error in the process (it tried hard to warn me, but I persisted in my foolishness.) I’ll let the putty log speak to it.
dennis@mediaserver:/var/lib/dpkg$ sudo killall mythbackend
dennis@mediaserver:/var/lib/dpkg$ whereis mythbackend
mythbackend: /usr/bin/mythbackend
dennis@mediaserver:/var/lib/dpkg$ cd /usr/bin
dennis@mediaserver:/usr/bin$ cd mythbackend
-bash: cd: mythbackend: Not a directory
dennis@mediaserver:/usr/bin$ rm -R *
rm: remove write-protected regular file `['? ^C
dennis@mediaserver:/usr/bin$ sudo rm -R *
dennis@mediaserver:/usr/bin$ ls
Installing everything once was so much fun that I decided to do it again!
So I reinstalled again. The second time around it was a very quick process (even with a nuked /usr/bin I still had a chance to backup customized config files to a client box before reinstalling, so I really didn’t lose much.)
Power wise, I’ve gone from ~13W for the DS-106j, to 35W to 40W for the new device (measured with a Kill-A-Watt. Handy device.) This represents a pretty big move in the wrong direction, but it wasn’t unexpected. 4-8W or so could likely be saved going to a more efficient, fanless power supply. That’ll be a future experiment. The Caviar Green, at 3-4W, isn’t much more power hungry than an SSD, so that wouldn’t make a huge difference. The motherboard and its chipset is the real piggy of this farmyard.
Alas, in return for the extra power consumption I now have a vastly more interesting network device, serving files at a much more usable pace.
So my first adventure is beginning the work on a .NET-based uPnP server, ensuring that it works on Mono along the way. Thus far it has been nothing but remarkable success, and it still astounds me seeing fairly complex .NET applications running well on a Linux box. The thing really, really works!
The story of Markus Frind is not a new one around development circles: Some guy creates a remarkably unpolished, seemingly unsophisticated dating website and in short order is bragging about the million dollar checks he's getting from Google Adsense payments.
Still, you owe it to yourself to read the article about his exploits in January's Inc. It is a fascinating story of internet success against the odds, and the site that is serving up 1.6 billion pages per month on an inexpensive modicum of hardware. That article references Markus' blog entry from 2006 where he explains how his extraordinary success story began.
[Imagine that I insert some drawn-out blowhard "lesson" to be learned from Mr. Frind's success here, allowing me to justify making an entry that is basically nothing more than a link, all while pretending that if you follow these simple steps you too can achieve the same results]