News   Nov 28, 2024
 546     0 
News   Nov 28, 2024
 1K     2 
News   Nov 28, 2024
 808     0 

Metrolinx: Presto Fare Card

Issue is, say one streetcar sends a packet, but then you have hundreds of buses and streetcars sending and downloading packets for the updated list and soon enough you find that the data requirements start to overload the processing and bandwidth that they'd ideally like to run these on (I assume based on an educated guess).

On a day-to-day basis I manage a platform that peaks at roughly 100,000 events per second, fully transactionally and interactive (equivalent to creditcard charge processing during retail sales checkout). This is low end, I've done consulting work on systems approaching 800,000 events per second (nearly 3 billion events per hour).


Presto isn't dealing with anywhere close to 1 billion riders per hour (transfer + tap-out would make 3 billion taps). They'll be dealing with a peak load closer to 2000 events per second system-wide and it doesn't need to be real-time; a 2 minute lag getting results on the website is perfectly acceptable. That's a pretty trivial load with even discount server hardware.

It would be well under 1MB/sec system wide for peak load (500 bytes per record is a huge amount of space; should be closer to 50 bytes per record to identify customer, charge type, $ amount, device, and GPS coordinates).


That kind of thing was a huge challenge in the late 90's when London and Hong Kong were starting their card's implementations; much less of a problem by the time they launched (yay EVDO networks). Now it's very straight forward to handle with off-the-shelf hardware and software for the difficult bits; both for the network and the central backend. They just need to write the glue.

The hardest part for Metrolinx/TTC is going to be inter-departmental politics; connecting and letting the Presto device use the in-bus network to communicate to the Presto backend.
 
Last edited:
On a day-to-day basis I manage a platform that peaks at roughly 100,000 events per second, fully transactionally and interactive (equivalent to creditcard charge processing during retail sales checkout). This is low end, I've done consulting work on systems approaching 800,000 events per second (nearly 3 billion events per hour).


Presto isn't dealing with anywhere close to 1 billion riders per hour (transfer + tap-out would make 3 billion taps). They'll be dealing with a peak load closer to 2000 events per second system-wide and it doesn't need to be real-time; a 2 minute lag getting results on the website is perfectly acceptable. That's a pretty trivial load with even discount server hardware.

It would be well under 1MB/sec system wide for peak load (500 bytes per record is a huge amount of space; should be closer to 50 bytes per record to identify customer, charge type, $ amount, device, and GPS coordinates).


That kind of thing was a huge challenge in the late 90's when London and Hong Kong were starting their card's implementations; much less of a problem by the time they launched (yay EVDO networks). Now it's very straight forward to handle with off-the-shelf hardware and software for the difficult bits; both for the network and the central backend. They just need to write the glue.

The hardest part for Metrolinx/TTC is going to be inter-departmental politics; connecting and letting the Presto device use the in-bus network to communicate to the Presto backend.

I think there is a bit of a tweak required in this analysis. You were looking at a centralized system where all the data is stored in one location. However, won't Presto need a mesh-type system so that the users balance is stored on each bus? (to allow for both underground usage where there is no signal and for the speed required for a tap)?

Not difficult...need the equivalent power of a laptop on each bus with changes in user data being sent around. But I'm not the expert that you are on this...what are your thoughts?
.
 
On a day-to-day basis I manage a platform that peaks at roughly 100,000 events per second, fully transactionally and interactive (equivalent to creditcard charge processing during retail sales checkout). This is low end, I've done consulting work on systems approaching 800,000 events per second (nearly 3 billion events per hour).


Presto isn't dealing with anywhere close to 1 billion riders per hour (transfer + tap-out would make 3 billion taps). They'll be dealing with a peak load closer to 2000 events per second system-wide and it doesn't need to be real-time; a 2 minute lag getting results on the website is perfectly acceptable. That's a pretty trivial load with even discount server hardware.

It would be well under 1MB/sec system wide for peak load (500 bytes per record is a huge amount of space; should be closer to 50 bytes per record to identify customer, charge type, $ amount, device, and GPS coordinates).


That kind of thing was a huge challenge in the late 90's when London and Hong Kong were starting their card's implementations; much less of a problem by the time they launched (yay EVDO networks). Now it's very straight forward to handle with off-the-shelf hardware and software for the difficult bits; both for the network and the central backend. They just need to write the glue.

