The OS is responsible for being a reliable source of trusted entropy. There are many ways to create strong pseudo-random numbers, some are faster than others, but all can be strong. Random numbers are a complex issue that should be implemented once and implemented well. Doing random in user land is a horrible idea and has been a reoccurring issue over the years. You also run the issue that software may not get upgraded, but the OS can. Single point of responsibility and all that jazz.
Kind of like how it is recommended not to implement your own version of TCP and let the OS handle it. Could you imagine if random software implemented their own network stacks?
Max Sequential Read Up to 540MB/s
Max Sequential Write Up to 520MB/s
4KB Random Read
Random read (QD1) [IOPS]: up to 10,000 IOPS
Random read (QD32) [IOPS]: up to 197,000 IOPS
4KB Random Write
Random Write (QD1) [IOPS]: up to 40,000 IOPS
Random Write (QD32) [IOPS]: up to 88,000 IOPS
I assume what you're talking about is the QD1 4k random read that is important. Yes, they have that information front and center. 10,000 4k blocks every second is about 40MB/s. About 700MB/s with a queue depth of 32. Actual benchmarks are showing 4k random reads of 50MB/s for a QD=1 and 400MB for a QD=32.
"Power loss protection" seems to universally indicate that the SSD can flush all contents of the cache, not just block tables. It is not specifically documented anywhere, but with newer drives being a lot more stable and earlier generations, it's entirely possible that they immediately flush the internal state on power loss.
One of the features of the Samsung 850s is they can dynamically change MLC into SLC and maintains 3GB of SLC for quick writes. One of their claims is that this allows the dram to be quickly flushed to the SLC and written to MLC over time, and can resume after power loss.
SSDs with "power loss protection" store enough power to write out all of their cache, which is something like 1GB now days. Like we've mentioned, we don't care about caches not being flushed, but how to the internal mapping tables hold up without "power loss protected". My hope would be that modern controllers can handle keeping internal state and just screw the data in cache.
I was reading about Samsung's "RAPID Mode" that uses system memory as a write cache to speed up writes to the SSD. One of the topics about "RAPID Mode", which is even more sensitive to power loss because of increase caching, is that it handles power loss "well". They have done extensive testing with "RAPID Mode" and power loss. I figure if they can offer 10 year warranties and feel confident about these issues, I'll trust them until proven otherwise. They have a great track record. I still wouldn't put all of my eggs in one basket.
The 850s are known for nearly 1PB of writen, come with a 170TB 5 year warranty for 250GB+ models. According to an interview with Samsung, going over the 170TB limit will not always void your warranty, as long as it was "consumer" workloads. I guess they have 120GB drives in their shop with over 8PB of data written to them.
I would like to more about this topic. According to Samsung, the 850 drives reserve a portion of the drive to use as SLC allowing the DRAM to be quickly written to the SLC and allows the drive to slowly write out to the MLC. From the sounds of it, Samsung is less concerned about the drive internal state getting corrupted and committed data being lost and more concerned with in-flight data that hasn't been written being committed.
I'm also not concerned with losing data during a write, I just don't want to lose my drive. I wish there was more information on this topic.
Intel has a bug that makes you lose all of your data, oops. Samsung has a bug that reduces the speed of your drive, then they offer a fix, OMG BURN THEM!
All of your points have already been extensively looked over and discarded as "not possible". "Dark Matter" is almost 100 years old. It is the longest standing scientific unknown in all of history. If you think you're smarter than 100 years of scientists, you have quite the ego.
We also "assume" normal matter exists using the same definition of "assume'". It is true that Dark Matter could be a collection of stuff and not a single thing, but we know for sure that it is not normal.
Multiplexing doesn't offer that much speed increase as some people would like you to believe
Limit your browser to one connection per server and tell me that with a strait face. TCP has horrible congestion control and should not be used to multiplex web requests.
Re:Great if optimizing the wrong thing is your thi
on
HTTP/2 Finalized
·
· Score: 1
Have you ever purchased a $250,000 firewall, reverse proxy, and encryption accelerator all-in-one device? These things are meant to handle 10mil HTTPS connections at full duplex 10Gb/s, and establish 400,000 new HTTPS connection per second. Plus, they can re-write and otherwise manipulate HTTP headers. All of this in real time at 10gb/10gb rates. It is not an easy thing to do when parsing text. Binary is much easier to accelerate.
Wow, thanks for the list. I'll have to see if Chrome has anything like "YouTube HD". I hate how YouTube defaults to 480p for me, buffers about 1/2 of the video instantly, then I switch to 720p just to have it reload. Seems so wasteful since I almost exclusive use 720p for my low resolution, except when listening to mix-music.
You sir, are an idiot. Please stop spouting horrible information. There are only a few situations where multiple connections are faster and it primarily has to do with load balancing over aggregate links or laod balancing CPU cores. Multiple TCP streams are almost always a bad thing. They may seem faster, but only because other people do it, over all, it's slower.
Lots of TCP connections between two end points is known to exasperate issues like buffer bloat and global synchronization. Each additional TCP connection effectively works as a multiplier. TCP may want to increase PPS by 1, but because you have N connections, you increase PPS by N, making the ramp up too aggressive, and also increase the rate of packet-loss, which makes the back-off also more aggressive. What happens when you get global synchronization of many end points that are aggressively ramping up and backing off at the same time? Bad things.
Re:Great if optimizing the wrong thing is your thi
on
HTTP/2 Finalized
·
· Score: 1
My understanding is the use of binary is to simplify parsing. It's a lot harder to hardware accelerate a mark up language than looking for byte codes in an ASIC.
Long ago I wrote an OS with only a few lines of code, try to do that with protected mode. HTTP/1.1 has some serious limitations that makes high latency high bandwidth connections feel like dial-up.
Some of what HTTP2 is trying to fix the issues with TCP by multiplexing multiple streams over a single TCP connection instead of over many TCP connections. anyone with basic understandings of how TCP, HTTP, HTTPS, and networks interact will understand why HTTP2 has major benefits. It's more like a bandaid over other fundamental network issues, but it's better than what we got.
Also, HTTP/1 already allows a browser to send multiple requests without waiting for the response of the previous request.
Incorrect. HTTP/1.1's pipelining is blocking, in that the responses must be returned in the order they were requested. It has a front of line blocking issue.
Re:Great if optimizing the wrong thing is your thi
on
HTTP/2 Finalized
·
· Score: 4, Informative
It's a bandwidth vs latency issue. HTTP1/1.1 is more latency sensitive, HTTP2 helps high latency. You say that pages load slowly because they're so large, yet these large bloated web pages consume nearly no bandwidth. HTTP2 multiplexing allows async requests and preemptive pushing of data, which should allow better usage of bandwidth. Fewer connections will also allow for quicker TCP relieve window ramp up and reduce the thundering hurd issue that many connections over a congested link creates.
"Obvious" is a relative term. What is obvious to a master in a field is not obvious to an untrained monkey. Plus there is virtually no incentive to reject patents and the rules around rejecting patents is so vague, the person who rejects a patent could get in a lot of trouble. They also base how good a patent clerk is doing based on the number of patent granted. There's a lot of bias in the system.
Well, based on what I've read anyway. I don't actually work at the patent office or know anyone who does.
Slashdot Mirror
The OS is responsible for being a reliable source of trusted entropy. There are many ways to create strong pseudo-random numbers, some are faster than others, but all can be strong. Random numbers are a complex issue that should be implemented once and implemented well. Doing random in user land is a horrible idea and has been a reoccurring issue over the years. You also run the issue that software may not get upgraded, but the OS can. Single point of responsibility and all that jazz.
Kind of like how it is recommended not to implement your own version of TCP and let the OS handle it. Could you imagine if random software implemented their own network stacks?
I jumped on NewEgg and got greeted with this
Max Sequential Read Up to 540MB/s
Max Sequential Write Up to 520MB/s
4KB Random Read
Random read (QD1) [IOPS]: up to 10,000 IOPS
Random read (QD32) [IOPS]: up to 197,000 IOPS
4KB Random Write
Random Write (QD1) [IOPS]: up to 40,000 IOPS
Random Write (QD32) [IOPS]: up to 88,000 IOPS
I assume what you're talking about is the QD1 4k random read that is important. Yes, they have that information front and center. 10,000 4k blocks every second is about 40MB/s. About 700MB/s with a queue depth of 32. Actual benchmarks are showing 4k random reads of 50MB/s for a QD=1 and 400MB for a QD=32.
"Power loss protection" seems to universally indicate that the SSD can flush all contents of the cache, not just block tables. It is not specifically documented anywhere, but with newer drives being a lot more stable and earlier generations, it's entirely possible that they immediately flush the internal state on power loss.
One of the features of the Samsung 850s is they can dynamically change MLC into SLC and maintains 3GB of SLC for quick writes. One of their claims is that this allows the dram to be quickly flushed to the SLC and written to MLC over time, and can resume after power loss.
SSDs with "power loss protection" store enough power to write out all of their cache, which is something like 1GB now days. Like we've mentioned, we don't care about caches not being flushed, but how to the internal mapping tables hold up without "power loss protected". My hope would be that modern controllers can handle keeping internal state and just screw the data in cache.
I was reading about Samsung's "RAPID Mode" that uses system memory as a write cache to speed up writes to the SSD. One of the topics about "RAPID Mode", which is even more sensitive to power loss because of increase caching, is that it handles power loss "well". They have done extensive testing with "RAPID Mode" and power loss. I figure if they can offer 10 year warranties and feel confident about these issues, I'll trust them until proven otherwise. They have a great track record. I still wouldn't put all of my eggs in one basket.
The 840 EVO performance issue was fixed with a firmware update.
The 850s are known for nearly 1PB of writen, come with a 170TB 5 year warranty for 250GB+ models. According to an interview with Samsung, going over the 170TB limit will not always void your warranty, as long as it was "consumer" workloads. I guess they have 120GB drives in their shop with over 8PB of data written to them.
I would like to more about this topic. According to Samsung, the 850 drives reserve a portion of the drive to use as SLC allowing the DRAM to be quickly written to the SLC and allows the drive to slowly write out to the MLC. From the sounds of it, Samsung is less concerned about the drive internal state getting corrupted and committed data being lost and more concerned with in-flight data that hasn't been written being committed.
I'm also not concerned with losing data during a write, I just don't want to lose my drive. I wish there was more information on this topic.
You can purchase two 1TB SSDs and mount them in this http://www.newegg.com/Product/...
Modern MLC drives are able to handle nearly 1PB of writes. I'm not sure what more you want from a 120GB SSD.
Intel has a bug that makes you lose all of your data, oops. Samsung has a bug that reduces the speed of your drive, then they offer a fix, OMG BURN THEM!
They've already accounted for all forms of known types matter, including brown/black dwarfs.
All of your points have already been extensively looked over and discarded as "not possible". "Dark Matter" is almost 100 years old. It is the longest standing scientific unknown in all of history. If you think you're smarter than 100 years of scientists, you have quite the ego.
We also "assume" normal matter exists using the same definition of "assume'". It is true that Dark Matter could be a collection of stuff and not a single thing, but we know for sure that it is not normal.
Multiplexing doesn't offer that much speed increase as some people would like you to believe
Limit your browser to one connection per server and tell me that with a strait face. TCP has horrible congestion control and should not be used to multiplex web requests.
Have you ever purchased a $250,000 firewall, reverse proxy, and encryption accelerator all-in-one device? These things are meant to handle 10mil HTTPS connections at full duplex 10Gb/s, and establish 400,000 new HTTPS connection per second. Plus, they can re-write and otherwise manipulate HTTP headers. All of this in real time at 10gb/10gb rates. It is not an easy thing to do when parsing text. Binary is much easier to accelerate.
Hear Hear!
Wow, thanks for the list. I'll have to see if Chrome has anything like "YouTube HD". I hate how YouTube defaults to 480p for me, buffers about 1/2 of the video instantly, then I switch to 720p just to have it reload. Seems so wasteful since I almost exclusive use 720p for my low resolution, except when listening to mix-music.
Using multiple connections is faster...
You sir, are an idiot. Please stop spouting horrible information. There are only a few situations where multiple connections are faster and it primarily has to do with load balancing over aggregate links or laod balancing CPU cores. Multiple TCP streams are almost always a bad thing. They may seem faster, but only because other people do it, over all, it's slower.
Lots of TCP connections between two end points is known to exasperate issues like buffer bloat and global synchronization. Each additional TCP connection effectively works as a multiplier. TCP may want to increase PPS by 1, but because you have N connections, you increase PPS by N, making the ramp up too aggressive, and also increase the rate of packet-loss, which makes the back-off also more aggressive. What happens when you get global synchronization of many end points that are aggressively ramping up and backing off at the same time? Bad things.
My understanding is the use of binary is to simplify parsing. It's a lot harder to hardware accelerate a mark up language than looking for byte codes in an ASIC.
Long ago I wrote an OS with only a few lines of code, try to do that with protected mode. HTTP/1.1 has some serious limitations that makes high latency high bandwidth connections feel like dial-up.
Some of what HTTP2 is trying to fix the issues with TCP by multiplexing multiple streams over a single TCP connection instead of over many TCP connections. anyone with basic understandings of how TCP, HTTP, HTTPS, and networks interact will understand why HTTP2 has major benefits. It's more like a bandaid over other fundamental network issues, but it's better than what we got.
Also, HTTP/1 already allows a browser to send multiple requests without waiting for the response of the previous request.
Incorrect. HTTP/1.1's pipelining is blocking, in that the responses must be returned in the order they were requested. It has a front of line blocking issue.
It's a bandwidth vs latency issue. HTTP1/1.1 is more latency sensitive, HTTP2 helps high latency. You say that pages load slowly because they're so large, yet these large bloated web pages consume nearly no bandwidth. HTTP2 multiplexing allows async requests and preemptive pushing of data, which should allow better usage of bandwidth. Fewer connections will also allow for quicker TCP relieve window ramp up and reduce the thundering hurd issue that many connections over a congested link creates.
"Obvious" is a relative term. What is obvious to a master in a field is not obvious to an untrained monkey. Plus there is virtually no incentive to reject patents and the rules around rejecting patents is so vague, the person who rejects a patent could get in a lot of trouble. They also base how good a patent clerk is doing based on the number of patent granted. There's a lot of bias in the system.
Well, based on what I've read anyway. I don't actually work at the patent office or know anyone who does.
Yeah, a VPN with a single 1Gb port that shares with 10+ other people.