Stress caused by pressure is relative. You could have a balloon with 1 million PSI in it, but it wouldn't be stressful to the balloon as long as the balloon also was inside a container with 1 million PSI. Yes, everything "down there" is under pressure, but not everything is under stress.
What I say in public may be considered "public", but what I hear on my phone is relatively private, I have an expectation that no one else being able to hear. Not to mention any other non-vocal forms of communication.
The difference between the bandwidth prices for some datacenters is not because bandwidth is expensive, but because they pay a premium to be directly peered with thousands of networks. Really, some datacenters have 4+ transit providers and have direct connections to over 1,000 different high profile networks. You're not paying for "bandwidth", you're paying for high quality, low latency, highly resilient bandwidth.
There are plenty of datacenters that offer cheap bandwidth that does doesn't come with 10ms latencies and 0ms of jitter, but most home users don't care about 99.999% uptime and every additional 10ms of latency reducing their revenue by $10m/year.
In this case it wasn't. There was no obvious waste of resources, the devs had a nice breakdown with a profiler showing the main things being done. No one parts of the system was using vastly more resources than the other, and there was a lot of different parts. Relative to other gaming engines, it was beating them on number of objects rendered by quite a bit.
Immutability increases memory usage, which puts pressure on your allocator, which also needs to be thread safe, and garbage collecting tends to be a "stop world" issue, which means all of your threads stopping. Depending on how you use "immutability", it could be worse than mutability for parallelism. People need to understand how things work in order to understand how they interact. There is no magic bullet, programmers need to start understanding and stop assuming everything is a blackbox that just works as desired.
Part of growing up is learning to know when you don't know what you're talking about and Linus is calling you on it. Every time that I've looked into why Linus was "wrong", it was because he was wrong in theory, but correct in practice, because in practice, people are idiots and Linus recognizes this.
I assume Linus is looking at this from a practical standpoint, that jumping the gun to making massive overhauls of the kernel to optimize for our current limited understanding of concurrent software and hardware interactions for a problem that most programmers are too stupid to even take advantage of, would be a bit premature. We should wait for hardware and software to better stabilize before we get locked(pun) into a concurrency regime for the next few decades.
We've only just recently gained concurrent support for network and storage IO, and hardware has been changing a lot in the past few years as we keep scaling up SSDs and 40gb+ NICs. We can use work-arounds for the mean time, and once everyone says "yes, this is the best way", we can make large kernel changes.
Another example, AMD is already working on Mantle. Even if it doesn't fully take off, it's research into a related area, and we'll learn a lot from it. At some point in the future, a Mantle-like system may be incorporated into the Kernel, but lets not turn the kernel into a cesspool of ever changing interfaces while they figure this problem out.
It's too early to know if it's just too hard a problem for the human mind in general
Most user-space parallel problems aren't hard, it's just programmers who use algorithms and data-structures as black-boxes without understanding their implementation or characteristics, or alternatives, or generally being able to think for themselves. I don't know how many times I've glanced at problems that were throughput sensitive, and I immediately saw large potentials for parallelism, but required designs that would be utterly illogical for a serial design.
Solving code parallelism problems is nearly identical to making well factored code. You need to break down the problem into its atomic parts, then rearrange those parts. Once you understand all atomic parts of a system and all of the data dependencies, parallelism becomes trivial. The problem is most people don't "understand" the system that they're working on, they just mindlessly throw code at a wall and some sticks. Most parallel code really needs to be designed from the beginning. Designing code? What's what?
Your Linux gaming machine shouldn't be doing more than 3/4 cores of CPU and handing the heavy grunt work off to the GPU anyway. No need for a 64 core CPU for that one.
Spoken truly like someone who does not understand anything about games or parallel processing. We already have games that ran make a 12 core CPU run at 80% load and a quad-GPU about the same. "Pipeline" style multithreading is becoming popular. Each stage of the graphics pipeline is ran where it is most efficient, which may be the CPU or the GPU, and data may bounce between the CPU and GPU several times before completed.
Piplining plays well with streaming, so one of the first jobs is for the CPU to break up the work to be done into many difference smaller pieces that can be "streamed". "Streaming" is just breaking up a large object into smaller objects. This allows for the GPU and CPU to be kept busy working on difference pieces that are at different points of the pipeline, keeping them busy.
The natural evolution of this is each stage of the pipeline can be a collection of "processing units", each unit capable of working on an unit of the stream. While the pipeline may prefer to use the GPU for certain types of work or the CPU for other types, if the current machine has an unbalanced mixture of CPU and GPU, the pipeline may augment one with the other. While the CPU may not be as good, if the machine has a lot of CPU cores left unused, might as well use them to speed things up.
We need a framework that allows code to run where it would be best to run, but also have the ability to overflow to less efficient execution units if they are relatively unused. In other words, we need to treat CPUs and GPUs like a pool of computing resources, and *something* needs to manage these resources to crunch data.
Cutting your frequency in half may reduce your power consumption by 80%. Lots of low frequency cores will kick the crap out of a single high frequency core, efficiency wise.
Larger caches also mean higher latency. If you have a lot of registers, that's great, but if you can't be constantly prefetching data from memory for one reason or another, higher cache latency will make everything slower for a small subset of workloads.
We're in the transition where throwing more transistors at a single core makes the core slower for most workloads with marginal gains for specific workloads. We need more cores, either of the same type or different types that specialize for certain types of workloads. Maybe we need some cores with large caches and some with smaller caches or some with lots of SIMD or some with few SIMD.
Because most of the work the graphics processor (=GPU) does is largely independent of the main processor (=CPU) (the CPU pushes in the data, says "do X with it", the GPU then churns away through the data) it doesn't need to be closely linked or share a lot of memory.
There is little GPU+CPU workloads because communications between the GPU and CPU is so slow, not because there is no demand for it. There is a huge class of hybrid workloads that require data ping-ponging back and forth between the GPU and CPU, but no one writes code for that because it's latency sensitive to nanoseconds and GPU to CPU latency is in microseconds. AMD is working on reducing the latency by integrating the GPU and CPU together.
That's why SSDs keep a reserve of about 10%-30% of the logical storage as pre-TRIM'd. Some of the newer SSDs even reserve another bunch of the drive as a scratch pad for writes.
Looking at this benchmark, it seems reads are more likely to have a random long access time than writes. http://techreport.com/review/2...
I think you missed the part about 65% and not "all" cancers, and some cancers are highly affected by carcinogens and some are less based on biases created in modern living.
Copyrighted data is owned by the public, but the copyright holder gets temporary exclusive control over use and distribution. Some news site got DMCA requests to remove the data, but the site laughed and linked some recent Supreme Court cases where private content that was never intended to be released as not protected. I can't remember if there was any nuances related to them being news sources.
There would need to be a court order, not a civil complaint. So get a court order, per IP address, and request that customer be disconnected. In a few months time, you may have a few tens of those bot net nodes knocked offline.
An ASIC that tracks state at line rate? What are you smoking, I want some. You do realize that state exhaustion is a form of DOS, yes? There is no way an ASIC could handle the number of states required. We're already having issues with ASIC trying to handle a few hundred thousand routes, yet alone millions or billions of states.
They try to close the connection with RST the server says wait I have data to send you.
There is no "wait" for RST. RST packets are immediate, no questions asked, no stopping it. If the client sends an RST, it will send the packet, then kill the state without waiting.
Most bots doing SYN floods don't use the OS, but instead use raw sockets to quickly generate lots of SYNs, which does not consume any state overhead in the OS network stack. When doing RAW sockets, it's up to the caller to handle all state.
Routers all maintain a reasonably sized set of source/destination/timer triplets
Routers are stateless. Some routers have firewalls built in and those hybrids are be a mix of stateless and stateful. Next gen high end routers are starting to reach a point where stateful can't be done. We're transitioning from 10gb to 1tb, we're actually starting to hit issues with physics not allowing processing to happen in time. We're nearly entering a time of photonic routers that can't do any processing at all, but they can route speed of light fast.
Routing and switching data is dead simple, but anything that is stateful requires storing those states and constantly tracking them. Extremely complicated stuff to be doing at line rate, and "soon" to be impossible at line rate.
To make a stateful firewall will just make a firewall that gets DOS'd from lack of processing or memory resources to handle the bandwidth. Great, not only is your router more expensive and complicated and prone to misconfiguration, but it's also more vulnerable to different type of DOS attack.
You can't protect from one type of DOS without proportionally increasing your risk to another form of DOS. You're better off just brute-forcing the issue and getting more bandwidth. There are ways to get crazy cheap bandwidth, but you need to bring your edge to the bandwidth, not the bandwidth to your edge.
I asked my ISP about this and I was told that my ONT only allows assigned IPs to be the source IPs. I can't even spoof the IP of someone else in my subnet. The only IPs I can "spoof" are ones on my physical link, so my local network.
"routers" are not session based, but stateful firewalls are. What you're thinking about is NAT "routers", which are not really routers, but firewalls with NAT and basic routing capabilities. Routers are stateless.
Slashdot Mirror
Stress caused by pressure is relative. You could have a balloon with 1 million PSI in it, but it wouldn't be stressful to the balloon as long as the balloon also was inside a container with 1 million PSI. Yes, everything "down there" is under pressure, but not everything is under stress.
What I say in public may be considered "public", but what I hear on my phone is relatively private, I have an expectation that no one else being able to hear. Not to mention any other non-vocal forms of communication.
They should have been using fiber. Specs on a popular GPON chassis says maximum operating ambient air temp is 131f @ 95% relative humidity.
The problem seems to be routers. A regular router seems to be limited to about 121f and "core" routers are more around 104f.
The difference between the bandwidth prices for some datacenters is not because bandwidth is expensive, but because they pay a premium to be directly peered with thousands of networks. Really, some datacenters have 4+ transit providers and have direct connections to over 1,000 different high profile networks. You're not paying for "bandwidth", you're paying for high quality, low latency, highly resilient bandwidth.
There are plenty of datacenters that offer cheap bandwidth that does doesn't come with 10ms latencies and 0ms of jitter, but most home users don't care about 99.999% uptime and every additional 10ms of latency reducing their revenue by $10m/year.
Some ISPs have a congested connection to Netflix and VPN is many times an alternative uncongested route.
You assume those networks are ran by professionals. They may work for a company, but rarely do you hear about a professional place getting hacked.
In this case it wasn't. There was no obvious waste of resources, the devs had a nice breakdown with a profiler showing the main things being done. No one parts of the system was using vastly more resources than the other, and there was a lot of different parts. Relative to other gaming engines, it was beating them on number of objects rendered by quite a bit.
Immutability increases memory usage, which puts pressure on your allocator, which also needs to be thread safe, and garbage collecting tends to be a "stop world" issue, which means all of your threads stopping. Depending on how you use "immutability", it could be worse than mutability for parallelism. People need to understand how things work in order to understand how they interact. There is no magic bullet, programmers need to start understanding and stop assuming everything is a blackbox that just works as desired.
Part of growing up is learning to know when you don't know what you're talking about and Linus is calling you on it. Every time that I've looked into why Linus was "wrong", it was because he was wrong in theory, but correct in practice, because in practice, people are idiots and Linus recognizes this.
I assume Linus is looking at this from a practical standpoint, that jumping the gun to making massive overhauls of the kernel to optimize for our current limited understanding of concurrent software and hardware interactions for a problem that most programmers are too stupid to even take advantage of, would be a bit premature. We should wait for hardware and software to better stabilize before we get locked(pun) into a concurrency regime for the next few decades.
We've only just recently gained concurrent support for network and storage IO, and hardware has been changing a lot in the past few years as we keep scaling up SSDs and 40gb+ NICs. We can use work-arounds for the mean time, and once everyone says "yes, this is the best way", we can make large kernel changes.
Another example, AMD is already working on Mantle. Even if it doesn't fully take off, it's research into a related area, and we'll learn a lot from it. At some point in the future, a Mantle-like system may be incorporated into the Kernel, but lets not turn the kernel into a cesspool of ever changing interfaces while they figure this problem out.
It's too early to know if it's just too hard a problem for the human mind in general
Most user-space parallel problems aren't hard, it's just programmers who use algorithms and data-structures as black-boxes without understanding their implementation or characteristics, or alternatives, or generally being able to think for themselves. I don't know how many times I've glanced at problems that were throughput sensitive, and I immediately saw large potentials for parallelism, but required designs that would be utterly illogical for a serial design.
Solving code parallelism problems is nearly identical to making well factored code. You need to break down the problem into its atomic parts, then rearrange those parts. Once you understand all atomic parts of a system and all of the data dependencies, parallelism becomes trivial. The problem is most people don't "understand" the system that they're working on, they just mindlessly throw code at a wall and some sticks. Most parallel code really needs to be designed from the beginning. Designing code? What's what?
Your Linux gaming machine shouldn't be doing more than 3/4 cores of CPU and handing the heavy grunt work off to the GPU anyway. No need for a 64 core CPU for that one.
Spoken truly like someone who does not understand anything about games or parallel processing. We already have games that ran make a 12 core CPU run at 80% load and a quad-GPU about the same. "Pipeline" style multithreading is becoming popular. Each stage of the graphics pipeline is ran where it is most efficient, which may be the CPU or the GPU, and data may bounce between the CPU and GPU several times before completed.
Piplining plays well with streaming, so one of the first jobs is for the CPU to break up the work to be done into many difference smaller pieces that can be "streamed". "Streaming" is just breaking up a large object into smaller objects. This allows for the GPU and CPU to be kept busy working on difference pieces that are at different points of the pipeline, keeping them busy.
The natural evolution of this is each stage of the pipeline can be a collection of "processing units", each unit capable of working on an unit of the stream. While the pipeline may prefer to use the GPU for certain types of work or the CPU for other types, if the current machine has an unbalanced mixture of CPU and GPU, the pipeline may augment one with the other. While the CPU may not be as good, if the machine has a lot of CPU cores left unused, might as well use them to speed things up.
We need a framework that allows code to run where it would be best to run, but also have the ability to overflow to less efficient execution units if they are relatively unused. In other words, we need to treat CPUs and GPUs like a pool of computing resources, and *something* needs to manage these resources to crunch data.
Cutting your frequency in half may reduce your power consumption by 80%. Lots of low frequency cores will kick the crap out of a single high frequency core, efficiency wise.
Larger caches also mean higher latency. If you have a lot of registers, that's great, but if you can't be constantly prefetching data from memory for one reason or another, higher cache latency will make everything slower for a small subset of workloads.
We're in the transition where throwing more transistors at a single core makes the core slower for most workloads with marginal gains for specific workloads. We need more cores, either of the same type or different types that specialize for certain types of workloads. Maybe we need some cores with large caches and some with smaller caches or some with lots of SIMD or some with few SIMD.
Because most of the work the graphics processor (=GPU) does is largely independent of the main processor (=CPU) (the CPU pushes in the data, says "do X with it", the GPU then churns away through the data) it doesn't need to be closely linked or share a lot of memory.
There is little GPU+CPU workloads because communications between the GPU and CPU is so slow, not because there is no demand for it. There is a huge class of hybrid workloads that require data ping-ponging back and forth between the GPU and CPU, but no one writes code for that because it's latency sensitive to nanoseconds and GPU to CPU latency is in microseconds. AMD is working on reducing the latency by integrating the GPU and CPU together.
That's why SSDs keep a reserve of about 10%-30% of the logical storage as pre-TRIM'd. Some of the newer SSDs even reserve another bunch of the drive as a scratch pad for writes.
Looking at this benchmark, it seems reads are more likely to have a random long access time than writes. http://techreport.com/review/2...
I think you missed the part about 65% and not "all" cancers, and some cancers are highly affected by carcinogens and some are less based on biases created in modern living.
Copyrighted data is owned by the public, but the copyright holder gets temporary exclusive control over use and distribution. Some news site got DMCA requests to remove the data, but the site laughed and linked some recent Supreme Court cases where private content that was never intended to be released as not protected. I can't remember if there was any nuances related to them being news sources.
The person driving gets in trouble, not the owner. Intent is a big player in how court will handle this.
There would need to be a court order, not a civil complaint. So get a court order, per IP address, and request that customer be disconnected. In a few months time, you may have a few tens of those bot net nodes knocked offline.
An ASIC that tracks state at line rate? What are you smoking, I want some. You do realize that state exhaustion is a form of DOS, yes? There is no way an ASIC could handle the number of states required. We're already having issues with ASIC trying to handle a few hundred thousand routes, yet alone millions or billions of states.
They try to close the connection with RST the server says wait I have data to send you.
There is no "wait" for RST. RST packets are immediate, no questions asked, no stopping it. If the client sends an RST, it will send the packet, then kill the state without waiting.
Most bots doing SYN floods don't use the OS, but instead use raw sockets to quickly generate lots of SYNs, which does not consume any state overhead in the OS network stack. When doing RAW sockets, it's up to the caller to handle all state.
There is no notion of a "correct" IP when a customer can have more than one IP. Just drop the packet.
Routers all maintain a reasonably sized set of source/destination/timer triplets
Routers are stateless. Some routers have firewalls built in and those hybrids are be a mix of stateless and stateful. Next gen high end routers are starting to reach a point where stateful can't be done. We're transitioning from 10gb to 1tb, we're actually starting to hit issues with physics not allowing processing to happen in time. We're nearly entering a time of photonic routers that can't do any processing at all, but they can route speed of light fast.
Routing and switching data is dead simple, but anything that is stateful requires storing those states and constantly tracking them. Extremely complicated stuff to be doing at line rate, and "soon" to be impossible at line rate.
To make a stateful firewall will just make a firewall that gets DOS'd from lack of processing or memory resources to handle the bandwidth. Great, not only is your router more expensive and complicated and prone to misconfiguration, but it's also more vulnerable to different type of DOS attack.
You can't protect from one type of DOS without proportionally increasing your risk to another form of DOS. You're better off just brute-forcing the issue and getting more bandwidth. There are ways to get crazy cheap bandwidth, but you need to bring your edge to the bandwidth, not the bandwidth to your edge.
I asked my ISP about this and I was told that my ONT only allows assigned IPs to be the source IPs. I can't even spoof the IP of someone else in my subnet. The only IPs I can "spoof" are ones on my physical link, so my local network.
"routers" are not session based, but stateful firewalls are. What you're thinking about is NAT "routers", which are not really routers, but firewalls with NAT and basic routing capabilities. Routers are stateless.