The hardest part for Metrolinx/TTC is going to be inter-departmental politics; connecting and letting the Presto device use the in-bus network to communicate to the Presto backend.

Then why do you think it isn't being implemented? I don't know much about the infrastructure side of this stuff just how they work. I've got to believe that the difference between the data being transmitted wirelessly and being uploaded every day from the warehouse can't be much of an contentious issue right? (RE: Internal political hurdles)
 
There's a balance to be struck between how often the Presto devices (on-vehicle, kiosks, etc.) phone home to provide and receive data. The system is designed with a fairly infrequent schedule in place for that to allow for devices to spend long periods of time without a connection (perhaps relevant to smaller transit agencies). The downside of that infrequent schedule is latency in terms of the syncing of what the system knows about your balance with what your card knows.

Swapping data about each card nightly is probably not good enough for a lot of people - and that already requires each device on the system to phone home to get and give updated info about any cards it saw during the day. Ottawa has already moved to add more connectivity to its system to allow buses to connect four times per day. From what I've experienced on the TTC, the streetcars seem to do better than that. It seems plausible that the readers are connecting when they reach a connected subway station.

Keep in mind that one of the key requirements is speed and the ability to work in the absence of a persistent connection between Presto device and the Presto system. Introducing a multi-second delay into the tap process would be a deal breaker, as would having a system that fails in the event that the device loses connection for a period of time.

Like any complex system, there are trade-offs to be made and in the case of Presto, it seems that they've sacrificed latency in the syncing of card to system in exchange for speed and reliability. Perhaps there are more tweaks that can be made.
 
Then why do you think it isn't being implemented? I don't know much about the infrastructure side of this stuff just how they work. I've got to believe that the difference between the data being transmitted wirelessly and being uploaded every day from the warehouse can't be much of an contentious issue right? (RE: Internal political hurdles)

It's seems to be a batch process today, so they're too far off from a near real-time implementation. There's a good chance many devices are being cleared by hand (maintenance goes past with a reader that connects to the central system). I know many devices in the subway system must be doing that today (including kiosks) because they're not getting/processing sync.

The credit/debit feature the TTC demanded pretty much makes a link to the buses internal network a requirement. If the website doesn't update in near real-time once credit cards are accepted across all vehicles, then it's definitely not a technical issue or even a TTC political issue; at that point the billing backend will be getting the data in near real-time and simply not sharing with the database driving the website.

For now I'm going to assume Metrolinx didn't think of it when the contract was tendered long-long ago and now Accenture wants a large fee (almost entirely profit) to implement it as a change request. I've worked with Accenture before, they rarely do or even consider anything not in the contract.
 
Last edited:
I just got this response from the Parks folk on PRESTO for the Island ferry:

"Thank you for your suggestion regarding the use of PRESTO cards for Ferry Ticketing. We are currently investigating the feasibility of this payment method for ticketing and pass holders on our ferries.

We expect to have a recommendation regarding the use of PRESTO cards for Ferry Ticketing by the end of March. If the recommendation is favourable, a business case for this potential project would be created and go forward for approval.

If approved, this project would be assessed based on priority, along with the many other projects being considered, and then scheduled accordingly."

Good they are looking at it but clearly not something that will happen for many months, unless people write to the Chair of the Parks Committee urging action. 'councillor_berardinetti@toronto.ca'
 
Last edited:
That would be great for tourists. I believe in Boston your T pass covers the ferry from Charlestown to downtown.
I do not think that this would make much difference for tourists in particular, there is no suggestion that a TTC pass would give free ferry rides. It would simply be a way of using $$ on your PRESTO card to pay a fare on the ferry which would be more convenient for many people.
 
I do not think that this would make much difference for tourists in particular, there is no suggestion that a TTC pass would give free ferry rides. It would simply be a way of using $$ on your PRESTO card to pay a fare on the ferry which would be more convenient for many people.

The London Oyster Card can be used for water transport on the Thames. The card is definitely something a tourist would want to acquire for their visit. I ordered ours online and got it by mail in only a few days. Presto should be aspiring to the same for Toronto, so yes the Ferry should be included -- it's an easy service to add.

- Paul
 
Agreed -- we used Oyster when in London recently; it was awesome and made travel much simpler.
 
