Category: Calc
March 8, 2007
ElasticLive: A Comparison to Native EC2
So, there's this service out there called ElasticLive, run by enomaly. At first, it looked like competition to Amazon EC2, but then I saw how they were wording their services and it didn't take long to realize that they are reselling Amazon EC2 services. Amazon EC2 is already rather easy to use, so I am curious as to what they offer over Amazon EC2.
For starters, for their dedicated grid machine they charge 25 cents per hour, 45 cents per gigabyte of bandwidth, and 25 cents per gigabyte a month for storage. However, they include 1000 GB of bandwidth and 160GB of storage in this pricing. Let's compare, shall we?
For someone maximizing the account, ElasticLive will be losing about $115 a month. Even with 160GB of storage, bandwidth only has to average below about 425GB, though, and they make money. Then, again, above about 1250GB of bandwidth they'll start making money again. So, for the consumer, it's only cheaper if you're in that middle-ground.
However, they offer fractional virtual servers (likely a VM system within a VM). For 5 cents an hour, you get a system with 20GB storage, 200MB RAM, and 60GB of bandwidth for the month. Given the normal system has 1.75GB of RAM and 160GB of space, this gives about 8 virtual machines per, uh, virtual machine. Let's compare this, shall we?
- A full Amazon EC2 native AMI with same transfer and storage: $88.04
- 1 ElasticLive fractional: $36.52
- 8 ElasticLive fractional: $292.19
- Amazon EC2 with 8x transfer and 8x storage: $193.04
Here, we can see the consumer that just needs something small and simple can save some money, especially if they don't need much space or bandwidth. They can get many of the Amazon EC2 advantages but at a lower cost because ElasticLive is helping divide the resources out. Assuming they can get 8 instances on one AMI, they'd be making money with only 5 or 6 fully used fractional grid machines.
It would also seem that ElasticLive offers some basic AMIs that can be used as part of their service, including access to server configuration tools like cPanel and Plesk. It's an interesting idea, for sure. However, it seems to have a fairly narrow window of use to the consumer, unless their provisioning tools are very easy to use compared to something like the EC2 UI plugin for Firefox. Although it's a common thing to do, I'm not sure about the prospects of building a business off of the fact the most consumers don't fully use what they pay for. I'd also be curious if someone could access their personal AMIs in their own AWS account for the fractional stuff or not.
One service that they do offer that is interesting is the ElasticDNS service for dynamic DNS for Amazon EC2 users. I'll have to check that out a bit more...
()
(0)March 6, 2007
The Cost of Amazon EC2 P2V of an Existing Server
So, let's say that you have an existing server that you'd like to migrate to Amazon's Elastic Computing Cloud (EC2) by using their physical to virtual (P2V) tool. The question is, how much will this cost you for the initial Amazon Machine Image (AMI) upload to Amazon Simple Storage Server (S3)? And then, how much will it cost to continue to run on EC2?
The basic equation is relatively simple. We'll go with an example, first. Let's say you've got a server that's currently using 40GB of storage. That will need to be packaged into an AMI. Although there may be some compression (?) we'll assuming there isn't. Uploading 40GB to S3 will cost 20 cents a gigabyte, or eight dollars (the costs are all in US dollars). After that, you'll be paying 15 cents a gigabyte per month to store this AMI or $6 per month plus bandwidth. If you were using about 100GB a month of bandwidth, you'll be paying an addition $20 a month for that. That's a total of $26 per month plus the cost of the instance at about $73 per month. So, you'd then be paying about $99 per month.
However, if you just want to bring up your server in the cloud for a few hours to run some tests or experiments with different configurations, you'd only pay $8 to get it up there and then for the AMI time.
There is one caveat, though. Make sure that you aren't going to be charged by your current host for the upload. Also, you need enough room on your current physical machine to make a mirror of it.
In my case, I'm thinking about splitting a single physical server into two servers. One that will remain the physical server and one that will be hosted with EC2. This would increase costs, of course, but it creates a better logical separation between certain uses of the machine.
My other use case is to test a yum-based OS upgrade since I can't really upgrade any other way - aside from imaging a slightly newer OS on to the box and reconfiguring everything. However, I noticed the following in one of the FAQs:
Can I use my own kernel?
Not at present.
I'm not entirely sure what that means given that people have published many AMIs with many different version of Linux which I didn't think would be using the exact same kernel.
Finally, along the cost lines, don't forget about your time. That has value to you and/or your company. To summarize the formula, you've got:
One Time Cost:
(20 cents * GBServer) + (current host cost to upload) + (your time to prep upload) + (your time to convert to S3 store for persistence)
Monthly Costs:
($73 per server) + (15 cents * GBServer) + (20 cents * bandwidthGB)
Sure, most of this is obvious. The largest unknown, though, would be the time to convert servers over to have data persist outside of the AMI. This can either be done by having the application directly store to S3, having a backup system run a frequent full backup of the data directories to AMI and restore on boot, or use one of the filesystem drivers to have the data portion of the filesystem be linked directly to S3. (Where S3 is used, any other off-AMI storage could be considered, but I'm assuming the network connection between the AMIs and S3 is very fast and very low latency.)
February 12, 2007
A New Look at Future So-Called "4G" Networks
NTT DoCoMo in Japan recently did a successful test at 5Gbps. Yes, that's five times the speed of a wired Gigabit Ethernet network. That's pretty impressive.
Now, I don't think the generation can be labeled until it's in the past and can be defined. However, that's not really the issue here. The issue here is: What can we do with 5 gigabits of data moving every second to the mobile?
I say that there is a ton of stuff that we can do with that amount of bandwidth. But really, what's that come out to? Maybe 500 megabytes per second after protocol overhead? Then you factor in the mobile reality factor, which is that current 2.4Mbps networks operate at an average of 500Kbps. So, we can bring this number further down to a mere 100 megabytes per second. That's so sad, isn't it? What, that's only about 157 times the speed of my current DSL line. Uh...
This is some amazing amount of bandwidth available. As long as the latency is low enough, this could enable some very interesting applications. It's nearly as fast as some of the fastest desktop hard drives available today. So, anything you could do from a super fast hard drive, you could enable on a handset like this without having it's own local storage. This brings data and applications from the entire web to the phone in on-demand time. That is, you get what you want when you ask for it.
Think something like Google Earth, but with no waiting time for bringing in the data while you zoom around. Imagine being able to play full HD video of any movie available without having to wait for buffering and never having it stutter. All applications available by just launching them without a need to copy them locally or install them.
Don't forget about all of things that we (as a whole) haven't thought about yet. There will be new media, new applications, and new uses that will be able to leverage this sort of bandwidth. Let's also not forget that this is just the next step up. There will be more steps as big or bigger than this. What will they enable?
Sure, thinking about that is like thinking about the uses for the 2.4Mbps networks we have now back in the early 1980s. If you were sitting on a 300 baud modem back then, you probably didn't even dream of watching movies over it. After all, why would this even be a consideration? You could rent tapes and you could see TV over cable.
Following by example, what do we take for granted now as something that we can't do on the web? This would be something that you would normally think of as taking too long to do on the web or maybe that the interface isn't right or something like that. For example, if you calculated out the size of what a movie might have been and then calculated how long it might take to transfer it over twenty years ago, you'd come up with a number on the order of 30 years. Remember, part of why we can even do it now is because of the modern compression being applied to the size. Even a highly compressed, low resolution DVD contains 2 or 3 gigabytes of video and audio. Even audio wasn't really downloaded much until it was reduced from around 15 megabytes a minute for high quality audio to only a megabyte a minute.
Here's a final thought: If your mobile is working at that rate, how fast will your wired home Internet connection be? If it's that fast, imagine how fast your local storage will be? I could go on, but I won't...
January 29, 2007
How Did I Miss Amazon EC2?
Amazon's EC2 (for Ephemeral Content Creation? no. Echo Cho Cho? no. Electronic Comedy Central? no! try Elastic Compute Cloud on for size) is a virtual computing environment that is to virtualization that S3 (Simple Storage Service) is to, uh, (this comparison is breaking down fast) dynamically adjustable RAID arrays.
Too many parenthesis to follow? Basically, for ten US cents and hour, you can load up a virtual computer image with an Amazon Web Service API that can have whatever installed on it that you want. The virtual system is equivalent to a 1.7GHz machine with 1.75GB of RAM and a 160GB hard disk all sitting on a fat 250Mbps net connection (that bursts to a full Gigabit). You store your virtual machine image within the S3 storage system.
Amazon charges for the S3 storage (a separate account from EC2), for the time the virtual computer is on, and for the bandwidth that the virtual computer uses that leaves the EC2/S3 system (they don't say about bandwidth to/from SQS). Pricing is currently pretty simple. For each virtual computer you have running, you pay the ten cents an hour, then you pay twenty cents a gigabyte for bandwidth, fifteen cents for each gigabyte of storage used per month. There really aren't any limits to any of these three items. So, you could run your machine for 15 minutes each month or you could run dozens of machines continuously. (They do ask that you contact them if you will be trying to use more than 20 virtual machines.)
Effectively, what they're providing is not only the ability to provision and configure your own dedicated servers on a relatively high bandwidth connection but the ability to do so via scripts, too. A high end system could have a watchdog monitoring server performance and bring up new servers as they are needed then take them down when resources become available. This could near-perfectly optimize costs.
This could also be used as a test bed for setting up grid servers and other forms of distributed computing devices and servers. With testing costing only 80 cents for a typical 8 hour work day, that's not bad at all. This can also be enabled cheaply. A single virtual machine image can be used for multiple instances of the virtual machine. So if you make a test environment for your application that can fit in a gigabyte, then you could have as many individual, dedicated servers as you wanted available when you wanted for only fifteen cents a month plus the server time. That's cheap, in my opinion!
If you run a service that only needs to be available for weekdays (or weekends) you could also have it shut off during the other times to reduce costs. Or if you have a seasonal application or service that only needs to run, say, in October, you could set it up and have it only available during October with only the storage fees to have it ready for the next October (although you could store the image offline until the next year, if you chose to).
Now, speaking of costs, if you just wanted to run a basic dedicated web server, is it actually cost effective with Amazon EC2? I'll compare to a system I have with 1&1 a known system over at The Planet, and running (probably against ToS) a server on a DSL or Cable connection.
The 1&1 system is a 3Ghz P4-HT system with 2GB of RAM, 120GB of storage (with an addition 120GB of offline backup) and 1500GB of transfer. All of this runs $119 plus 49 cents a gigabyte for overage. It also includes static IP addresses. The machine has a 100Mbps connection to the external world. This machine also comes with Plesk, a firewall, control panel, serial access, some various bits of software.
A lower end system over at The Planet includes a 2.0GHz Celeron with 512MB of RAM, 80GB of storage, 750GB of transfer, and a 10Mbps ethernet card. This all costs $69 per month and also still includes some IP addresses. I can't find a specific number for overage costs of bandwidth, but going for 3000GB per month to 3500GB per month on a more expensive server costs an additional $125 per month. This corresponds to 25 cents per gigabyte.
Both of these systems provide dedicated, true hardware. You can run whatever you want on them, including virtualization software to create as many other virtual machines as you want (and the hardware can handle). On the first system, though, it has more RAM and probably a faster processor that compared to an EC2 system. The second system is likely slower and less capable and definitely has a slower connection to the real world. Both of these systems are a good comparison because neither are high end and both are relatively affordable. The respective companies can usually get one online within a couple of days after you contact them. Both of these options are also self-managed.
Now for the fun part... if we assume that a processor is a processor and not worry about the comparative speed of these systems and not worry about the comparative speed of their physical hard disks, we can make a comparison assuming full use of each system.
An Amazon EC2 system that used 1500GB of transfer and 120GB of persistent disk space while being operational 24/7 would cost $73 for the compute time plus $300 for the transfer and another $18 for the storage. This is a total of $391, which is clearly more expensive than the 1&1 option, yet it does have advantages that I'll get to in a moment.
The other system on Amazon EC2 would cost the same $73 for the compute time please $150 for half the transfer and $12 for two thirds of the storage, bringing the cost down to $235, which is still much more expensive than either system, though you get a lot more RAM with the EC2 system.
Now, here's the thing, though: You wouldn't want to run either hardware system with a full disk. Nor are either of these systems likely to keep up with their allotted transfer. In my case, on the 1&1 system, I only use about 50GB of the storage and maybe 150GB of the transfer. In this scenario, the cost would be down to $110, which is ever so slightly cheaper. Yet if the transfer was down one month, the cost would go down. And if I cleaned up cruft on the disk, the cost would go down. This brings both benefit (keeping a tight system would be cheaper) and risk (increase in traffic costs more initially). Now, your base costs is $73, which is slightly more than the cheapest The Planet system and plenty more than a shared host. You are charged for uptime, not average load.
However, a bigger benefit is easier scaling and provisioning: you can do it yourself. And you are not tied to physical hardware limitations, so you can use more storage as you need to with S3. Software upgrades would be made easier, too, since you can bring a second system up to upgrade and test before bringing the first system down.
Now, after some thinking and looking around, there are two large concerns with Amazon EC2. The first is that the virtual machine's disk is not persistent. If you want persistent data, you have to either store it in Amazon S3 directly or frequently copy data files to Amazon S3 (which isn't quite as simple as scp). The other problem is lack of a physical IP address. This can be solved with some of the dynamic DNS hosts that are around for other reasons.
Now, I said I would compare to a self run machine. Your initial setup will cost more, since you'll have to buy the hardware. You might find a good, low end Dell server for $400 or so. You'll have to figure out how to handle the IP address issue if you don't have a static IP, much like the Amazon EC2. But that's it, right? Because you already have your net connection, there are no further charges, right? Think again. Here in CA, after our basic electric usage, we end up paying about 33 cents for every KWh used. A small 300 watt system will end up running that same 10 cents an hour that Amazon EC2 charges, bringing back the base $73. And your users won't like your slow 600Kbps uplink connection to them. Nor will your provider be happy about you hosting a server, since it's usually against the Terms of Service for home connections. And what if you hosted it on your gaming system with it's nice 1 kilowatt power supply? That'll cost you a cool $330 a month around here (although your heating bill may drop, your AC bill will go up during the summer).
None of these options provide one the experimental flexibility of Amazon EC2, though: You can't try them out for a few hours and at a few bucks cost. Most of them require annual commitments. The ability for just a little money to play with your own farm of a dozen servers is also amazing. If you've already got scripts that can break data up easily across processes and even machines via network shares, then you can quite easily bring up a number of machines, distribute the data to them, process the data easily on 20 machines, copy the results back down from each, and shut the machines down. Even with network speeds, this could be much faster than running the same processing on a single machine.
I think, for me and right now, the biggest single problem is that it's a limited beta and they aren't letting new people in right now. Darn... I was hoping to play with it a little this weekend. One possible use for me right now would be to clone my current server in to an AMI, use the AMI to test upgrading of the OS, and then either do the upgrade again or transfer back to the physical server I'm on. But, alas, that's not gonna happen right now...
January 25, 2007
Comparing HD and TV Resolutions
There is a page floating around the net currently that appears to do a good job of comparing a 480p display to a 720p display (it's here, for reference). At first glance, it's great. You mouse over and see the 720p while mousing away and seeing the 480p. There's a very clear difference between the two. The 720p view has much more detail than the 480p view.
Then I realized something. This comparison is somewhat flawed. What it's actually comparing is 720p to a 480p screen that's being scaled to 720p with an unknown algorithm from paint.net. So really, it's comparing how a 480p picture would look on a 720p screen when scaled with that algorithm.
I also got to thinking about this with respect to our TV. Our TV is a 40" 1080p LCD screen. That means, by definition, anything being displayed on it is being scaled to 1080p since you can't change the fact that it has 1920x1080 pixels on the screen. When it's drawing a native 1920x1080 image, all is pixel perfect. But when it's drawing a 1280x720 image full screen, this is actually a 720p image being scaled to 1080p even if the info says that it's 720p (the source is 720p and the screen mode is 720p, but the screen still has 1080p pixels being used).
The same is true when it's drawing any of the other resolutions, such as 480i, 480p, and 1080i. In the 480x cases, there are black bars on the side so the aspect ratio is kept correct so it's not actually lighting up all of the 1920 pixels across the screen. However, since we know the aspect ratio is 4:3, we also then know that in the 480 modes what we're really looking at is 480x scaled to 1080p at 1440x1080 rather than the widescreen 1920x1080.
When the TV is doing the scaling, like it does with a component input, it uses it's algorithm to figure out how to draw and smooth the pixels on to the screen. With VGA input, though, at 1920x1080, the source of the video must do the scaling (in my case, either a computer or the XBox 360).
What this means is that when I compare the quality of a 480i digital channel to a 1080i or 720p HD channel it's all being compared with the TVs scaling to 1080p. This is not necessarily how these channels would look on a 720p or 480i screen as our TV has more pixels.
The same goes for the comparison of 480p to 720p where the comparison images are both 720p, but one has been scaled and scaled rather well, at that. For a different comparison, you could do a non-smoothing scale that would basically similar 480p with larger pixels in the same size as a 720p screen, or put gaps simulating the same size pixels but with a greater pitch. Either of these methods would try to simulate a a different number of pixels being used while normalizing to the viewers screen.
Anyway, just some random thoughts on the topic... in the end, we decided on a TV that scaled better than most but not quite as well as the $1k more expensive Sony Bravia Pro series. The point being that the quality of the scaling on an HD TV is quite important these days. A good scaler can actually produce really good images. Our TV has a good scaler, but the XBox 360 has a much better one.
February 27, 2006
Bittorrent: The Slow Download Method?
So, last week I needed to download the Fedora Core 4 DVD. It's about 2.4GB. I started by just clicking on the main download link. The download rate on this was really slow. Having recently downloaded the same thing at work for a work project, I knew that many of the mirror sites were no faster, though. So, I decided to try out the torrent.
I didn't have a torrent client installed, so I did the natural thing. I downloaded Azureus, arguably the most popular client as it's also always near the top of popularity for all SourceForge projects. i got it up and running and grabbed the torrent. Within a few minutes it was transferring at 50KBps (B is for byte and b is for bit). This wasn't too bad, but for 2.4GB it was going to take a long, long time. I gave it another 10 minutes and it was still only hovering around 60-70KBps. On a typical site, I normally get well over 300KBps, with peaks up into the 600KBps range.
So, I decided go and try out one of the mirrors for the hell of it. What would it hurt? Instead of the typical HTTP mirror, I decided to try out an FTP mirror, figuring it might have less protocol overhead (is this true). Well, the top link in the western US section fit the bill; it was an Oregon university link. So I clicked. It immediately started downloading at over 500KBps and went up to 550KBps. All of this while the torrent was still running. Already I was getting 10x the speeds. I killed the torrent and after just about an hour I had downloaded the entire 2.4GB at a sustained transfer rate of 622KBps. Why would I ever use a torrent if it's less than a tenth the speed of a decent site?
I've been doing a lot of thinking this last week on why the torrent was so slow. The idea behind torrents, of course, is that the bandwidth is distributed and the entire universe of people downloading the particular torrent add to the overall download bandwidth of the torrent. So why would it be so much slower?
Well, there are a number of factors. On factor for many people is that they have a firewall where they can't open up the ports on it. This is not the case for me; we run a WRT54G with OpenWRT on it. The ports were open and configured properly.
Another factor is that the universe of people isn't always large enough to give everyone full theoretical bandwidth. In particular, we have a fairly fast connection (for US standards) and so we expect faster transfer rates than normal. For a normal user, getting 80KBps is roughly have of their expected 1.5Mbps connection.
The other big problem as I see it, though, is that the vast majority of people are on connections were the uplink is a tiny fraction of their downlink. A typical US DSL line will have 1.5Mbps down and 128Kbps up. Our connection is around 6 Mbps down and 608Kbps up, a similar ratio. That is, a typical ratio is 10x the dowlink speed as the uplink speed. So, from here we can do some simple math.
Let's say everyone in this hypothetical torrent universe has the same connection speeds. For simplicity, we'll use 1MBps down and 100KBps up. So, now let's say we have 10 clients in the universe downloading the same torrent. We now have a bandwidth demand of 10MBps but only 1MBps of bandwidth being provided. Why would the eleventh client join in when they'll just get one tenth of the current available bandwidth (they don't download from themselves). Interestingly, one tenth of the bandwidth happens to be equal to the speed of the uplink everyone has: 100 KBps. In fact, the bandwidth available when everyone is downloading is exactly the average of all of the uplink speeds summed divided by the number of clients. Since, on average, everyone's uplink is a tenth of their downlink this means that, on average, each person will get a download speed of about one tenth of their maximum download speed. Funny enough, that's exactly what I was getting.
Now you might be asking, "What about seeds?" Well, this is the single piece that seperates reality from theory. The theory is that when a client is done downloading it will continue to upload but it will no longer have any download demand for that particular file. So, if after our first ten theoretical clients finish downloading, another 10 will come on. Now we still only have a download demand of 10MBps. However our available upload bandwidth is now doubled to 2 MBps. This means that the new 10 clients will each get to download at 200 KBps. So, if this follows, we need 100 clients in the system, with only 10 downloading and everyone uploading. This gives us a total bandwidth demand of 10 MBps and a total bandwidth supply of 10 MBps. (You'll actually need more since there is some protocol overhead in finding peers but we'll leave that out for now as it's relatively irrelevant.)
Unfortunately, reality doesn't quite work that way. And, in fact, I don't think it can realistically work that way. First off, a typically person downloads a file and gets off the network. Yes, this means their bandwidth demand goes away. However, they take their bandwidth supply with them. There are a few reasons why someone might want to do this. One reason is that they may be turning their machine off. A more typical reason is that they need the bandwidth for something else. It's common that when your uplink bandwidth is saturated your overall net experience will suffer. Response times get worse, other people on the network complain, and you get booted. (QoS can help solve some of these problems, but it isn't available in most routers.) However, another more common reason might be that the client is going to go off and start downloading another torrent. If they left their old torrent in seed mode and started a new one, the bandwidth would likely be split between the two. This means that they would only be giving a twentieth of their download demand back as bandwidth supply. This makes it even harder for this next torrent universe to build up the supply they need, even if this particular client goes into seed mode.
Take, for example, a torrent for a daily podcast. If a particular client decides to leave each torrent they download going in seed mode indefinitetly, after only two weeks each torrent will only get 10KBps of supply, or a hundredth of their download demand. If everyone did these, then the universe would need 1000 clients to provide enough bandwidth supply to only 10 clients. This is not realistic. So it's actually in the next torrents benefit that a client stop seeding the previous torrent. However, the previous torrent suffers for this.
Now, when you compare to a single server feeding to 10 clients, you only need a server with a 10MBps connection to feed them. This is fairly trivial for a single server to provide. Now why doesn't that server just join the torrent as a seed? Well, sometimes they do. In our example, each server that can seed at 10MBps is equivalent to 100 clients worth of bandwidth supply. This is also a great way to load balance between multiple servers rather than having to do (relatively) complex routing, bandwidth sharing, and load balancing. But do 10 servers seeding at 10MBps actually provide the same amount of bandwidth as a single 100MBps server?
Usually not, since there is protocol overhead and for clients there is often a loss of bandwidth when a lot of ports are in use. Not only that, since all bandwidths get averaged out, those that could have downloaded of a server and gotten off the network more quickly won't be able to. This goes back to my real example. I could have been demanding 622KBps of bandwidth for hours on the torrent, but instead I used that much bandwidth for about an hour on an FTP server and went away, freeing up the bandwidth much sooner.
I don't think torrents are the solution to overall network bandwidth. I think they are a great solution for small sites to distribute the bandwidth demands to others. This is because the torrents scale. In our example, each additional client adds demand ot the tune of 10x their uplink however, I've shown that they will typically only get bandwidth equivalent, on average, to their uplink bandwidth. This means that 10 people can download at the same rate as 10000 or even 1000000 people. They don't get to use their full download bandwidth, of course. In the end, the bandwidth actually becomes synchronous in a particular torrent universe.
So, the reason torrents are so popular isn't because a particular client can download faster. It's because they scale with the downloading universe. And anyone who can stay behind for however long as a seed just helps the situation by however little. So, if you need to download quickly, finding a fast FTP server will always win out unless it takes you hours to find that server. For Fedora Core DVDs, I'll stick with finding an FTP server since that will almost always be faster for me -- and I'll end up taking more than my fair share of bandwidth out of the universe of torrent clients since I won't stick around to seed a file I need to burn to DVD and delete of my system.
(There is, of course, another reason people like torrents. Sometimes they are the only way to download something. But that's a completely different topic.)
April 27, 2004
How a wedding dress gets thousands of hits a minute...
Good grief: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=4146756343
Certainly, it's funny enough. Right now, 15:04, it's at 752,268 hits. When my friend first showed me, it was at 726k hits. And that was only a few minutes ago.
And this is the sort of thing that mostly goes through IM, too. IM seems to be the new method of choice for passing jokes and other things around. And it's much faster than email, in general. Not because of the technology. But because of the way people use it. I'm sure this has made plenty of other blogs, too.
After typing that paragraph, it's 15:06. And it has 758,914 hits. That's an average of 55 hits a second. At this rate, each day will produce 4,752,000 hits. The whole page size, including graphics, is 370kilobytes. That gives 1.6374886 terabytes of transfer per day. In bandwidth terms, this listing is using 19.8730469 MBps of bandwidth.
And now, at 15:15 (hey, I work too) it's got 777937 hits. In the last 9 minutes, the rate has changed to only 12.71875 MBps of bandwidth.
I'm lucky to have ebay items that get over 100 hits. The PowerMac I recently sold only got 104 hits.
Certainly, it's all the story -- and the responses. But is any of it real? Who knows. It certainly has helped make the price go up. ;)
And yes, the hits are unique... the counter will not count me twice.
And I sign out with it at 792,249 hits. Up 39,981 hits since I started this. Amazing.
[Update: it's 09:52 on the next day the hit counter on this is up to 3,568,643. It's been rolling at an average of 43.4 per second, or 15.68MBps. Amazing. What's more amazing, though: it's currently bid up to $15,100. For a $1,200 new dress? And at 10:08, it's at 3,657,941 for a 16 minute pass of 93 per second or 33.6 MBps, more than twice the average and significantly higher than yesterday. That's a rate of 8million per day.]
[Update2: Alright, the guy is now getting media coverage on TV and other sources. He's officially being called The eBay Wedding Dress Guy. The hits appear to be rolling even faster. At 11:17, I saw 4,073,693. That's up over 500k from the earlier update. 4,092,881 two minutes later, rolling at a rate of 57.8 MBps. And yes, all of these bandwidth rates are in mega_bytes_ per second. Certainly, eBay servers are very distributed to be able to handle such loads.]
February 9, 2004
Fuzzy math?
Joshua Claybourn's Domain: Meet the Numbers
But maybe not so...
This from my comment here.
On the budget, it is interesting to note that social security, at 510B is larger than defense at 429B and the rest of discretionary at 485B and that of the three, only defense has gone down (from 433B in the current year). This table has all the facts. The other docs are here. Perhaps his math score was even lower than his language score? But actually, if you look at Table S-12, it's clear the discretionary budget is increasing from 908 to 914, or 0.66% (the previous increase was 9.9%, but who's counting?) However, Table S-2 clearly shows the discretionary budget going from 787 to 818, a 3.9% increase, as the table accurately shows. Unless you include supplementals ... which have gone where?
Maybe someone else can clear this up...
