That can happen just about anywhere. You'd have to be down the road from a power plant to have any real assurance of power availability. (something Apple and Facebook, and the state of NC, have done. 'tho NC built their backup facility in Forest City which is a good distance from 3 plants, but on top of the new single turbine coal plant in Cliffside.)
They use ANI which is how 911 gets your number, which is not spoofable.
Oh yes it is. Buy a PRI from a phone company that lets you announce whatever number you want. The phone company is *supposed* to check what you send them, but I've never met one that will. The intended purpose is to announce a toll-free number, the pilot number, etc. instead of the trunk or line numbers.
And how the hell are they supposed to validate and enforce this? eBay never has the phone in their possession to check the numbers. One can enter any BS data they want.
In my experience, blows/fans fail more often than compressors and pumps.:-) (blowers run constantly, compressors shouldn't)
The preference in data center cooling is/has been to use "free cooling" through water/glycol loops when the outside air is cold enough to handle heat rejection on it's own. Otherwise, compressors are used to push heat into the same loop. It's becoming more trendy to place data centers in cooler climates where compressors are never needed; then stability can be maintained by precise mixing of inside and outside air. (some systems bring outside air into the room, others have air-to-air heat exchangers so outside air doesn't enter the room... less work to scrub that air.)
The room is sealed and managed by precision cooling equipment because we want a precisely controlled, stable environment. As long as the setpoint is within human comfort, the exact point is less important than keeping it at that point! Google's data has shown, *for them*, 80F is the optimal point for hardware longevity. (I've not seen anywhere that it's made a dent in their cooling bill.)
Yes and no. If the room is properly insulated, any heat generated in the room will have to be forcefully removed. At some point, the room will reach equilibrium -- heat will escape at the rate it's generated, but it will be EXTREMELY hot in there by then. Rate of thermal transfer is dependant on the difference in temperature; the larger the difference, the faster energy transfers. Raising the temp of the room will lead to higher equipment temps; until you do it, you won't know if you've made the difference better (wider) or worse (narrower).
The key finding from Google's research was that temperature stability was the most important factor. Fluctuating temperatures are very hard on machines -- esp. hard drives.
I once worked in an office building where the building would shut off the HVAC in the evenings and all day weekends... it would be 100F+ in there Sunday evening. (over 120 on 100 degree days.) Then they have tones of heat to dump come Monday morning; and all the while, they're destroying every piece of electronics in the building. (net cooling costs... they saved very little. add in replacing the damaged everything, and it cost them money.)
Have you seen the factories in China building your chips for factions of pennies each? What you design and test in your precise lab bears little resemblance to what is churned out of the factories. (and plugged into other cheap-as-dirt designs.) Stuff from a decade ago is still running strong; stuff built just last year is failing or has already failed. Reason: quality no longer matters; only cheap matters.
Also, the 3M heat sink tape has a lifespan of 3-5 years. At which point enough of the oils in that tape have escaped to compromise it's ability to transport heat. *poof* Your chip(s) start to burn up.
A) There are very few people actually within the data center on a daily basis. And when they are, 99% of the time, they're in the cold aisle. (Did you look at their hot aisle? You couldn't walk down it not matter what temp it is.) B) s/HVAC/CRAC/ then... there's no "H" (heating) involved. And little to no "V", either. And for the record, MANY HVAC systems use chilled water / evap. (hint: the one in this office is an evap unit.) [and many data centers use gycol as it caries more heat than pure water.]
That's a lot of it... it's easier to contain the heat. In the end, you'll get the same result: a closed loop system. On one side, there's the HVAC unit taking in hot air and pushing out cold air. On the other is the servers pulling in the cold air and venting hot air. The ideal setup ducts *all* of it. But that's ugly, expensive, and tedious to setup and maintain. A hot aisle system is the best compromise as one's cold air will naturally hug the floor and hot air the ceiling. All you need to do is keep the hot air from ever mixing with the cold on it's way to HVAC. You can do that by cold containment, but then you have to work out how to get the cold air everywhere you need it. Flooding the room with cold air is much easier (and cheaper.) [even with a raised floor, the further you get away from the chiller, the lower the air pressure gets.] And in the google/facebook setups, the air doesn't have to move very far at all -- through the rack, up the hot aisle, through the chiller, and cascade back down in front of the rack.
The difference is... with an analog signal, it was still watchable even with significant noise and/or low signal. With digital, there's a cliff; you either have enough signal to construct the data stream, or you don't, and without a near perfect, continuous data stream, there's no f'ing picture at all. You don't get a wavy picture, or snow; you get a blank screen.
Make that 100%. None, Zero, Nada. No TV on the market today has a cablecard slot. The CE manufacturers had enough of the bullshit continuous changing of the "standards" and crap cable companies bolted on outside the standards -- PPV, video on demand, iControl(tm), integrated guide data, switched digital video... Switched Digital Video (SDV) was the last straw. Without a Tuning Adapter, unidirectional cable devices (read: all 3rd party devices) are almost completely useless.
True, Exchange(tm) can do a great many things. On the whole, most people don't need most of it. The more gears you try to keep spinning, the more places you have for a wrench to fall. Around here, not a month goes by that something doesn't happen to the 3rd party smart phone integration parts (iOS, Android, and Blackberry are INDEPENDANT connectors.) [Windows phones can natively talk MAPI.]
Small office that places very little demand on it, I could see that. But you are a statistical anomaly on the very edge of the bell curve. (or you have very bad memory:-))
I've never seen a medium sized exchange (500-1000 users) system *not* have some sort of outage yearly, if not several times a year. And that's in companies that have multiple people who's entire job is to manage Exchange(tm). I seriously doubt those people are making work for themselves. (read: they don't need to.)
The network coverage at this point is almost negligible between carriers.
This is untrue -- unless you mean they all suck in some way. Your experience is highly dependant on the specific phone in use, the carrier, and the exact square foot of earth on which you're standing.
Class E *is* reserved space. That's why many devices refuse to allow those addresses.
Yes, a decade (plus) ago we could have wasted efforts to un-reserve that space -- and forcably reclaim all those legacy/8's. We'd still end up in exactly the same damned place... IPv4 address space isn't large enough for the global internet. The effort was instead devoted to creation of IP-ng (aka IPv6.) For all of the "designed by committee" mistakes, IPv6 is our solution. It's too god damn late to say it's trash and try to invent a new system.
The biggest failure of IP-ng is the complete lack of migration, transition, and interoperability. IPv4 and IPv6 are COMPLETELY different protocols. They might as well be Appletalk and IPX. They create to completely independant network. There is zero chance of ever getting the entire world to agree to drop v4 and go v6 at any set point. The largest sticking point here are US ISPs... they have v4 address space and their customers only want to get to v4 connected sites, thus there's zero pressure to deploy v6. (read: no consumer demand -- also zero consumer understanding) Even within the enterprise sector, there's little demand for IPv6; so again, the ISP has no pressure to support it. In fact, their plan for "the we day run out of IPv4" is carrier grade NAT, not IPv6. The IPv6 deployments of most US ISPs is a horrible joke -- AT&T's answer is 6rd - period, Legacy Bellsouth DSL... switch to Uverse: see previous answer, TWC? who knows as next to none of their customers have IPv6 connectivity, Comcast appears to be the only one headed in the right direction but at glacial speed.
IPv6 isn't an IPv4 bandaid, per se. It's a cement truck trying to pave over it. The quad-A record format was to allow v4 and v6 DNS to interoperate. One can resolve IPv6 addresses via a 100% IPv4 DNS system. It also means IPv4 only hosts can see IPv6 records ('tho they cannot talk to them.) Your suggestion would further isolate IPv6 within it's own DNS realm.
TL;DR IPv6 deployment is a matter of business need. As long as you have a v4 address and need to talk to other v4 hosts, there's no need for v6. This is the boat american companies are riding.
This has been debated as well. It would require reprogramming *every* internet connected device. Do I need to point out how many devices are in common use that no longer have any code support? These are devices that won't get IPv6 support either. So, given the choice of "upgrading the entire internet" for the short term gain of the class E space (best case, adds a few months) or deploying IPv6 -- which is, for better or worse, the solution -- we're f'ing deploying IPv6. No more g** d*** bandaids.
May be, but you've always had a PUBLIC IP address. When your ISP assigns you 192.168.38.45, how do you expect to connect to that from your hotel room? This is the problem parts of the world *already* face. Many APNIC ISPs have been deploying CGN for some time now. US cellphone networks have been known to do that as well. (99% of the time you won't notice.)
Simple... the dns lookup is for "example.com" -- that being the hostname. "ftp://" and "http://" are application specific protocols. There are dns SRV records, but as others have said, no ftp/http applications use them (currently.)
RAs and SLB (server load balancing [read: proxy]) NEXT
While having PI address space makes things cleaner, it's not something consumers can do. When the router sends a new RA with a different prefix, all the hosts should update their address instantly. (I've never actually tested that.)
Indeed. And it's been covered numerous times before. First off, reclaiming a single/8 will not make any measurable dent. There was a NANOG post a few months back from John Curran that pretty much was the last word. While there is *a lot* of address space that could be reclaimed, a) it would only prolong the inevitable, and b) it would take lenghtly, expensive legal fights to get it all back. ARIN's official stance is to accept any legacy blocks anyone wants to hand over, but they aren't even bothering to ask that any be returned.
(Honestly, you'd be an idiot to hand over something worth so much that's costing you absolutely zero.)
Turn on privacy extentions, which almost every modern OS does by default, and the EUI64 based addresses aren't used. Laptops that can connect via wired or wireless interfaces will have a different address based on what interface was used... undock your laptop and it's address changes and all of your connections drop. (Driver Magic(tm) aside)
Also, machines don't have MACs; interfaces have MACs. Many machines have multiple NICs and they're replacable. Even Sun eventually learned to stop that stupidity -- the hostid was used to generate a single MAC used by all interfaces; it was a bloody f'ing mess from day one.
Slashdot Mirror
That can happen just about anywhere. You'd have to be down the road from a power plant to have any real assurance of power availability. (something Apple and Facebook, and the state of NC, have done. 'tho NC built their backup facility in Forest City which is a good distance from 3 plants, but on top of the new single turbine coal plant in Cliffside.)
You'll need an old friend indeed, to find media that old.
I'll go look through my boxes, but I wouldn't bet on a) having that version, or b) the floppies it came on being readable.
They use ANI which is how 911 gets your number, which is not spoofable.
Oh yes it is. Buy a PRI from a phone company that lets you announce whatever number you want. The phone company is *supposed* to check what you send them, but I've never met one that will. The intended purpose is to announce a toll-free number, the pilot number, etc. instead of the trunk or line numbers.
And how the hell are they supposed to validate and enforce this? eBay never has the phone in their possession to check the numbers. One can enter any BS data they want.
In my experience, blows/fans fail more often than compressors and pumps. :-) (blowers run constantly, compressors shouldn't)
The preference in data center cooling is/has been to use "free cooling" through water/glycol loops when the outside air is cold enough to handle heat rejection on it's own. Otherwise, compressors are used to push heat into the same loop. It's becoming more trendy to place data centers in cooler climates where compressors are never needed; then stability can be maintained by precise mixing of inside and outside air. (some systems bring outside air into the room, others have air-to-air heat exchangers so outside air doesn't enter the room... less work to scrub that air.)
A) Temperature STABILITY!
B) Humidity.
The room is sealed and managed by precision cooling equipment because we want a precisely controlled, stable environment. As long as the setpoint is within human comfort, the exact point is less important than keeping it at that point! Google's data has shown, *for them*, 80F is the optimal point for hardware longevity. (I've not seen anywhere that it's made a dent in their cooling bill.)
Yes and no. If the room is properly insulated, any heat generated in the room will have to be forcefully removed. At some point, the room will reach equilibrium -- heat will escape at the rate it's generated, but it will be EXTREMELY hot in there by then. Rate of thermal transfer is dependant on the difference in temperature; the larger the difference, the faster energy transfers. Raising the temp of the room will lead to higher equipment temps; until you do it, you won't know if you've made the difference better (wider) or worse (narrower).
The key finding from Google's research was that temperature stability was the most important factor. Fluctuating temperatures are very hard on machines -- esp. hard drives.
I once worked in an office building where the building would shut off the HVAC in the evenings and all day weekends... it would be 100F+ in there Sunday evening. (over 120 on 100 degree days.) Then they have tones of heat to dump come Monday morning; and all the while, they're destroying every piece of electronics in the building. (net cooling costs... they saved very little. add in replacing the damaged everything, and it cost them money.)
Maybe because they're the ones *actually* building them??? A good bit of Cisco's hardware is built in China. (amung other places.)
Have you seen the factories in China building your chips for factions of pennies each? What you design and test in your precise lab bears little resemblance to what is churned out of the factories. (and plugged into other cheap-as-dirt designs.) Stuff from a decade ago is still running strong; stuff built just last year is failing or has already failed. Reason: quality no longer matters; only cheap matters.
Also, the 3M heat sink tape has a lifespan of 3-5 years. At which point enough of the oils in that tape have escaped to compromise it's ability to transport heat. *poof* Your chip(s) start to burn up.
A) There are very few people actually within the data center on a daily basis. And when they are, 99% of the time, they're in the cold aisle. (Did you look at their hot aisle? You couldn't walk down it not matter what temp it is.)
B) s/HVAC/CRAC/ then... there's no "H" (heating) involved. And little to no "V", either. And for the record, MANY HVAC systems use chilled water / evap. (hint: the one in this office is an evap unit.) [and many data centers use gycol as it caries more heat than pure water.]
That's a lot of it... it's easier to contain the heat. In the end, you'll get the same result: a closed loop system. On one side, there's the HVAC unit taking in hot air and pushing out cold air. On the other is the servers pulling in the cold air and venting hot air. The ideal setup ducts *all* of it. But that's ugly, expensive, and tedious to setup and maintain. A hot aisle system is the best compromise as one's cold air will naturally hug the floor and hot air the ceiling. All you need to do is keep the hot air from ever mixing with the cold on it's way to HVAC. You can do that by cold containment, but then you have to work out how to get the cold air everywhere you need it. Flooding the room with cold air is much easier (and cheaper.) [even with a raised floor, the further you get away from the chiller, the lower the air pressure gets.] And in the google/facebook setups, the air doesn't have to move very far at all -- through the rack, up the hot aisle, through the chiller, and cascade back down in front of the rack.
Hot Aisle Containment. Without it, yes, the cold air would be mixing with rising hot air.
The difference is... with an analog signal, it was still watchable even with significant noise and/or low signal. With digital, there's a cliff; you either have enough signal to construct the data stream, or you don't, and without a near perfect, continuous data stream, there's no f'ing picture at all. You don't get a wavy picture, or snow; you get a blank screen.
Make that 100%. None, Zero, Nada. No TV on the market today has a cablecard slot. The CE manufacturers had enough of the bullshit continuous changing of the "standards" and crap cable companies bolted on outside the standards -- PPV, video on demand, iControl(tm), integrated guide data, switched digital video... Switched Digital Video (SDV) was the last straw. Without a Tuning Adapter, unidirectional cable devices (read: all 3rd party devices) are almost completely useless.
True, Exchange(tm) can do a great many things. On the whole, most people don't need most of it. The more gears you try to keep spinning, the more places you have for a wrench to fall. Around here, not a month goes by that something doesn't happen to the 3rd party smart phone integration parts (iOS, Android, and Blackberry are INDEPENDANT connectors.) [Windows phones can natively talk MAPI.]
Small office that places very little demand on it, I could see that. But you are a statistical anomaly on the very edge of the bell curve. (or you have very bad memory :-))
I've never seen a medium sized exchange (500-1000 users) system *not* have some sort of outage yearly, if not several times a year. And that's in companies that have multiple people who's entire job is to manage Exchange(tm). I seriously doubt those people are making work for themselves. (read: they don't need to.)
CommuniGate. Google. Depends on where you draw the line for "complete".
This is untrue -- unless you mean they all suck in some way. Your experience is highly dependant on the specific phone in use, the carrier, and the exact square foot of earth on which you're standing.
Class E *is* reserved space. That's why many devices refuse to allow those addresses.
Yes, a decade (plus) ago we could have wasted efforts to un-reserve that space -- and forcably reclaim all those legacy /8's. We'd still end up in exactly the same damned place... IPv4 address space isn't large enough for the global internet. The effort was instead devoted to creation of IP-ng (aka IPv6.) For all of the "designed by committee" mistakes, IPv6 is our solution. It's too god damn late to say it's trash and try to invent a new system.
The biggest failure of IP-ng is the complete lack of migration, transition, and interoperability. IPv4 and IPv6 are COMPLETELY different protocols. They might as well be Appletalk and IPX. They create to completely independant network. There is zero chance of ever getting the entire world to agree to drop v4 and go v6 at any set point. The largest sticking point here are US ISPs... they have v4 address space and their customers only want to get to v4 connected sites, thus there's zero pressure to deploy v6. (read: no consumer demand -- also zero consumer understanding) Even within the enterprise sector, there's little demand for IPv6; so again, the ISP has no pressure to support it. In fact, their plan for "the we day run out of IPv4" is carrier grade NAT, not IPv6. The IPv6 deployments of most US ISPs is a horrible joke -- AT&T's answer is 6rd - period, Legacy Bellsouth DSL... switch to Uverse: see previous answer, TWC? who knows as next to none of their customers have IPv6 connectivity, Comcast appears to be the only one headed in the right direction but at glacial speed.
IPv6 isn't an IPv4 bandaid, per se. It's a cement truck trying to pave over it. The quad-A record format was to allow v4 and v6 DNS to interoperate. One can resolve IPv6 addresses via a 100% IPv4 DNS system. It also means IPv4 only hosts can see IPv6 records ('tho they cannot talk to them.) Your suggestion would further isolate IPv6 within it's own DNS realm.
TL;DR IPv6 deployment is a matter of business need. As long as you have a v4 address and need to talk to other v4 hosts, there's no need for v6. This is the boat american companies are riding.
This has been debated as well. It would require reprogramming *every* internet connected device. Do I need to point out how many devices are in common use that no longer have any code support? These are devices that won't get IPv6 support either. So, given the choice of "upgrading the entire internet" for the short term gain of the class E space (best case, adds a few months) or deploying IPv6 -- which is, for better or worse, the solution -- we're f'ing deploying IPv6. No more g** d*** bandaids.
May be, but you've always had a PUBLIC IP address. When your ISP assigns you 192.168.38.45, how do you expect to connect to that from your hotel room? This is the problem parts of the world *already* face. Many APNIC ISPs have been deploying CGN for some time now. US cellphone networks have been known to do that as well. (99% of the time you won't notice.)
Simple... the dns lookup is for "example.com" -- that being the hostname. "ftp://" and "http://" are application specific protocols. There are dns SRV records, but as others have said, no ftp/http applications use them (currently.)
RAs and SLB (server load balancing [read: proxy]) NEXT
While having PI address space makes things cleaner, it's not something consumers can do. When the router sends a new RA with a different prefix, all the hosts should update their address instantly. (I've never actually tested that.)
Indeed. And it's been covered numerous times before. First off, reclaiming a single /8 will not make any measurable dent. There was a NANOG post a few months back from John Curran that pretty much was the last word. While there is *a lot* of address space that could be reclaimed, a) it would only prolong the inevitable, and b) it would take lenghtly, expensive legal fights to get it all back. ARIN's official stance is to accept any legacy blocks anyone wants to hand over, but they aren't even bothering to ask that any be returned.
(Honestly, you'd be an idiot to hand over something worth so much that's costing you absolutely zero.)
Turn on privacy extentions, which almost every modern OS does by default, and the EUI64 based addresses aren't used. Laptops that can connect via wired or wireless interfaces will have a different address based on what interface was used... undock your laptop and it's address changes and all of your connections drop. (Driver Magic(tm) aside)
Also, machines don't have MACs; interfaces have MACs. Many machines have multiple NICs and they're replacable. Even Sun eventually learned to stop that stupidity -- the hostid was used to generate a single MAC used by all interfaces; it was a bloody f'ing mess from day one.