It makes perfect sense in this case. You can go on leave, come back, then go on leave again, how ever many times you want during the year. Work at your leisure.
DX12 and OpenGL Vulkan are based around treating a GPU as a compute engine and not a "graphics" anything. You compute the work, then write it out to a buffer to be displayed. At this point you just have a bunch of compute tasks and a bunch of compute engines. This new way of doing stuff scales nearly perfectly linearly with the number of total compute in your computer. There have been some tech demos of a system with xfire ATI cards, paired with an Nvidia and the Intel IGP, and the engine made near perfect use of all of the GPUs at the same time to increase the FPS.
We are a point in time where people who write games no longer write the engines. Once some big engine rolls out these new features, everyone that uses that engine get a lot of benefit with no changes on their end. Of course the developers will need more understanding to make full use, but a lot of the basic stuff you can get for free from the engine. Like render this polygon. The game programmer does not need to know how its being rendered. Advanced shading will need to know more.
While I dislike how at some point, given millions of years, one of my ancestors had to be stronger than someone else and probably kill them in competition for not enough resources, but if it wasn't for them I would not be alive. I'm saying, you can't have you cake and eat it to. If you want someone that is capable of surviving a hyper competitive environment, they're going to have to be an asshole and screw over everyone every chance they get.
The new graphics APIs will allow IGPs to be faster for some work loads. Discrete GPUs have high throughput but also high communications latency, about 100x that of an IGP that is on chip. The IGP can communicate with the CPU directly via the L2/L3 cache, but a discrete GPU has to go over a high latency PCIe link with all kinds of encoding latency overhead.
Let the IGP do physics, AI, or whatever, and leave the heavy crunching to the big boy. Newer game engines are looking into better ways to allow the screen to be broken into pieces, allowing multiple GPUs with different amounts of compute to work well as a team with efficient dynamic load balancing.
A research paper about Samsung VNAND had their TLC pegged between 5k and 60k write cycles, depending on how you tweaked the SSD for performance, but same density and less than a 3x difference in performance. VNAND is using a much larger processes while having greater densities. The larger process allows VNAND to have a lot more write cycles compared to regular TLC NAND. Of course the cycles will against get worse as the process shrinks, but VNAND inherently has more write cycles than NAND, even at the same process size. I assume this other implementation will be similar.
It only affects the handshakes, then it's all AES. Stop making lots of connections and use long lived connections. But like you said, how are the measuring it. 20% just for the handshake or 20% on average per web request?
Newer DWMD multiplexing tech allows for 400Gb-500Gb super-channels and near future versions are about to have 1Tb/s super-channels. A 500Gb single super-channel can support anything from 50 10Gb channels to a single 500Gb channel. Of course the current max bandwidth across all channels in a single fiber is about 32Tb/s, so they'll have to make do. 32Tb/s can have 320 100Gb/s streams. Suddenly 100Gb sounds slow.
I assume the money issue is more of a legacy system issue. Some hardware that an ISP purchases is very expensive and you only replace every 8 years. Maybe the last time they ordered some hardware, they wanted to save 20% to get some older equipment that didn't support IPv6. I know I can purchase a Layer 3 switch that does not support IPv6 for a decent chunk less than one that does.
All new equipment for a long time has supported IPv6, but why purchase new when you can purchase a generation or two old and get liquidation prices? When my ISP purchased all new gigabit fiber and replaced their core router with a new shiny one that has more 10Gb and 100Gb ports than they'll need for a long time, I'm sure it supports IPv6, but there is bound to be a few pieces of old gear that needs to go away. Then they need to get training and do planning before they attempt to roll it out.
They don't "own" them, they have a civil contract that says ARIN has granted them the right to use them and ARIN can't forcefully take them back as long as the original contract is valid. As soon as the IP blocks transfer owners, they are no longer grandfathered in. There have been a few exceptions to this rule early during the transitional phase, but ARIN is locking down on any more exceptions.
Many set-top boxes like Roku support streaming from your home media server. They'll need LAN access in those cases.
"Built in caching proxy server" - Doesn't help with HTTPS and with just around the corner 10Gb internet, I challenge you to make a cheap device that can handle proxying data at 10Gb/s.
"The device needs a real time virus scanner that is automatically updated" - Not so much a virus scanner, but an IDS. Can't virus scan at 10Gb/s.
"Must of course include basic traffic shaping and other useful stuff" - Even professionals get Traffic shaping wrong most of the time. An AQM like Cake or fq_Codel is all that is needed. Fair queueing and flow isolation to combat bufferbloat.
"You could even use VPNs to link two homes together" - More features!
You have a lot of great ideas, but as it is, even $400 consume grade routers are riddled with security holes that never get fixed. They can't even get NAT or UPNP right, what makes you think they can do some of the more complicated features in a secure way? Remember, most of these devices are EoL by the time they can be purchased. Supporting devices is a cost and most companies don't want that.
Either people need to take responsibility for their own security or we need a better open source security framework and support that allows for companies to make the devices and let the opensource community handle the software side of things. We cannot trust companies to maintain bug fixes for their devices.
"Slow start" is relative. It is much slower than going strait to line rate, but it is an binary search that increases bandwidth exponentially per RTT. Many TCP implementations start off with a window size of 8 segments or more at full line rate. Most TCP implementations coalesce ACKs to reduce the number of ACK packets. This would mean every 2 segments gets an ACK. 8 segments sent means 4 ACKs which means 4 doulbings(16x) in just the first RTT. 16x 8 segments is 128 segments. a 20ms RTT with 128 1500 byte segments is 76.8Mb/s in the first 20ms, and will continue to double every 2 segments ACKed per RTT. By the time you are 40-60ms in, you should be at almost 200Mb/s. His 15 seconds is forever.
My example is a little bit simplified because once a TCP stream gets moving, the packets are spaced apart, only the initial transfer will burst all segments in the window at line rate. A bit of trivia. Google modified their TCP stack to increase the number of initial bursted segments because most responses are quite small, and if you can fit the entire response in the initial burst the client only needs to wait one RTT, but if there are any more segments to be sent, the client now has to wait at least 2-RTTs, even if it's one more segment.
I have a 1Gb link that is rate limited to 100Mb. When I download files, wireshark shows a 1Gb burst of 30 1500 byte packets back-to-back, then my ISP's rate limiting starts to clamp down and the traffic shaping starts to space out the TCP flow and dials down to my 100Mb provisioned rate. This all happens in the first second, not 15-20 seconds. Although I have an 10ms RTT to every major datacenter in Chicago via Level 3 Comm. Low RTTs allow TCP to quickly ramp up. My ISP does have one CDN on their network, akamai. 1.5ms ping.
10ms to Chicago, 30ms to New York City and Atalanta and Washington(AWS), 40ms to Texas and Florida, and 60ms to Cali. Short RTTs help a lot with TCP.
Bandwidth isn't everything, ping, jitter, and loss are also important. Jitter typically indicates congestion and so does loss. I can reach every major datacenter in the world with under a 250ms RTT. That includes Moscow, India, China, Japan, South Korea, New Zealand, and Australia. Also, all under 1ms of jitter.
ARIN already laid out several phases. A few months ago they started to limit how many IPs they handed out, a month ago they started to reject some requests. We're reaching the end game, which includes reclaiming IPs. You will need to prove every year that you still need your blocks more than others, and every year ARIN will get more strict and refuse renewal for some customers so other customers that are more deserving get some. It will start to get painful.
Some CDNs are seeing 18%-40% of web requests from AT&T, Verizon, or Comcast are over IPv6. IPv6 is still growing at an exponential rate for almost a decade now, about 100% per year. At the current about 10% of all USA, given 100% growth that hasn't shown any signs of stopping, we'll be at 40% in two years and 80% in 3 years.
HTTP1.1 is a huge limitation. You need a lot of connections to make any decent use of your bandwidth. I find that even slow websites are mostly a latency vs throughput issue. The data comes in bursted at 1Gb/s, but there are large gaps between the responses.
Not just block sized inserts, but also inserts at block boundaries. And block sized inserts only works for dedup. CoW won't help with dedup off if the blocks shift, but no issues flipping bits or appending.
We don't need a/48 per person, just per household. With 3 people per household, that's saves you almost 2 bits! Meant to be funny. 1 bit isn't that useful of a difference.
But my router and switch and computers just crashed, how does IPv6 handle that? DNS servers are critical infrastructure. Shit will break when they go down, get used to it.
Slashdot Mirror
Unified raw address space. You can still carve it up into virtual spaces if you want, like protected memory.
It makes perfect sense in this case. You can go on leave, come back, then go on leave again, how ever many times you want during the year. Work at your leisure.
DX12 and OpenGL Vulkan are based around treating a GPU as a compute engine and not a "graphics" anything. You compute the work, then write it out to a buffer to be displayed. At this point you just have a bunch of compute tasks and a bunch of compute engines. This new way of doing stuff scales nearly perfectly linearly with the number of total compute in your computer. There have been some tech demos of a system with xfire ATI cards, paired with an Nvidia and the Intel IGP, and the engine made near perfect use of all of the GPUs at the same time to increase the FPS.
We are a point in time where people who write games no longer write the engines. Once some big engine rolls out these new features, everyone that uses that engine get a lot of benefit with no changes on their end. Of course the developers will need more understanding to make full use, but a lot of the basic stuff you can get for free from the engine. Like render this polygon. The game programmer does not need to know how its being rendered. Advanced shading will need to know more.
While I dislike how at some point, given millions of years, one of my ancestors had to be stronger than someone else and probably kill them in competition for not enough resources, but if it wasn't for them I would not be alive. I'm saying, you can't have you cake and eat it to. If you want someone that is capable of surviving a hyper competitive environment, they're going to have to be an asshole and screw over everyone every chance they get.
The new graphics APIs will allow IGPs to be faster for some work loads. Discrete GPUs have high throughput but also high communications latency, about 100x that of an IGP that is on chip. The IGP can communicate with the CPU directly via the L2/L3 cache, but a discrete GPU has to go over a high latency PCIe link with all kinds of encoding latency overhead.
Let the IGP do physics, AI, or whatever, and leave the heavy crunching to the big boy. Newer game engines are looking into better ways to allow the screen to be broken into pieces, allowing multiple GPUs with different amounts of compute to work well as a team with efficient dynamic load balancing.
They do, and they sell them for $600+ under their Xeon brand.
One per "per connection" was implied. The other person talked about using many keys per connection and storing "1k-4k" of data per machine connected.
A research paper about Samsung VNAND had their TLC pegged between 5k and 60k write cycles, depending on how you tweaked the SSD for performance, but same density and less than a 3x difference in performance. VNAND is using a much larger processes while having greater densities. The larger process allows VNAND to have a lot more write cycles compared to regular TLC NAND. Of course the cycles will against get worse as the process shrinks, but VNAND inherently has more write cycles than NAND, even at the same process size. I assume this other implementation will be similar.
In theory you only ever need one symmetric key assuming you have a strong cipher like AES and you assume the handshake can't be broken.
It only affects the handshakes, then it's all AES. Stop making lots of connections and use long lived connections. But like you said, how are the measuring it. 20% just for the handshake or 20% on average per web request?
Newer DWMD multiplexing tech allows for 400Gb-500Gb super-channels and near future versions are about to have 1Tb/s super-channels. A 500Gb single super-channel can support anything from 50 10Gb channels to a single 500Gb channel. Of course the current max bandwidth across all channels in a single fiber is about 32Tb/s, so they'll have to make do. 32Tb/s can have 320 100Gb/s streams. Suddenly 100Gb sounds slow.
I assume the money issue is more of a legacy system issue. Some hardware that an ISP purchases is very expensive and you only replace every 8 years. Maybe the last time they ordered some hardware, they wanted to save 20% to get some older equipment that didn't support IPv6. I know I can purchase a Layer 3 switch that does not support IPv6 for a decent chunk less than one that does.
All new equipment for a long time has supported IPv6, but why purchase new when you can purchase a generation or two old and get liquidation prices? When my ISP purchased all new gigabit fiber and replaced their core router with a new shiny one that has more 10Gb and 100Gb ports than they'll need for a long time, I'm sure it supports IPv6, but there is bound to be a few pieces of old gear that needs to go away. Then they need to get training and do planning before they attempt to roll it out.
They don't "own" them, they have a civil contract that says ARIN has granted them the right to use them and ARIN can't forcefully take them back as long as the original contract is valid. As soon as the IP blocks transfer owners, they are no longer grandfathered in. There have been a few exceptions to this rule early during the transitional phase, but ARIN is locking down on any more exceptions.
You can't use the high and low IPs and you at least need a gateway ip. 3 IPs per subnet are lost. I'm not sure what the 4th IP gets lost to.
Many set-top boxes like Roku support streaming from your home media server. They'll need LAN access in those cases.
"Built in caching proxy server" - Doesn't help with HTTPS and with just around the corner 10Gb internet, I challenge you to make a cheap device that can handle proxying data at 10Gb/s.
"The device needs a real time virus scanner that is automatically updated" - Not so much a virus scanner, but an IDS. Can't virus scan at 10Gb/s.
"Must of course include basic traffic shaping and other useful stuff" - Even professionals get Traffic shaping wrong most of the time. An AQM like Cake or fq_Codel is all that is needed. Fair queueing and flow isolation to combat bufferbloat.
"You could even use VPNs to link two homes together" - More features!
You have a lot of great ideas, but as it is, even $400 consume grade routers are riddled with security holes that never get fixed. They can't even get NAT or UPNP right, what makes you think they can do some of the more complicated features in a secure way? Remember, most of these devices are EoL by the time they can be purchased. Supporting devices is a cost and most companies don't want that.
Either people need to take responsibility for their own security or we need a better open source security framework and support that allows for companies to make the devices and let the opensource community handle the software side of things. We cannot trust companies to maintain bug fixes for their devices.
"Slow start" is relative. It is much slower than going strait to line rate, but it is an binary search that increases bandwidth exponentially per RTT. Many TCP implementations start off with a window size of 8 segments or more at full line rate. Most TCP implementations coalesce ACKs to reduce the number of ACK packets. This would mean every 2 segments gets an ACK. 8 segments sent means 4 ACKs which means 4 doulbings(16x) in just the first RTT. 16x 8 segments is 128 segments. a 20ms RTT with 128 1500 byte segments is 76.8Mb/s in the first 20ms, and will continue to double every 2 segments ACKed per RTT. By the time you are 40-60ms in, you should be at almost 200Mb/s. His 15 seconds is forever.
My example is a little bit simplified because once a TCP stream gets moving, the packets are spaced apart, only the initial transfer will burst all segments in the window at line rate. A bit of trivia. Google modified their TCP stack to increase the number of initial bursted segments because most responses are quite small, and if you can fit the entire response in the initial burst the client only needs to wait one RTT, but if there are any more segments to be sent, the client now has to wait at least 2-RTTs, even if it's one more segment.
I have a 1Gb link that is rate limited to 100Mb. When I download files, wireshark shows a 1Gb burst of 30 1500 byte packets back-to-back, then my ISP's rate limiting starts to clamp down and the traffic shaping starts to space out the TCP flow and dials down to my 100Mb provisioned rate. This all happens in the first second, not 15-20 seconds. Although I have an 10ms RTT to every major datacenter in Chicago via Level 3 Comm. Low RTTs allow TCP to quickly ramp up. My ISP does have one CDN on their network, akamai. 1.5ms ping.
10ms to Chicago, 30ms to New York City and Atalanta and Washington(AWS), 40ms to Texas and Florida, and 60ms to Cali. Short RTTs help a lot with TCP.
Bandwidth isn't everything, ping, jitter, and loss are also important. Jitter typically indicates congestion and so does loss. I can reach every major datacenter in the world with under a 250ms RTT. That includes Moscow, India, China, Japan, South Korea, New Zealand, and Australia. Also, all under 1ms of jitter.
Except they legally own those IP blocks because of contracts when rules were different a long time ago. Mob rule, steal people's property!
ARIN already laid out several phases. A few months ago they started to limit how many IPs they handed out, a month ago they started to reject some requests. We're reaching the end game, which includes reclaiming IPs. You will need to prove every year that you still need your blocks more than others, and every year ARIN will get more strict and refuse renewal for some customers so other customers that are more deserving get some. It will start to get painful.
Some CDNs are seeing 18%-40% of web requests from AT&T, Verizon, or Comcast are over IPv6. IPv6 is still growing at an exponential rate for almost a decade now, about 100% per year. At the current about 10% of all USA, given 100% growth that hasn't shown any signs of stopping, we'll be at 40% in two years and 80% in 3 years.
HTTP1.1 is a huge limitation. You need a lot of connections to make any decent use of your bandwidth. I find that even slow websites are mostly a latency vs throughput issue. The data comes in bursted at 1Gb/s, but there are large gaps between the responses.
Not just block sized inserts, but also inserts at block boundaries. And block sized inserts only works for dedup. CoW won't help with dedup off if the blocks shift, but no issues flipping bits or appending.
We don't need a /48 per person, just per household. With 3 people per household, that's saves you almost 2 bits! Meant to be funny. 1 bit isn't that useful of a difference.
The idea is one machine, one address
More like 5 IPs per computer. Each for different usages.
But my router and switch and computers just crashed, how does IPv6 handle that? DNS servers are critical infrastructure. Shit will break when they go down, get used to it.