Most ISP don't actually shape Netflix, they use DNS to send you to a different server to alter your route. Shaping can happen, but you find it more in ISPs that have 1mb DSL, not 100mb cable. It gets really hard to shape large numbers of people with fast connections. If they are shaping, not much you can do. My ISP does not shape or QoS, so tracert and pathping work fine.
There is a 16tb/s connection that has a 680km range available right now and a 1tb/s link that was tested to have a 13,000km range and should be ready for real world soon. Those two have slightly better storage capacity. There is also the 1pb/s connect with 56km range, but that uses a special new type of fiber that is much more expensive and both will take a while to see real-world use.
That 2% of the population? Who cares? They know what they're giving up living in the middle of a 1000 acre forest. for the rest of a nation, even farmers, this is not an issue.
In an a near by area where I used to live, above ground cables broke about 3 times per year and underground cables in my new area, well, it's been about 8 years now, not a single issue. Lots of trees, freezing rain, tornadoes, other randomly strong seasonal wind, and some other stuff.
I would think getting reclassified as common carrier would reduce the hurtle because then ISPs would get ROW access without being regulated as a telcom.
Why not start a mini-ISP and co-location facility in the area?
Unless I'm a regulated utility like power, gas, telcom, cable, water, I don't get ROW access by default. I would have to go door-to-door to get permission to run cables/fiber to each person's property. That increases install prices from about $1.8k/house to around $10k/house. Hard to be competitive.
When they installed fiber around here, they didn't tear up the streets. They used something that looked like this to go under streets. http://blog.cleveland.com/busi...
Switches, cables and admin systems all cost money, and these costs all increase with the amount of bandwidth running through the system.
You're doing it wrong. With 400gb/s ports and 1pb/s routers that you can get, I don't see how messily 100mb/s residential connections that are on average 5% active during peak hours can make a multi tb/s router even flinch.
Bandwidth is so cheap that the act of tracking someone's usage costs more than the bandwidth they use. It's cheaper to not monitor and just build your network to handle what you sell.
they need to make sure your backhaul interconnects are overbuilt enough to deal with expected growth in line with however long it would take to build additional capacity
That's the beauty of fiber. I have a 1gb fiber ring connecting me from my house to my ISP's trunk. No "pop" involved. Come on over and get a 30/30 dedicated connection for $60/month. Their last mile is not over-subscribed, they can handle everyone running 1gb/1gb at the same time. What can't handle it is their trunk. The only planning they need to worry about is upgrading their trunk for the foreseeable future. How much does one of these networks cost? About $1,800 per house passed.
Anyway, what do you mean by "make sure your backhaul interconnects are overbuilt enough"? A single fiber can move 16tb/s of data right now with commercially available Dense Wave Division Multiplexers and can accept any mixture of 10gb-400gb ports and newer tech can push 1pb/s over a single fiber. How much data are these interconnects supposed to be handling anyway, more than 16tb/s?
In batches of 1gb, L3 charges about $6/mbit. Once you get about 100gb increments, it's almost $1/mbit. Ohh noooesss, double the price.. freak out. Even at $6/mbit, there is still A LOT of room for profit.
The trunk infrastructure is basically free compared to the last mile infrastructure. After dropping $100mil to connect a few people on the last mile, paying $25k/month to get a fiber link to an IX in the next state is less than a rounding error on your last mile maintenance costs.
http://bgp.he.net/AS5056
Looks like XO comm is their biggest with around 50% and Cogent and Spring mostly sharing the other 50%, based on blocks routed.
Always a good idea. Not as good as a back-up, but you can snapshot your current system and rollback to that exact snapshot if bad things happen. One of the beautiful parts of ZFS on root.
Re:I wish FreeBSD had a decent VM server/hyperviso
on
FreeBSD 10.0 Released
·
· Score: 1
The important distinction is between hypervisors that do software partitioning of devices (either via emulation or paravirtualised devices), and ones that don't. Xen, KVM, and byhve all fall into the former category and so have a TCB that's several MBs of object code.
It is interesting to note that KVM is over 12mil lines of code and XEN is about 515k LOC, while byhve is only 1,300.. yes.. 1 thousand three hundred. byhve also compiles to just under 500KB. XEN is around 1MB, but I can't find info on KVM.
With 90% of my in-state Uni tuition cover by state taxes, I doubt they want to "pad" with more requirements. If anything, there were quite a few 3 credit general courses that counted for 2 different requirements, meaning you could almost cut your require general classes in half. Being that most generals were only 2 credits, it would only reduce credits by 50%, but that would save you money since you pay by credit.
Well, you paid per credit up to 12 credits. After that, credits were free, but you had to have your adviser and department head sign off if taking more than 13 credits. I've seen some people who took 17 credits. No life, but save a lot of money and graduate early.
Re:I wish FreeBSD had a decent VM server/hyperviso
on
FreeBSD 10.0 Released
·
· Score: 4, Insightful
According to wiki: Kernel-based Virtual Machine (KVM) and bhyve are implemented as a kernel modules for Linux and FreeBSD respectively which, when loaded, allows its host operating system to act as a bare metal (i.e., Type 1) hypervisor
So the only difference is the kernel is not just a hypervisor, but also an OS. If you don't make use of the OS part, it works like a normal Type 1 hypervisor.
Re:I wish FreeBSD had a decent VM server/hyperviso
on
FreeBSD 10.0 Released
·
· Score: 4, Informative
bhyve is technically a type 2, but it makes use of the HW acceled instructions that Type 1s normally use. bhyve is more a of a hybrid between 1 and 2, with more of a bias towards 2. Because of this, it is not very friendly with many Type 2 guests because it lacks legacy support and it's not a true Type 1, so it still needs proper interfaces, but it is faster, lighter weight, and uses about 10x fewer lines of code than most, so it is easy to debug and prove security.
Getting picked on growing up taught me how important it is to be nice to people, and that you should always try not to judge a person based on appearances or first impressions.
Great advice. To add to that, most people have a bit of drama and tend to leave out important pieces when they complain about someone else. For this reason, I have learned to not take on other people's grudges, but I do take everything with a grain of salt. Too many people get their knickers in a twist over small petty things. Life is too short to focus on whom you don't like. If I don't get along with someone, I just stop associating with them or at least try my best given a certain circumstance.
The issue with Java for GPUs is that GPUs have objects and love structures. GPUs puke when random memory access is involved. Right now, Java treats everything as an object, even structs. Java will need to be revamped a bit to work on GPUs. Get ready to start doing buffers and structs in Java, it'll be like C.
AMD has two separate core logics with their own execution units that only share the FPU. They have their own L1 caches and a bunch of other things. The FPU can handle 256bits worth of FPU calculations split it almost any configuration of x87, SSE, AVX. The only real time you see contention for the FPU unit is when doing 2x 128bit SSE instructions on a single core or a single 256bit AVX instruction.
Intel's hyper threading shared nearly everything, right down to the integer execution units and L1 cache. Intel made a highly pipelined CPU with a lot of execution units, then made it so it presented itself as two logical CPUs, as many of those execution units will be idle because of memory stalls or just can't pipeline enough instructions in parallel to use them all.
Intel's design has a better best case and a worse worst case, AMD is more middle of the road. Both designs increase throughput per transistor and reducing power per transistor on average.
A huge benefit Intel's design gets is if you disable HT or the OS puts a one of the logical cores to sleep, you can make use of the entire CPU, making single threaded performance strong as you have a single core with massive L1 cache and a ton of pipelinable execution units.
But remember, Intel optimized for throughput, so that large L1 cache comes with a 2 cycle latency, but can handle 128bit loads per cycle. If you're going to optimize for single threaded performance, make use of those extra registers in 64bit mode and help hide that latency. when hyper-threading is enabled, it helps hide single threaded latency by interleaving logical threads against the cache, making it mostly seem like 1 cycle latency. Higher throughput, but higher latency.
Slashdot Mirror
Monster cables, making sure the super-position of your photons are kept pristine.
Most ISP don't actually shape Netflix, they use DNS to send you to a different server to alter your route. Shaping can happen, but you find it more in ISPs that have 1mb DSL, not 100mb cable. It gets really hard to shape large numbers of people with fast connections. If they are shaping, not much you can do. My ISP does not shape or QoS, so tracert and pathping work fine.
There is a 16tb/s connection that has a 680km range available right now and a 1tb/s link that was tested to have a 13,000km range and should be ready for real world soon. Those two have slightly better storage capacity. There is also the 1pb/s connect with 56km range, but that uses a special new type of fiber that is much more expensive and both will take a while to see real-world use.
Trace route or pathping?
That 2% of the population? Who cares? They know what they're giving up living in the middle of a 1000 acre forest. for the rest of a nation, even farmers, this is not an issue.
In an a near by area where I used to live, above ground cables broke about 3 times per year and underground cables in my new area, well, it's been about 8 years now, not a single issue. Lots of trees, freezing rain, tornadoes, other randomly strong seasonal wind, and some other stuff.
I would think getting reclassified as common carrier would reduce the hurtle because then ISPs would get ROW access without being regulated as a telcom.
Why not start a mini-ISP and co-location facility in the area?
Unless I'm a regulated utility like power, gas, telcom, cable, water, I don't get ROW access by default. I would have to go door-to-door to get permission to run cables/fiber to each person's property. That increases install prices from about $1.8k/house to around $10k/house. Hard to be competitive.
When they installed fiber around here, they didn't tear up the streets. They used something that looked like this to go under streets. http://blog.cleveland.com/busi...
Who is "Utilities" that they can charge power and telcom fees? Around here "Utilities" just means power/telcom/gas/cable, all of whom have ROW access.
Nearly my entire city has everything underground, including power. I find it strange to have anything above ground.
Switches, cables and admin systems all cost money, and these costs all increase with the amount of bandwidth running through the system.
You're doing it wrong. With 400gb/s ports and 1pb/s routers that you can get, I don't see how messily 100mb/s residential connections that are on average 5% active during peak hours can make a multi tb/s router even flinch.
Bandwidth is so cheap that the act of tracking someone's usage costs more than the bandwidth they use. It's cheaper to not monitor and just build your network to handle what you sell.
they need to make sure your backhaul interconnects are overbuilt enough to deal with expected growth in line with however long it would take to build additional capacity
That's the beauty of fiber. I have a 1gb fiber ring connecting me from my house to my ISP's trunk. No "pop" involved. Come on over and get a 30/30 dedicated connection for $60/month. Their last mile is not over-subscribed, they can handle everyone running 1gb/1gb at the same time. What can't handle it is their trunk. The only planning they need to worry about is upgrading their trunk for the foreseeable future. How much does one of these networks cost? About $1,800 per house passed.
Anyway, what do you mean by "make sure your backhaul interconnects are overbuilt enough"? A single fiber can move 16tb/s of data right now with commercially available Dense Wave Division Multiplexers and can accept any mixture of 10gb-400gb ports and newer tech can push 1pb/s over a single fiber. How much data are these interconnects supposed to be handling anyway, more than 16tb/s?
In batches of 1gb, L3 charges about $6/mbit. Once you get about 100gb increments, it's almost $1/mbit. Ohh noooesss, double the price.. freak out. Even at $6/mbit, there is still A LOT of room for profit.
The trunk infrastructure is basically free compared to the last mile infrastructure. After dropping $100mil to connect a few people on the last mile, paying $25k/month to get a fiber link to an IX in the next state is less than a rounding error on your last mile maintenance costs.
http://bgp.he.net/AS5056 Looks like XO comm is their biggest with around 50% and Cogent and Spring mostly sharing the other 50%, based on blocks routed.
But first test your backups.
Always a good idea. Not as good as a back-up, but you can snapshot your current system and rollback to that exact snapshot if bad things happen. One of the beautiful parts of ZFS on root.
The important distinction is between hypervisors that do software partitioning of devices (either via emulation or paravirtualised devices), and ones that don't. Xen, KVM, and byhve all fall into the former category and so have a TCB that's several MBs of object code.
It is interesting to note that KVM is over 12mil lines of code and XEN is about 515k LOC, while byhve is only 1,300.. yes.. 1 thousand three hundred. byhve also compiles to just under 500KB. XEN is around 1MB, but I can't find info on KVM.
With 90% of my in-state Uni tuition cover by state taxes, I doubt they want to "pad" with more requirements. If anything, there were quite a few 3 credit general courses that counted for 2 different requirements, meaning you could almost cut your require general classes in half. Being that most generals were only 2 credits, it would only reduce credits by 50%, but that would save you money since you pay by credit.
Well, you paid per credit up to 12 credits. After that, credits were free, but you had to have your adviser and department head sign off if taking more than 13 credits. I've seen some people who took 17 credits. No life, but save a lot of money and graduate early.
According to wiki: Kernel-based Virtual Machine (KVM) and bhyve are implemented as a kernel modules for Linux and FreeBSD respectively which, when loaded, allows its host operating system to act as a bare metal (i.e., Type 1) hypervisor
So the only difference is the kernel is not just a hypervisor, but also an OS. If you don't make use of the OS part, it works like a normal Type 1 hypervisor.
bhyve is technically a type 2, but it makes use of the HW acceled instructions that Type 1s normally use. bhyve is more a of a hybrid between 1 and 2, with more of a bias towards 2. Because of this, it is not very friendly with many Type 2 guests because it lacks legacy support and it's not a true Type 1, so it still needs proper interfaces, but it is faster, lighter weight, and uses about 10x fewer lines of code than most, so it is easy to debug and prove security.
That's not an excuse.
Getting picked on growing up taught me how important it is to be nice to people, and that you should always try not to judge a person based on appearances or first impressions.
Great advice. To add to that, most people have a bit of drama and tend to leave out important pieces when they complain about someone else. For this reason, I have learned to not take on other people's grudges, but I do take everything with a grain of salt. Too many people get their knickers in a twist over small petty things. Life is too short to focus on whom you don't like. If I don't get along with someone, I just stop associating with them or at least try my best given a certain circumstance.
The issue with Java for GPUs is that GPUs have objects and love structures. GPUs puke when random memory access is involved. Right now, Java treats everything as an object, even structs. Java will need to be revamped a bit to work on GPUs. Get ready to start doing buffers and structs in Java, it'll be like C.
AMD has two separate core logics with their own execution units that only share the FPU. They have their own L1 caches and a bunch of other things. The FPU can handle 256bits worth of FPU calculations split it almost any configuration of x87, SSE, AVX. The only real time you see contention for the FPU unit is when doing 2x 128bit SSE instructions on a single core or a single 256bit AVX instruction.
Intel's hyper threading shared nearly everything, right down to the integer execution units and L1 cache. Intel made a highly pipelined CPU with a lot of execution units, then made it so it presented itself as two logical CPUs, as many of those execution units will be idle because of memory stalls or just can't pipeline enough instructions in parallel to use them all.
Intel's design has a better best case and a worse worst case, AMD is more middle of the road. Both designs increase throughput per transistor and reducing power per transistor on average.
A huge benefit Intel's design gets is if you disable HT or the OS puts a one of the logical cores to sleep, you can make use of the entire CPU, making single threaded performance strong as you have a single core with massive L1 cache and a ton of pipelinable execution units.
But remember, Intel optimized for throughput, so that large L1 cache comes with a 2 cycle latency, but can handle 128bit loads per cycle. If you're going to optimize for single threaded performance, make use of those extra registers in 64bit mode and help hide that latency. when hyper-threading is enabled, it helps hide single threaded latency by interleaving logical threads against the cache, making it mostly seem like 1 cycle latency. Higher throughput, but higher latency.