re: Oyster - yeah it's pretty awesome, but a bit of a headache when you forget to tap out. It's funny, but traveling by myself 5 years ago, I didn't have this problem, but last May with my gf, we forgot to tap out so many times. Fortunately, the service folks were very nice and helped to refund us quite a bit of money.

I don't know whether to laugh or cry, but Hong Kong's Octopus card launched in 1997. 1997!!! I understand Toronto and Hong Kong are not the same, but despite being a modern city, we are pretty backwards when it comes to transit. :(
 
We are currently investigating the feasibility of this payment method for ticketing and pass holders on our ferries. We expect to have a recommendation regarding the use of PRESTO cards for Ferry Ticketing by the end of March. If the recommendation is favourable, a business case for this potential project would be created and go forward for approval. If approved, this project would be assessed based on priority, along with the many other projects being considered, and then scheduled accordingly."

And if we decide that it's a priority then it will take us a few more months to perform a cost-benefit analysis before we initiate the first round of public consultations (date and time TBD). Upon completion of an environmental assessment in accordance to the terms of reference created by Metrolinx, we must await approval by the ministry of transportation after a 30 day public review period. After that the implementation plan has to go through the political process at city hall which eventually culminates in a vote by city council. If successful and if the Liberals win the next election, then we will proceed with selecting a contractor who will design and build the Presto fare payment system. The Presto machines will not accept debit or credit cards initially but they can be converted to the next generation of Presto technology (currently in development) at some future undetermined date. Fare integration with the TTC might also be a possibility pending the completion of the Metrolinx fare integration study.
 
I lived in lived in London around 8 years ago and I loved the Oyster; when the province was first talking about Presto I was excited and even thought Adam Giambrone's comments saying it would be obsolete by the time it was implemented was ridiculous. I thought no one would want to use credit cards or phones for transit for security reasons and possible gouging from credit services. But I was wrong. After visiting Chicago last summer I was really impressed with their new system Ventra.
https://www.ventrachicago.com/howitworks/
http://chi.streetsblog.org/2014/10/...-small-step-towards-transit-fare-integration/
My wife was hesitant to use a credit card, so I only used mine as an experiment as I couldn't find many experiences by foreigners using the system. It worked perfectly and I saved money by not having extra transit tickets. Meanwhile, when going back to London last summer as well I had a few inconveniences with topping up including having to wait in more lines and problems with machines taking cards and money. All eliminated with contactless in Chicago. Which I've heard London want to implement ASAP, including discontinuing Oyster because apparently it's expensive to maintain.
So here in Ontario, we are just now widely implementing a system that I understand is engineered worse than Oyster. While other cities have already installed systems that the TTC board said were the future at the inception of the project. The province and Metrolinx really screwed up here.
 
I lived in lived in London around 8 years ago and I loved the Oyster; when the province was first talking about Presto I was excited and even thought Adam Giambrone's comments saying it would be obsolete by the time it was implemented was ridiculous. I thought no one would want to use credit cards or phones for transit for security reasons and possible gouging from credit services. But I was wrong. After visiting Chicago last summer I was really impressed with their new system Ventra.
https://www.ventrachicago.com/howitworks/
http://chi.streetsblog.org/2014/10/...-small-step-towards-transit-fare-integration/
My wife was hesitant to use a credit card, so I only used mine as an experiment as I couldn't find many experiences by foreigners using the system. It worked perfectly and I saved money by not having extra transit tickets. Meanwhile, when going back to London last summer as well I had a few inconveniences with topping up including having to wait in more lines and problems with machines taking cards and money. All eliminated with contactless in Chicago. Which I've heard London want to implement ASAP, including discontinuing Oyster because apparently it's expensive to maintain.
So here in Ontario, we are just now widely implementing a system that I understand is engineered worse than Oyster. While other cities have already installed systems that the TTC board said were the future at the inception of the project. The province and Metrolinx really screwed up here.

Isn't all this coming to Presto soon so I don't see what the big deal. Presto will soon work on phones and with credit cards and debit cards I believe.
 
I had a fantastic experience using Ventra in Chicago. Instead of buying a specific card, I just purchased a 3 day pass. I was then able to "store" the pass to my contactless credit card, using that as fare media to tap in and out at station gates. So easy!
 

Back
Top