top | item 40774320

(no title)

teknologist | 1 year ago

None in that case. But with these cards there’s less need for centralization of data storage and code logic

discuss

order

CraigJPerry|1 year ago

>> there’s less need for centralization of data storage and code logic

You make it sound like less moving parts are a bad thing :-)

I know what you're getting at though - the decentralized tolerance of network partitions and the ability to provide higher availability and faster decision speed at the entry barrier.

The system design constraints are hard but not impossible, my back of napkin maths says 5k/ticket scans per second with 99th percentile latency < 1000ms not only satisfies every use case that exists today but allows for 3x population growth beyond!

There's a few things in your favour when designing this system though. For example, in the case of network partition, you have geographic locality so a pen drive delivered a couple of times per day is likely feasible.

rswail|1 year ago

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:

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).

teknologist|1 year ago

1000ms is a surprisingly long wait at a ticket barrier, though! Latency is everything in this use case...