They use TPS as a unit because that's how large banks and other transaction oriented entities do their provisioning and capacity planning. That's their 'unit', not CPU cycles.
There are industry-standard benchmarks that measure TPS. See for example (or maybe not even for example; it may be effectively the only one in town) http://www.tpc.org/information/benchmarks.asp.
And of course, anybody considering buying such a machine will spend quite a bit on evaluating how it performs under their load, just like SPEC (https://www.spec.org/) says something, but not all.
I've looked at the tpc.org maybe 13 years ago. It never made sense to me to use it as a measurement unit back then and it still don't make sense to me now. :)
Because they are not arguing with scientists but with "decision makers". So bullshit is more important than proven facts... Tanksfully, banks are moving slowly out of mainframes. You'll never find a new business going on a mainframe. Mainframes users are captive, not free.
You're thinking very much in terms of a PC architecture. Many components of the mainframe including a lot of the I/O hardware and some instructions in the assembly language itself are record oriented, and within reasonable limits operate on an entire record at once. It's not that big of a jump to go from entire records being atomic operations to at least speaking about entire transactions being the basic, atomic units of computation in the system.
Like a row in a table. I/O instructions in S/360 (as I recall) assembler would fetch an entire record in a single instruction / cycle (the I/O devices are radically different and would support this - it wasn't just syntactic sugar around reading a word or byte at a time). So the time to read in a record, perform some operations and write a record back out is actually much more predictable based on clock speed than it sounds like it would be to someone from a PC background.
Row and table would be the database terminology. In mainframes you have records in datasets, but they're the same thing: tuples of fields. It's just that in a mainframe to maximize throughout a lot of the work like dealing with natively supported data formats is offloaded to special I/O controllers, which makes it easier to work with via low-level assembly instructions.
Comments
what's a transaction in this context?
http://en.wikipedia.org/wiki/Transaction_processing_system
I know that but this is a very general definition of TPS. How many CPU cycles a transaction requires? It varies on the transaction of course.
So I am wondering why they use TPS as a unit when it can be anything.
They use TPS as a unit because that's how large banks and other transaction oriented entities do their provisioning and capacity planning. That's their 'unit', not CPU cycles.
But how can they claim they can do X transactions when a transaction's processing requirement is undefined?
There are industry-standard benchmarks that measure TPS. See for example (or maybe not even for example; it may be effectively the only one in town) http://www.tpc.org/information/benchmarks.asp.
And of course, anybody considering buying such a machine will spend quite a bit on evaluating how it performs under their load, just like SPEC (https://www.spec.org/) says something, but not all.
I've looked at the tpc.org maybe 13 years ago. It never made sense to me to use it as a measurement unit back then and it still don't make sense to me now. :)
Because they are not arguing with scientists but with "decision makers". So bullshit is more important than proven facts... Tanksfully, banks are moving slowly out of mainframes. You'll never find a new business going on a mainframe. Mainframes users are captive, not free.
You're thinking very much in terms of a PC architecture. Many components of the mainframe including a lot of the I/O hardware and some instructions in the assembly language itself are record oriented, and within reasonable limits operate on an entire record at once. It's not that big of a jump to go from entire records being atomic operations to at least speaking about entire transactions being the basic, atomic units of computation in the system.
Define a record.
Also can you elaborate more on how ASM instructions can be record oriented?
Like a row in a table. I/O instructions in S/360 (as I recall) assembler would fetch an entire record in a single instruction / cycle (the I/O devices are radically different and would support this - it wasn't just syntactic sugar around reading a word or byte at a time). So the time to read in a record, perform some operations and write a record back out is actually much more predictable based on clock speed than it sounds like it would be to someone from a PC background.
to the CPU, what's a row and what's a table in this context.
Row and table would be the database terminology. In mainframes you have records in datasets, but they're the same thing: tuples of fields. It's just that in a mainframe to maximize throughout a lot of the work like dealing with natively supported data formats is offloaded to special I/O controllers, which makes it easier to work with via low-level assembly instructions.
How many TPS Reports per second can it issue?