3 ms·

a common network topology is to have a load balancer distribute load to a number of cheap Http servers which internally connect to a centralized and powerful da

a common network topology is to have a load balancer distribute load to a number of cheap Http servers which internally connect to a centralized and powerful database server. In this case only the database server really needs ECC ram. The system is designed to be fault tolerant for any individual HTTP server node so the increased cost vs the problem it solves doesn't make sense. I guess you could argue that a random bit flip could somehow make the HTTP server vulnerable and able to compromise the network however that risk is impossibly small. If we take IBMs estimation that a bit flip occurs at an approximate rate of (3.7 × 10-9) bytes/month and then divide it by the number of bytes in the system you can see that the odds of randomly corrupting a byte in memory that triggers a vulnerability is too small.

fulafel 10y ago
What about memory-error corrupted application data (or application logic) where the corruption occurred on load balancers or web application servers? There's more to data integrity than security holes.
- blackflame7000 10y ago
  If you write code that detects stack smashing and illegal dereferences then you can terminate the webservice and either have a watchdog restart it or if it crashes multiple times have it taken out of service by the load balancer. There are plenty of ways to handle hardware errors without throwing out the hardware and getting "better" hardware. Technically, You could have a faulty component somewhere between the Ram and CPU and then what is your expensive ram going to do? What if the CPU cache has errors? For many small businesses often the difference between success and failure is their ability to make things work without throwing cash at the problem.
  - deleted 10y ago
    [deleted]
  - fulafel 10y ago
    Even with your proposed checks there remains a high probability to just get silent application data corruption, not crashes. Regarding faulty components, that is one part of ECC's job, but the other part is correcting the regular bit flips that happen with nominally operating DRAM. Flagging faulty components is more useful than you propose. There are not that many places where this corruption can occur, so being able to rule out RAM is very useful. The example you used, CPU caches, is actually already covered by ECC in most CPUs, including reasonably recent x86/amd64. The tradeoff would be more worthy of thought if ECC was much more expensive
    - blackflame7000 10y ago
      ECC ram is not a raid. If corrosion on a trace causes a bit flip from an adjacent line then the ram will recieve rhe corrupt data as valid. There is no parity ram stick to recover from. I never said ECC ram doesnt have a purpose. Im saying you are wasting your money if you think it's essential to running a web sever. Lets be real here, like 80% of computers on the internet stream porn. They dont need ecc ram
    - deleted 10y ago
      [deleted]
ori_b 10y ago
> In this case only the database server really needs ECC ram. That's only true if the database is read only. Otherwise, you will still insert corrupt data into it.
- blackflame7000 10y ago
  Assuming you dont do any input validation checking which is foolish for a database server particularly one dealing with SQL
  - ori_b 10y ago
    So, I've sent an int32 representing a payment amount. One of the low order bits gets flipped. Can you explain to me how I'd validate it?
    - blackflame7000 10y ago
      Compare the cost of the transaction to the price paid. First parse the payment amount from the client and store in in a bad region of memory. Then compare that variable with the transaction amount. When you read from the variable it will be corrupt and not match. Log the Error as High Priority because it shouldn't occur. Just saved you a ton with a simple if statement.
      - ori_b 10y ago
        > Compare the cost of the transaction to the price paid. The cost of the transaction is, by definition, the price paid. `if x != x: raise_error()` only works if x is NaN.
        blackflame7000 10y ago
        No the price of the transaction is the sum of the items in your shopping cart which is usually stored as a session variable or cookie. The price paid is the value charged to a customer which is gathered from an input parameter on form submission. If you are attempting to bill someone 1000$ for an item that cost 10 then you have a problem. You should know what the value of every item in your inventory is right? And you should also know when said item is being purchased if you are charging someone for it. If you didnt do this check what's to stop someone from submitting a payment of 10$ for a product that cost 1000$? Your fancy system with ECC Ram would let it go through and you just lost 990$ because you thought hardware could fix your software mistakes. This is a ridiculous conversation because data corruption could happen in the CPU cache, the QPI, or a number of micro-components in between the ram and cpu that could cause errors that ECC Ram can't fix. ECC ram is not a catch all for poor programming and poor validation checking period.

fulafel 10y ago

What about memory-error corrupted application data (or application logic) where the corruption occurred on load balancers or web application servers? There's more to data integrity than security holes.

blackflame7000 10y ago
If you write code that detects stack smashing and illegal dereferences then you can terminate the webservice and either have a watchdog restart it or if it crashes multiple times have it taken out of service by the load balancer. There are plenty of ways to handle hardware errors without throwing out the hardware and getting "better" hardware. Technically, You could have a faulty component somewhere between the Ram and CPU and then what is your expensive ram going to do? What if the CPU cache has errors? For many small businesses often the difference between success and failure is their ability to make things work without throwing cash at the problem.
- deleted 10y ago
  [deleted]
- fulafel 10y ago
  Even with your proposed checks there remains a high probability to just get silent application data corruption, not crashes. Regarding faulty components, that is one part of ECC's job, but the other part is correcting the regular bit flips that happen with nominally operating DRAM. Flagging faulty components is more useful than you propose. There are not that many places where this corruption can occur, so being able to rule out RAM is very useful. The example you used, CPU caches, is actually already covered by ECC in most CPUs, including reasonably recent x86/amd64. The tradeoff would be more worthy of thought if ECC was much more expensive
  - blackflame7000 10y ago
    ECC ram is not a raid. If corrosion on a trace causes a bit flip from an adjacent line then the ram will recieve rhe corrupt data as valid. There is no parity ram stick to recover from. I never said ECC ram doesnt have a purpose. Im saying you are wasting your money if you think it's essential to running a web sever. Lets be real here, like 80% of computers on the internet stream porn. They dont need ecc ram
  - deleted 10y ago
    [deleted]

ori_b 10y ago

> In this case only the database server really needs ECC ram. That's only true if the database is read only. Otherwise, you will still insert corrupt data into it.

blackflame7000 10y ago
Assuming you dont do any input validation checking which is foolish for a database server particularly one dealing with SQL
- ori_b 10y ago
  So, I've sent an int32 representing a payment amount. One of the low order bits gets flipped. Can you explain to me how I'd validate it?
  - blackflame7000 10y ago
    Compare the cost of the transaction to the price paid. First parse the payment amount from the client and store in in a bad region of memory. Then compare that variable with the transaction amount. When you read from the variable it will be corrupt and not match. Log the Error as High Priority because it shouldn't occur. Just saved you a ton with a simple if statement.
    - ori_b 10y ago
      > Compare the cost of the transaction to the price paid. The cost of the transaction is, by definition, the price paid. `if x != x: raise_error()` only works if x is NaN.
      - blackflame7000 10y ago
        No the price of the transaction is the sum of the items in your shopping cart which is usually stored as a session variable or cookie. The price paid is the value charged to a customer which is gathered from an input parameter on form submission. If you are attempting to bill someone 1000$ for an item that cost 10 then you have a problem. You should know what the value of every item in your inventory is right? And you should also know when said item is being purchased if you are charging someone for it. If you didnt do this check what's to stop someone from submitting a payment of 10$ for a product that cost 1000$? Your fancy system with ECC Ram would let it go through and you just lost 990$ because you thought hardware could fix your software mistakes. This is a ridiculous conversation because data corruption could happen in the CPU cache, the QPI, or a number of micro-components in between the ram and cpu that could cause errors that ECC Ram can't fix. ECC ram is not a catch all for poor programming and poor validation checking period.