If you're talking about DBMS stuff, sure. Otherwise, probably not. but remember, that if you put in another memory controller, then you have a *lot* more pins out of the chip, the motherboard design becomes more expensive, and more cramped. that doesn't mean that it can't be done, just that it's not necessarily cost-effective.
Manufacturing technology has progressed to where many more transistors can be cost-effectively packed onto a chip than years ago. Yet, all of the low-hanging fruit in CPU design was picked long, long ago, and so was the medium-hanging fruit. It takes vastly more to get a significant improvement out of a new architecture now than it did ten years ago.
So, packing more cores onto a chip allows you to fill your die with working transistors, and doesn't cost you billions in R&D.
Interestingly enough, Intel has always enjoyed the better manufacturing technology, and hence was in a position to go dual- or quad-core before AMD, but was lazy enough that it didn't look to the future, and its cores weren't really designed for that. AMD went out on a limb, and designed the Athlon64/Opteron to work *really* well at multi-core well before the manufacturing technology was in place, and it paid off handsomely for them.
Unfortunately, Intel is finally starting to pull its head from it's rectal cavity, and if Intel and AMD were to throw the same amount of ingenuity at the problem, the greater financial and manufacturing capability of Intel would mean bad news for AMD.
"I suspect for the desktop market we'll all see that having four cores does not improve most application performance significantly because it does not ameliorate the normal bottlenecks...
Yes, but very few people buy Opterons for the desktop market. I'm sure that a good number get sold for the "workstation" market (CAD, rendering, etc.), but not as desktops.
The real strength of the Opterons has been in DBMS servers, where the massive memory bandwidth from having 2, 4, or 8 memory controllers has really kicked the pants off of the shared-bus Xeons. However, going dual-core in bandwidth-critical situations can actually somewhat hinder performance, and going quad-core would probably be worse. These quad-cores will best fit the market where CPU cycles are mostly all that matter. SETI, rendering, etc..
Bombard it with energy, and measure the reaction seconds later? For some reason, an image keeps popping into my head of putting the substance in a 1.5-kilowatt microwave, zapping it for five seconds, and seeing if it explodes or not.
I guess there would have to be some blast deflectors around the microwave.
I listened to a radio interview with the designer of this saw some time ago. He mentioned that none of the major tool manufacturers would integrate this into their saws because of the added cost of production.
He then went on to quote the monetary costs to the tool manufacturers arising from injuries from the use of table saws... and it significantly exceeded the cost of simply fitting all of their table saws with this technology *without passing the cost to the consumer*. Crazy.
This technology can help people escape poverty. Not long ago, I listend to an interview about the cellular phone networks in... some African nation. One where there's enough violence that the cellular companies won't go in there - the country built it itself. He talked about how much of a benefit it has had on the local economy - and not just because it gave the small, mom-and-pop shops run out of houses something (cell cards) to sell, but because it allowed rural farmers to find markets for their crops besides the (often dishonest) middlemen who came to them. It's benefiting the rich, yes, but the poor are benefiting more.
I think that this might just work along those lines as well.
I'd like to see a movie theater where the tickets are $20 each. But you get to sit in a nice, comfortable recliner, without having to play "Elbow Wars" for the armrest, get kicked in the back by someone, or have to smell the breath of the person next to you. Shoot, make it $25, and have someone come around and refill your popcorn for you. I'll pay.
At least not for me. I used to be pretty darn high in the SETI rankings, having quite a number of machines at my disposal. But after a lot of thought, I decided to shut off all of the clients for good.
You see, consuming those extra tens of kilowatts means more pollution, and around here, more consumption of non-renewable resources. Between the low possibility of finding a remote signal, and the imminant possibility of crapping up the environment (MY environment, my local environment) long before anything could be done about the signal, I chose to try and keep this place clean.
Not only do the CPUs consume less energy without being fully loaded, with cool-n-quiet, they can consume MUCH less. And the building AC runs less to keep the place cool. Now, does this make a huge difference? I don't know. I still drive to work each day - alone in my car, as there isn't a public transit option, and I don't work the same hours as anyone else, and I still run an air conditioner all day long to keep my house cool for me, the wife, kid, and dogs.
I suppose that for a really good cause, like folding@home, I might feel alright about it. But for now, I like having the place quiet, and the electrical draw low.
Just because AT&T and L3 are tier-1 doesn't mean that everything they do is cluefull. Look at the recent hub-bub where AT&T has been trying to demand money from Google to pass their packets. You seem to have been carefully avoiding that.
Now, if Google *does* pay L3 for it's transit, then yes, it makes sense. But unless you have proof that they do, then we can't take that for granted.
Most networks with which I work are more than happy to peer with Google, even though the balance of packets is odd - they know that it will get packets to the endpoint more quickly, make their customers happy, and cost them less than paying someone else for transit to Google. If incurring more latency and costing more money is your idea of cluefull just because some other company is doing it, that's your problem.
It's also common knowledge that the standard peering agreements are there for the schmucks and small-time operators - and that big boys get to negotiate.
Doing a traceroute from several of Qwest's looking glasses, it appears that the packets are handed off directly to Qwest.
Tracing from one of Sprint's, it goes directly to Google again. Reverse DNS on one hop resolves to supernews.net, but the IP is a Sprint IP.
Adelphia hands it right to google.
Cogent hands it right to google.
Electric Lightwave hands it right to google.
Abovenet hands it right to google.
Broadwing hands it right to google.
I could go on, but I'm tired of looking. Either all of those providers are, in fact, peered with google as cluefull networks usually are, or Google is paying all of them for transit - which I find highly unlikely. Google isn't a Joe in an office shopping around for a DS-3.
Again, just because AT&T doesn't peer with google doesn't mean that's a smart decision.
"don't understand the difference between peering and transit."
Uh... maybe you missed the part where I specifically said *non-transit* peering. Maybe you should look more closely. Under my assertion that they probably have a non-transit peering arrangement with L3, then unless someone is taking advantage of poor routing filters, then *someone* paid L3 to accept a packet. Once L3 has that packet, they want to get rid of it, so they hand it off to Google via their peering arrangement, and Google doesn't pay anything for it, beside the cost of maintaining their equipment.
Now, the question is this: Why did AT&T hand it off to L3? That's a mystery. Presumably, L3 isn't going to accept any transit packets from AT&T without getting paid, so you have to ask yourself why AT&T would have to pay someone else to hand a packet to Google. If AT&T were smart, they'd have a peering arrangement, but from the spat that AT&T is going through with Google at the moment over AT&T demanding extortion money, perhaps there's just some bad blood.
In any event, the way it's happening in your traceroute isn't the optimal way, and it's not how all networks are run.
"No, they will not. Under a normal settlement-free peering (SFP) arrangement, Level3 would happily hand of packets destined for Google if those packets originated from a Level3 customer."
Realistically, if a packet destined for Google is on L3's network, they're going to hand it to Google at a peering point, if they have one, because if they're smart, they don't want to pay someone else to hand it off to Google. It gets the packet where it needs to go, costs them virtually nothing, and it's done with.
Just because AT&T does things screwy doesn't mean that's how every other network does it. On every decent network from which I've ever done a traceroute, it's been handed off directly to Google. The resolution between what you said and what I said is that pretty much every packet on L3's network destined for google already came from someone paying L3 to deliver that packet, because as you pointed out, they're not going to accept transit packets from non-paying customers.
"Thus, I kind of doubt that Level3 peers with Google, as Level3 obviously provides transit services to Google."
While I'm not privy to all of their dealings, from what I have heard of Google's infrastructure, I find it unlikely that they do provide transit in any significant amount. Just why L3 and AT&T are doing things that way is unknown to me, but that's not how cluefull networks typically operate. They want to get rid of the packet as quickly and cheaply as they can. That's why everyone wants to be in the "big-time" peering locations.
Non-transit peering generally involves no payment, just a written agreement, and a cable stretched between two routers already located in the same building. Look up the definition of "fee", and you'll see that it does not in any way fit that situation. Sorry, but who, exactly, is the moron?
No, that means that *your* ISP is paying for transit costs. Just because Google receives the packet doesn't mean that they've paid, I can't imagine that they don't have a peering arrangement with L3.
And yes, L3 will happily hand any packets destined for Google off to Google for free. They've made their money from their customers who paid to *send* the packet to Google. And it keeps them from having to pay someone else to get the packet to Google.
It's nothing unique, that's how *all* of the really big players handle it.
"How is Google "freeloading"? Paying $millions in ISP fees every year is now called "freeloading"?"
I don't think that Google pays much - if anything - in "ISP fees". They don't go out to some ISP and buy a bunch of OC-whatevers. They buy their own fiber, and have non-transit peering arrangements with all of the major ISPs, and many of the smaller ones as well. Because of that, they're able to hand off packets to the destination network without having to pay an upstream "default gateway" ISP.
Now, I'm sure that moving all those packets costs them a pretty penny, but calling them "ISP fees" doesn't quite fit.
Apart from programmer/developpers, you'd be surprised at how many people in medium to large corporations run as non-priveliged users.
Once you make users non-priveliged, a *HUGE* number of support problems go away. Before I handed off desktop support to an assistant, people would often come to me and ask for admin privs. Everyone who asks for admin priveliges will swear upon everything that they find holy that *they* would never cause any problems. Like prisoners, they're *all* innocent. And yet, without the admin rights, things go sooooo much more smoothly.
I've had fans fail on AMDs and Xeons. None of them have ever been damaged. Oh, wait... you must be a Tom's Hardware fanboy. I recall he put out the FUD about Athlons catching on fire. That might have been true five years ago, but isn't today.
A few months ago, I had a dual-AthlonMP server fall out of a rack, and keep running. One of the heat sinks *came off*. Not just a failed fan, a missing heat sink. That did ruin the CPU... but there was no fire, no theatrics, and the motherboard is just fine.
Even though both AMD and Intel both have thermal throttling, the AMDs produce less heat, so they're better equipped to survive a fan failure than the Intels.
Even somewhat modest CPUs can produce up to 100 watts of heat, and the top Intels can hit over 150 watts. (As an aside, the Mobile AthlonXP that I'm running on as I type this has a *max* draw of something like 35 watts.)
Your power supply doesn't produce most of the heat, it will produce a fraction of what the rest of your computer does. Maybe somewhere around 25%, but it could be lower or higher depending on the load.
The AMDs definitely sip less power than the Pentium-Ds. In fact, recently we built a good number of machines (A64/3200, 1 gig, 250g HD, GF 6200tc), and wanted to size out some UPS units. We plugged a sample machine and a 19" flat panel into a power meter, and went through bootup, normal usage, and shutdown. The highest draw we ever recorded (which was fairly brief) was only about 140 watts. Under normal office usage, it generally stayed at or below 100 watts. That's including about 30 watts for the flat panel, and losses in the power supplies!
I haven't put the meter on the P-D machines yet (hopefully I'll remember tomorrow), but I can say that even compared to the 3800 X2s, the 805 DEFINITELY pumps more heat out the back of the machine. The cases have 120mm fans blowing a good bit of air, so the machines don't overheat... the poor schmucks sitting at those cubicles just get sweaty legs.
Instead of Athlon64+ 3200 and X2 3800s, we built a few machines at the office with P-D 805s. Every user has complained about how hot it gets under their desk with the machines. You reach down and put your arm under the desk, and it's like a sauna. We haven't had any complaints with the AMDs.
Because now that AMD's chips have SSE 1/2/3 hardware, using Intel's compiler often results in speed increases on AMD chips as well. It doesn't help Intel if AMD gets the same boost!
Is the holdup really the hardware? I don't do a ton of phone stuff, but from the passing experience I've had with several phone systems, they're nothing more than a number of PRI interfaces, ports for the phones, a general-purpose CPU, and a hard drive. And many require another machine (usually a Windows machine) to run all of the IVR, voice mail, and every other feature. In other words, nearly everything is done in software on relatively general-purpose hardware.
Digium makes the interfaces, and there are plenty of IP telephones, so that takes care of the in and out, at least to some extent. It seems to me that there's at least a decent start at the hardware, and it's the software features that now have to pull the load. Am I wrong?
It does seem odd at first glance, but look at the current CPU market: AMD is taking significant market share from Intel, and the lucrative part at that. When AMD released the Opteron, they cought Intel with their pants - and shorts - down, and Intel is still trying to come up with a viable response. They've been grasping around for anything to try and get numbers back up.
So... being a good bedfellow of Intel, Microsoft kindly delayed the release of a 64-bit OS for quite some time, until Intel had a 64-bit chip ready as well. The thinking was that without a OS that used the 64-bitness, extra registers, and had a scheduler that understood the complexities of obtaining maximum performance out of a NUMA architecture, the Opteron would surely turn out to be a flop. Right?
Wrong. They forgot about Linux. Linux could already support 64 bits, and IBM had poured some VERY significant NUMA experience and technology into Linux. Linux completely carried the Opteron sales for at least the first year. It might have been two, but I don't recall off of the top of my head.
So... here's Intel right now, trying desperately to find a way to at least stop the bleeding on the high-end server market. It's not far-fetched to think that they said "Hey... Linux carried the Opteron, and has worked against us. It's helped AMD and IBM, maybe we should jump on that train, too."
Of course, that attributes much more intelligence to Intel's decision-makers than they have hitherto demonstrated, but it's possible.
In my office, the DBA and I have cubicles in the programmer's row so that we can communicate more efficiently with the programmers. The "front" of our cubicles (where the door is) faces large windows, and the back wall keeps the noise out. We get along pretty well, and felt like some openness and light, so we took down the wall between our cubicles. Then we took the front walls off, and replaced them with half-height walls, and one shared doorway. We built some short saloon-style swinging doors for the doorway, and put some potted plants along the inside of the half-height front wall.
The result has a very spacious, open, and even "friendly" feel to it. Programmers can just stop on the other side of the half-height wall for a quick question, or come in and sit down if it's a longer discussion. And the poor saps that have to sit over in the rat-maze of high-density, full-height cubicles with nothing but fluorescent light come over and hang out just to avoid depression.
A couple of years ago, I lucked into a free microwave. And a year ago, a family member for whom I've done a few favors gave me a small refrigerator. I swear, all the place needs now is a crapper.
"Actually, I am an engineer. In the telecom industry. Working for a Cisco competitor."
If you have a piece of paper from your state that says that you're a PE, then of course you're an engineer. If all you did was pass some "pay-me, pay-me!" certification exam with the word "engineer" in the title, then you're kidding yourself.
"You pointed out yourself that they have fewer fans. Obviously, entirely passive cooling is impossible."
No, I pointed out cases where there was *one* fan, not just fewer. Entirely passive cooling isn't impossible by any means, there are plenty of examples. But it's hard to make really powerful routers (of either flavor) completely fanless.
"Are they actually monitored? Are you going to get advance warning before something dies?"
Yep. It's not hard. Most distros come with all of the packages you need to monitor fans, temperatures, disks, etc. pre-installed. You can have as much advance warning as is possible based on the sensors in your particular system. Maybe Cisco has some fancier sensors.:-)
"if you have ten disks, the MTBF on those is going to be rather low. There's a good reason routers don't have disks."
Well... I disagree in some regards. First, the machine that I mention has twenty programmers flogging away untested code on it, handles FTP, samba, relational databases, email, web serving, DNS, and several other tasks. The kind of abuse that it suffers isn't really easy on an operating system. I've had it for about 7 years now. It was rebooted the first month to replace a faulty RAID card, and after that, it ran without reboot for about 3 years as an RDBMS machine. Then it was relegated to the code-monkies's flogging-victim, and since then, the only reboots have been for kernel upgrades or power issues (it's no longer in the data center, backed up by a generator). My Linux-based routers, on the other hand, have just sat there and worked. About a month ago, I was showing a new employee our servers, and couldn't even remember which machine *was* our core router, I put it in place and haven't looked at (or for) it since.
As for the disks, you'd be surprised how well good SCSI disks can do. Out of 10 drives that have been in place for about 7 years, we just lost the second one recently. And you're right, routers don't usually have disks. I've stuck a CF card into an IDE adapter, and there you go, diskless PC. And because a router only needs a write when a configuration is changed, it's not hard to make that happen on a PC.
"What chassis do you use? Because I have never seen a rackmount PC that can have its fans replaced without pulling it out."
Well, the "without pulling it out" is somewhat true. But if you're telling me that every Cisco can have any fan (or power supply) replaced without pulling it out of the rack, I don't think that's the case. And while it's a bit "seat of your pants" (or, as you would say, "russian roulette"), my servers are on rails, I can slide *most* of them forward, remove the lid, replace fans, and be done.
"Yeah, right. It's pretty obvious you are still in college. Either that or you like to play russian roulette with your network."
First, let me apologize for the "lick my sack" comment. I was out of line. No, I'm not in college any more, and as for the russian roulette, it's a bit of an exageration, but I do look at risks, benefits, and payoffs. I go to the CFO, and present him likely and worst-case scenarios of failures, and give him time, impact, and cost estimates. Then he, I, and the VP of the company sit down and figure out what makes the most sense.
As I'm sure that a certified person such as yourself is aware, once you get above 99.9%, costs start shooting up a *lot*. Try to get past 99.99%, and things really get pricy. And with the level of uptime adn performance we've had over the 7-year run of the
If you're talking about DBMS stuff, sure. Otherwise, probably not. but remember, that if you put in another memory controller, then you have a *lot* more pins out of the chip, the motherboard design becomes more expensive, and more cramped. that doesn't mean that it can't be done, just that it's not necessarily cost-effective.
Manufacturing technology has progressed to where many more transistors can be cost-effectively packed onto a chip than years ago. Yet, all of the low-hanging fruit in CPU design was picked long, long ago, and so was the medium-hanging fruit. It takes vastly more to get a significant improvement out of a new architecture now than it did ten years ago.
So, packing more cores onto a chip allows you to fill your die with working transistors, and doesn't cost you billions in R&D.
Interestingly enough, Intel has always enjoyed the better manufacturing technology, and hence was in a position to go dual- or quad-core before AMD, but was lazy enough that it didn't look to the future, and its cores weren't really designed for that. AMD went out on a limb, and designed the Athlon64/Opteron to work *really* well at multi-core well before the manufacturing technology was in place, and it paid off handsomely for them.
Unfortunately, Intel is finally starting to pull its head from it's rectal cavity, and if Intel and AMD were to throw the same amount of ingenuity at the problem, the greater financial and manufacturing capability of Intel would mean bad news for AMD.
steve
"I suspect for the desktop market we'll all see that having four cores does not improve most application performance significantly because it does not ameliorate the normal bottlenecks...
Yes, but very few people buy Opterons for the desktop market. I'm sure that a good number get sold for the "workstation" market (CAD, rendering, etc.), but not as desktops.
The real strength of the Opterons has been in DBMS servers, where the massive memory bandwidth from having 2, 4, or 8 memory controllers has really kicked the pants off of the shared-bus Xeons. However, going dual-core in bandwidth-critical situations can actually somewhat hinder performance, and going quad-core would probably be worse. These quad-cores will best fit the market where CPU cycles are mostly all that matter. SETI, rendering, etc..
Bombard it with energy, and measure the reaction seconds later? For some reason, an image keeps popping into my head of putting the substance in a 1.5-kilowatt microwave, zapping it for five seconds, and seeing if it explodes or not.
I guess there would have to be some blast deflectors around the microwave.
steve
I listened to a radio interview with the designer of this saw some time ago. He mentioned that none of the major tool manufacturers would integrate this into their saws because of the added cost of production.
He then went on to quote the monetary costs to the tool manufacturers arising from injuries from the use of table saws... and it significantly exceeded the cost of simply fitting all of their table saws with this technology *without passing the cost to the consumer*. Crazy.
This technology can help people escape poverty. Not long ago, I listend to an interview about the cellular phone networks in... some African nation. One where there's enough violence that the cellular companies won't go in there - the country built it itself. He talked about how much of a benefit it has had on the local economy - and not just because it gave the small, mom-and-pop shops run out of houses something (cell cards) to sell, but because it allowed rural farmers to find markets for their crops besides the (often dishonest) middlemen who came to them. It's benefiting the rich, yes, but the poor are benefiting more.
I think that this might just work along those lines as well.
This will give those poor, starving families a chance to make money running "Nigerian" schemes. :)
steve
I'd like to see a movie theater where the tickets are $20 each. But you get to sit in a nice, comfortable recliner, without having to play "Elbow Wars" for the armrest, get kicked in the back by someone, or have to smell the breath of the person next to you. Shoot, make it $25, and have someone come around and refill your popcorn for you. I'll pay.
steve
I agree. Let's make them swim naked.
At least not for me. I used to be pretty darn high in the SETI rankings, having quite a number of machines at my disposal. But after a lot of thought, I decided to shut off all of the clients for good.
You see, consuming those extra tens of kilowatts means more pollution, and around here, more consumption of non-renewable resources. Between the low possibility of finding a remote signal, and the imminant possibility of crapping up the environment (MY environment, my local environment) long before anything could be done about the signal, I chose to try and keep this place clean.
Not only do the CPUs consume less energy without being fully loaded, with cool-n-quiet, they can consume MUCH less. And the building AC runs less to keep the place cool. Now, does this make a huge difference? I don't know. I still drive to work each day - alone in my car, as there isn't a public transit option, and I don't work the same hours as anyone else, and I still run an air conditioner all day long to keep my house cool for me, the wife, kid, and dogs.
I suppose that for a really good cause, like folding@home, I might feel alright about it. But for now, I like having the place quiet, and the electrical draw low.
Just because AT&T and L3 are tier-1 doesn't mean that everything they do is cluefull. Look at the recent hub-bub where AT&T has been trying to demand money from Google to pass their packets. You seem to have been carefully avoiding that.
Now, if Google *does* pay L3 for it's transit, then yes, it makes sense. But unless you have proof that they do, then we can't take that for granted.
Most networks with which I work are more than happy to peer with Google, even though the balance of packets is odd - they know that it will get packets to the endpoint more quickly, make their customers happy, and cost them less than paying someone else for transit to Google. If incurring more latency and costing more money is your idea of cluefull just because some other company is doing it, that's your problem.
It's also common knowledge that the standard peering agreements are there for the schmucks and small-time operators - and that big boys get to negotiate.
Doing a traceroute from several of Qwest's looking glasses, it appears that the packets are handed off directly to Qwest.
Tracing from one of Sprint's, it goes directly to Google again. Reverse DNS on one hop resolves to supernews.net, but the IP is a Sprint IP.
Adelphia hands it right to google.
Cogent hands it right to google.
Electric Lightwave hands it right to google.
Abovenet hands it right to google.
Broadwing hands it right to google.
I could go on, but I'm tired of looking. Either all of those providers are, in fact, peered with google as cluefull networks usually are, or Google is paying all of them for transit - which I find highly unlikely. Google isn't a Joe in an office shopping around for a DS-3.
Again, just because AT&T doesn't peer with google doesn't mean that's a smart decision.
steve
steve
"don't understand the difference between peering and transit."
Uh... maybe you missed the part where I specifically said *non-transit* peering. Maybe you should look more closely. Under my assertion that they probably have a non-transit peering arrangement with L3, then unless someone is taking advantage of poor routing filters, then *someone* paid L3 to accept a packet. Once L3 has that packet, they want to get rid of it, so they hand it off to Google via their peering arrangement, and Google doesn't pay anything for it, beside the cost of maintaining their equipment.
Now, the question is this: Why did AT&T hand it off to L3? That's a mystery. Presumably, L3 isn't going to accept any transit packets from AT&T without getting paid, so you have to ask yourself why AT&T would have to pay someone else to hand a packet to Google. If AT&T were smart, they'd have a peering arrangement, but from the spat that AT&T is going through with Google at the moment over AT&T demanding extortion money, perhaps there's just some bad blood.
In any event, the way it's happening in your traceroute isn't the optimal way, and it's not how all networks are run.
"No, they will not. Under a normal settlement-free peering (SFP) arrangement, Level3 would happily hand of packets destined for Google if those packets originated from a Level3 customer."
Realistically, if a packet destined for Google is on L3's network, they're going to hand it to Google at a peering point, if they have one, because if they're smart, they don't want to pay someone else to hand it off to Google. It gets the packet where it needs to go, costs them virtually nothing, and it's done with.
Just because AT&T does things screwy doesn't mean that's how every other network does it. On every decent network from which I've ever done a traceroute, it's been handed off directly to Google. The resolution between what you said and what I said is that pretty much every packet on L3's network destined for google already came from someone paying L3 to deliver that packet, because as you pointed out, they're not going to accept transit packets from non-paying customers.
"Thus, I kind of doubt that Level3 peers with Google, as Level3 obviously provides transit services to Google."
While I'm not privy to all of their dealings, from what I have heard of Google's infrastructure, I find it unlikely that they do provide transit in any significant amount. Just why L3 and AT&T are doing things that way is unknown to me, but that's not how cluefull networks typically operate. They want to get rid of the packet as quickly and cheaply as they can. That's why everyone wants to be in the "big-time" peering locations.
steve
Non-transit peering generally involves no payment, just a written agreement, and a cable stretched between two routers already located in the same building. Look up the definition of "fee", and you'll see that it does not in any way fit that situation. Sorry, but who, exactly, is the moron?
steve
No, that means that *your* ISP is paying for transit costs. Just because Google receives the packet doesn't mean that they've paid, I can't imagine that they don't have a peering arrangement with L3.
And yes, L3 will happily hand any packets destined for Google off to Google for free. They've made their money from their customers who paid to *send* the packet to Google. And it keeps them from having to pay someone else to get the packet to Google.
It's nothing unique, that's how *all* of the really big players handle it.
steve
"How is Google "freeloading"? Paying $millions in ISP fees every year is now called "freeloading"?"
I don't think that Google pays much - if anything - in "ISP fees". They don't go out to some ISP and buy a bunch of OC-whatevers. They buy their own fiber, and have non-transit peering arrangements with all of the major ISPs, and many of the smaller ones as well. Because of that, they're able to hand off packets to the destination network without having to pay an upstream "default gateway" ISP.
Now, I'm sure that moving all those packets costs them a pretty penny, but calling them "ISP fees" doesn't quite fit.
steve
Apart from programmer/developpers, you'd be surprised at how many people in medium to large corporations run as non-priveliged users.
Once you make users non-priveliged, a *HUGE* number of support problems go away. Before I handed off desktop support to an assistant, people would often come to me and ask for admin privs. Everyone who asks for admin priveliges will swear upon everything that they find holy that *they* would never cause any problems. Like prisoners, they're *all* innocent. And yet, without the admin rights, things go sooooo much more smoothly.
steve
Why not?
I've had fans fail on AMDs and Xeons. None of them have ever been damaged. Oh, wait... you must be a Tom's Hardware fanboy. I recall he put out the FUD about Athlons catching on fire. That might have been true five years ago, but isn't today.
A few months ago, I had a dual-AthlonMP server fall out of a rack, and keep running. One of the heat sinks *came off*. Not just a failed fan, a missing heat sink. That did ruin the CPU... but there was no fire, no theatrics, and the motherboard is just fine.
Even though both AMD and Intel both have thermal throttling, the AMDs produce less heat, so they're better equipped to survive a fan failure than the Intels.
Steve
Even somewhat modest CPUs can produce up to 100 watts of heat, and the top Intels can hit over 150 watts. (As an aside, the Mobile AthlonXP that I'm running on as I type this has a *max* draw of something like 35 watts.)
Your power supply doesn't produce most of the heat, it will produce a fraction of what the rest of your computer does. Maybe somewhere around 25%, but it could be lower or higher depending on the load.
steve
The AMDs definitely sip less power than the Pentium-Ds. In fact, recently we built a good number of machines (A64/3200, 1 gig, 250g HD, GF 6200tc), and wanted to size out some UPS units. We plugged a sample machine and a 19" flat panel into a power meter, and went through bootup, normal usage, and shutdown. The highest draw we ever recorded (which was fairly brief) was only about 140 watts. Under normal office usage, it generally stayed at or below 100 watts. That's including about 30 watts for the flat panel, and losses in the power supplies!
I haven't put the meter on the P-D machines yet (hopefully I'll remember tomorrow), but I can say that even compared to the 3800 X2s, the 805 DEFINITELY pumps more heat out the back of the machine. The cases have 120mm fans blowing a good bit of air, so the machines don't overheat... the poor schmucks sitting at those cubicles just get sweaty legs.
steve
Instead of Athlon64+ 3200 and X2 3800s, we built a few machines at the office with P-D 805s. Every user has complained about how hot it gets under their desk with the machines. You reach down and put your arm under the desk, and it's like a sauna. We haven't had any complaints with the AMDs.
Because now that AMD's chips have SSE 1/2/3 hardware, using Intel's compiler often results in speed increases on AMD chips as well. It doesn't help Intel if AMD gets the same boost!
steve
Is the holdup really the hardware? I don't do a ton of phone stuff, but from the passing experience I've had with several phone systems, they're nothing more than a number of PRI interfaces, ports for the phones, a general-purpose CPU, and a hard drive. And many require another machine (usually a Windows machine) to run all of the IVR, voice mail, and every other feature. In other words, nearly everything is done in software on relatively general-purpose hardware.
Digium makes the interfaces, and there are plenty of IP telephones, so that takes care of the in and out, at least to some extent. It seems to me that there's at least a decent start at the hardware, and it's the software features that now have to pull the load. Am I wrong?
It does seem odd at first glance, but look at the current CPU market: AMD is taking significant market share from Intel, and the lucrative part at that. When AMD released the Opteron, they cought Intel with their pants - and shorts - down, and Intel is still trying to come up with a viable response. They've been grasping around for anything to try and get numbers back up.
So... being a good bedfellow of Intel, Microsoft kindly delayed the release of a 64-bit OS for quite some time, until Intel had a 64-bit chip ready as well. The thinking was that without a OS that used the 64-bitness, extra registers, and had a scheduler that understood the complexities of obtaining maximum performance out of a NUMA architecture, the Opteron would surely turn out to be a flop. Right?
Wrong. They forgot about Linux. Linux could already support 64 bits, and IBM had poured some VERY significant NUMA experience and technology into Linux. Linux completely carried the Opteron sales for at least the first year. It might have been two, but I don't recall off of the top of my head.
So... here's Intel right now, trying desperately to find a way to at least stop the bleeding on the high-end server market. It's not far-fetched to think that they said "Hey... Linux carried the Opteron, and has worked against us. It's helped AMD and IBM, maybe we should jump on that train, too."
Of course, that attributes much more intelligence to Intel's decision-makers than they have hitherto demonstrated, but it's possible.
In my office, the DBA and I have cubicles in the programmer's row so that we can communicate more efficiently with the programmers. The "front" of our cubicles (where the door is) faces large windows, and the back wall keeps the noise out. We get along pretty well, and felt like some openness and light, so we took down the wall between our cubicles. Then we took the front walls off, and replaced them with half-height walls, and one shared doorway. We built some short saloon-style swinging doors for the doorway, and put some potted plants along the inside of the half-height front wall.
The result has a very spacious, open, and even "friendly" feel to it. Programmers can just stop on the other side of the half-height wall for a quick question, or come in and sit down if it's a longer discussion. And the poor saps that have to sit over in the rat-maze of high-density, full-height cubicles with nothing but fluorescent light come over and hang out just to avoid depression.
A couple of years ago, I lucked into a free microwave. And a year ago, a family member for whom I've done a few favors gave me a small refrigerator. I swear, all the place needs now is a crapper.
"Actually, I am an engineer. In the telecom industry. Working for a Cisco competitor."
:-)
If you have a piece of paper from your state that says that you're a PE, then of course you're an engineer. If all you did was pass some "pay-me, pay-me!" certification exam with the word "engineer" in the title, then you're kidding yourself.
"You pointed out yourself that they have fewer fans. Obviously, entirely passive cooling is impossible."
No, I pointed out cases where there was *one* fan, not just fewer. Entirely passive cooling isn't impossible by any means, there are plenty of examples. But it's hard to make really powerful routers (of either flavor) completely fanless.
"Are they actually monitored? Are you going to get advance warning before something dies?"
Yep. It's not hard. Most distros come with all of the packages you need to monitor fans, temperatures, disks, etc. pre-installed. You can have as much advance warning as is possible based on the sensors in your particular system. Maybe Cisco has some fancier sensors.
"if you have ten disks, the MTBF on those is going to be rather low. There's a good reason routers don't have disks."
Well... I disagree in some regards. First, the machine that I mention has twenty programmers flogging away untested code on it, handles FTP, samba, relational databases, email, web serving, DNS, and several other tasks. The kind of abuse that it suffers isn't really easy on an operating system. I've had it for about 7 years now. It was rebooted the first month to replace a faulty RAID card, and after that, it ran without reboot for about 3 years as an RDBMS machine. Then it was relegated to the code-monkies's flogging-victim, and since then, the only reboots have been for kernel upgrades or power issues (it's no longer in the data center, backed up by a generator). My Linux-based routers, on the other hand, have just sat there and worked. About a month ago, I was showing a new employee our servers, and couldn't even remember which machine *was* our core router, I put it in place and haven't looked at (or for) it since.
As for the disks, you'd be surprised how well good SCSI disks can do. Out of 10 drives that have been in place for about 7 years, we just lost the second one recently. And you're right, routers don't usually have disks. I've stuck a CF card into an IDE adapter, and there you go, diskless PC. And because a router only needs a write when a configuration is changed, it's not hard to make that happen on a PC.
"What chassis do you use? Because I have never seen a rackmount PC that can have its fans replaced without pulling it out."
Well, the "without pulling it out" is somewhat true. But if you're telling me that every Cisco can have any fan (or power supply) replaced without pulling it out of the rack, I don't think that's the case. And while it's a bit "seat of your pants" (or, as you would say, "russian roulette"), my servers are on rails, I can slide *most* of them forward, remove the lid, replace fans, and be done.
"Yeah, right. It's pretty obvious you are still in college. Either that or you like to play russian roulette with your network."
First, let me apologize for the "lick my sack" comment. I was out of line. No, I'm not in college any more, and as for the russian roulette, it's a bit of an exageration, but I do look at risks, benefits, and payoffs. I go to the CFO, and present him likely and worst-case scenarios of failures, and give him time, impact, and cost estimates. Then he, I, and the VP of the company sit down and figure out what makes the most sense.
As I'm sure that a certified person such as yourself is aware, once you get above 99.9%, costs start shooting up a *lot*. Try to get past 99.99%, and things really get pricy. And with the level of uptime adn performance we've had over the 7-year run of the