If 150 hours was adequate performance, it doesn't matter even if it could have been done in 2 seconds. If 150 hours is inadequate performance, then they must have had a target time that the calculation needed to be done in. What difference what is achievable? Your business requirements should drive target performance times, not some arbitrary target of what can be achieved by other applications.
The fact that you didn't know how long things would take (wireless system) is one thing. That is not uncommon. That's what performance testing is for. Not having targets under different loads is another. Marketing's job is to do the customer research to find out what was acceptable to users. Leaving it to engineers to set times with no input from sales/marketing just means that you get them coming back saying "that's too slow".
Here's some figures for you
Response time is the primary performance target.
Primary guideline, make sure you set the users' expectation of how long any task will take. In the absence of a guide from the app, the user expects task time to be more or less instantaneous (so is always disappointed)
UI should remain responsive at all times, even when user initiated activity is occuring. For any activity which will take more than a tenth of a second, status should be displayed. For less than half a second, status messages are sufficient, but beyond that a status bar is preferred.
In the absence of expectation, if an activity will take more than one second user patience begins to stall. Over two seconds and the chance of abandoning the activity starts to increase. By eight seconds, the chances are very high that the user will abandon the task (various studies including IBM studies and more recent web page interactive studies).
Another study shows that the users memory of the "average" response time is actually the response time that corresponds to approximately the 90th percentile response time, i.e. the response time which is higher than 90% of response times encountered for the task.
Sound streams and video streams are different. Users identify stalls and gaps in streams very easily. Lowering the resolution is better than losing time segments. I don't have hard figures in this area.
Throughput (number of requests served per second/minute); transactions rates (number of transactions completed per second/minute); response time; and concurrency levels (the number of simultaneous requests being handled by the server) are the primary performance targets.
Good performance (achievable currently with J2EE) has sub-second response times and hundreds of (e-commerce) transactions per second. Servlets running on an average single server configuration machine can serve tens of dynamically built pages per second.
Near real-time systems (e.g. telco systems):
If a response will take longer than 200 ms, that needs to be signalled to the caller. No response in 500 ms is essentially a lost request. This essentially means that round-trip response times should be 500 ms or less. http://www.ietf.org/rfc/rfc2543.txt
What other systems do we you to talk about?
--Jack Shirazi JavaPerformanceTuning.com