Did a project several years where the customrr required that the server we delivered specifically for the project never use more than 50% CPU or RAM. No requirements about how fast it actually performs its intended function, just that it can only utilise half the available resources while doing it.
Probably a bleed-over from the embedded side. Spent a lot of years working embedded control systems for NASA and DoD - bare metal systems, often interrupt driven - and it was common to have 50% margin requirements. They know those systems will grow over time, and they often have lifespans measured in decades.
That would make sense, i hadn’t put that together but they had a lot of embedded control systems. This was water treatment but entirely separate from the control systems but i can see them having that a standard requirement
So was it a government (state or federal) water treatment plant? If so, I can tell you how it happened. The government contracting agencies have boilerplate text they’re supposed to add to contracts to make sure salient requirements get flowed. They’re supposed to delete or tailor anything that doesn’t make sense, but the contracts people aren’t usually very technical. We had requirements flowed to us about password management and account monitoring, but no one logs into a rocket engine or a torpedo. When we’d point it out, they’d say “oops, we should have deleted that.”
Not in the US, our water infrastructure was sold off in 90s but that makes sense. Was probably something similar
They held us to it though so they overpaid for hardware beyond their needs and we forced the software to run slower
Yeah, we have that with our customers sometimes. To me, an app should either be running full whack - maxing out bandwidth on CPU, disk, memory or network - or completely idle. Chuntering along at 2% is a bug. For the ones that put ‘monitoring tools’ that raise errors when we reach 100% on something, we set a Linux CGroup to throttle the offending resource. Takes longer, obviously, but not worth arguing with their network deployment teams 🤷 .
Did a project several years where the customrr required that the server we delivered specifically for the project never use more than 50% CPU or RAM. No requirements about how fast it actually performs its intended function, just that it can only utilise half the available resources while doing it.
Probably a bleed-over from the embedded side. Spent a lot of years working embedded control systems for NASA and DoD - bare metal systems, often interrupt driven - and it was common to have 50% margin requirements. They know those systems will grow over time, and they often have lifespans measured in decades.
That would make sense, i hadn’t put that together but they had a lot of embedded control systems. This was water treatment but entirely separate from the control systems but i can see them having that a standard requirement
So was it a government (state or federal) water treatment plant? If so, I can tell you how it happened. The government contracting agencies have boilerplate text they’re supposed to add to contracts to make sure salient requirements get flowed. They’re supposed to delete or tailor anything that doesn’t make sense, but the contracts people aren’t usually very technical. We had requirements flowed to us about password management and account monitoring, but no one logs into a rocket engine or a torpedo. When we’d point it out, they’d say “oops, we should have deleted that.”
Not in the US, our water infrastructure was sold off in 90s but that makes sense. Was probably something similar They held us to it though so they overpaid for hardware beyond their needs and we forced the software to run slower
Yeah, we have that with our customers sometimes. To me, an app should either be running full whack - maxing out bandwidth on CPU, disk, memory or network - or completely idle. Chuntering along at 2% is a bug. For the ones that put ‘monitoring tools’ that raise errors when we reach 100% on something, we set a Linux CGroup to throttle the offending resource. Takes longer, obviously, but not worth arguing with their network deployment teams 🤷 .
That RAM is mint condition collectors edition RAM. We’re just storing it there temporarily.
Don’t you dare fucking touch it.
My software does that anyway because I can’t be arsed with multithreading or a 64 bit version