Now, I have to wonder why wouldn’t they implement the compression. I’m inclined to think they actually did, but shipped the wrong build; It makes more sense than the alternative.
What I got from this write-up is even if compression was there, it wouldn’t have worked.
The system depends on having uncompressed pages that it’s running against. This driver statically allocates a chunk of memory to compress pages into. It can’t allocate all system memory (or anything close) without causing programs to have insufficient uncompressed pages. But since it can only use a fraction of RAM, the compression ratio only applies to that fraction. So, if you have a system with 8Mb RAM, and use a 2Mb compressed buffer, and get a 2:1 compression ratio…the system has 6Mb of addressable RAM with 10Mb of data stored in memory, so the amount of data in memory increases by 25%.
The claim, on the box, in the UI, was that it would (and did) double system memory. With this architecture, it had no realistic chance to do that. Getting there would require storing 8Mb of uncompressed data into a 2Mb compressed buffer - a 4:1 compression ratio out of a 486.
There were a lot of things about this product that contribute to the label “scam.” It had a polished UI that made claims about how much memory it was generating, and hooked APIs to indicate more RAM existed than really did. If those numbers were actually generated by querying how much data was in the compressed buffer, it’d make sense, but then they’d know that the product isn’t working. That UI had to just make up random numbers, so even if the driver was working, the UI claims weren’t connected to reality.
High quality software, no doubt.
Now, I have to wonder why wouldn’t they implement the compression. I’m inclined to think they actually did, but shipped the wrong build; It makes more sense than the alternative.
Yeah, it’d be a lot of effort for a scam, when you can simply not write a driver instead.
What I got from this write-up is even if compression was there, it wouldn’t have worked.
The system depends on having uncompressed pages that it’s running against. This driver statically allocates a chunk of memory to compress pages into. It can’t allocate all system memory (or anything close) without causing programs to have insufficient uncompressed pages. But since it can only use a fraction of RAM, the compression ratio only applies to that fraction. So, if you have a system with 8Mb RAM, and use a 2Mb compressed buffer, and get a 2:1 compression ratio…the system has 6Mb of addressable RAM with 10Mb of data stored in memory, so the amount of data in memory increases by 25%.
The claim, on the box, in the UI, was that it would (and did) double system memory. With this architecture, it had no realistic chance to do that. Getting there would require storing 8Mb of uncompressed data into a 2Mb compressed buffer - a 4:1 compression ratio out of a 486.
There were a lot of things about this product that contribute to the label “scam.” It had a polished UI that made claims about how much memory it was generating, and hooked APIs to indicate more RAM existed than really did. If those numbers were actually generated by querying how much data was in the compressed buffer, it’d make sense, but then they’d know that the product isn’t working. That UI had to just make up random numbers, so even if the driver was working, the UI claims weren’t connected to reality.