The usual maximum time allowed for tap->barrier open is a maximum of 450ms. That includes all read/write times for the token, display changes, fare calculations and deductions, all business rule validation (eg hotlisting stolen tokens etc).
The system I recently put in allowed for that 450ms, the time broke down to:
During peak periods the usual rate expected is 30-40 passengers through a gate/minute, which includes all of the time above, plus the passengers actually walking through the barriers (usually ~2m).
Not relevant. The maximum specified by contract is usually 450-500ms.
The barriers at rail stations have to have a defined maximum throughput of passengers, because it affects safety during emergencies etc. Most barriers are required to maintain somewhere between 30 and 45 passengers per minute.
Yes they can "default be open" and usually have emergency modes that disable validation entirely, but the speed during peak hour periods has to maintain the passenger flow.
The system I recently put in allowed for that 450ms, the time broke down to:
1) NFC comms ~100ms
2) Network comms ~50-100ms
3) Physical relays (releasing barriers etc) 100-200ms
During peak periods the usual rate expected is 30-40 passengers through a gate/minute, which includes all of the time above, plus the passengers actually walking through the barriers (usually ~2m).