Visual Representation of awful DB Performance

cherryghost

Ran a 13 stop near the start of the line through some data via RTPI (so may not be 100% accurate), this is my result for today:


The yellow line symbolises frequency time. The graph charts a bus arrival time in minutes before it arrives at the stop (1/0 mins, so value of 1/0). If another bus is minutes away from the last one, it will show as miniscule graph, but a bus marked nonetheless). My observations:
From 6:30 to 11:30 16 buses are expected on the timetable. 13 buses arrived, and of those 13, 4 were late.
From 11:30 to 6:45, 29 buses are expected. 28 arrived, 5 were late, and 3 buses arrived minutes from the previous one.

This stop I chose is near the start of the 13 line so buses arriving next to each other is likely a result of a driver running late in the opposite direction meaning they run late for the next scheduled one. Really silly in practice though.

If anyone wants a particular stop/bus/specific route ran through I can, for ya know, ****s and giggles.

devnull

If I'm reading it right at one point there was a 50 minute gap on a service running every 20 minutes?

cherryghost

devnull wrote: »

If I'm reading it right at one point there was a 50 minute gap on a service running every 20 minutes?

Yup and I contacted dB, they knew about it. There's a sudden dip there, they sent out a replacement fleet from the garage apparently

CarlosHarpic

That is shocking. Third world standards.

dowlingm

cherryghost wrote: »

Ran a 13 stop near the start of the line through some data via RTPI (so may not be 100% accurate)

You might find this guy's postings interesting - he has an in with Toronto's transit agency and does similar data analysis things. I find the graphs a bit bewildering myself https://stevemunro.ca/2018/02/06/king-street-update-january-2018-data/

StreetLight

I think it speaks more about the awful infrastructure that DB have to cope with.

boombang

Kudos for doing this. Could you provide a little more description of how to interpret the graph? I don't quite follow it.

Do we know if the information does correspond to the numbers of buses that actually ran?

cherryghost

boombang wrote: »

Kudos for doing this. Could you provide a little more description of how to interpret the graph? I don't quite follow it.

Do we know if the information does correspond to the numbers of buses that actually ran?

The stop is near my house, had a camera running it for the day Saturday. I had 2 sensors running, one via the RTPI API, and another motion detecting a portion of the camera. That way I could tell if the RTPI data was correct or not via counting motion counts and the API detail I graphed out above.

The graph simply describes a bus 'time to stop'. Once that bus reached 0/1, the next bus scheduled via RTPI showed.

If a bus ran late I just calculate the RTPI scheduled time from the first entry to the 0/1 minute counter (it sticks out of the graph flattens/spikes upwards for a few minutes, signalling a delay).

For that graph, it seemed RTPI was correct, the number of motion alerts triggered on the camera matched the API details.

If anyone wants a stop/route run through for a day(or a few, whatever), shoot. My stop is near the Grange castle garage so delays are inexcusable, can't imagine what some stops in town would look like. I'm sure the 145 has some shocking stuff.

Muahahaha

Great work OP. Though I doubt DB would want data like this being made publically available. Especially to the NTA

cherryghost

Here my day so far (and morning rush hour):


This morning showed how rubbish RTPI can be.
From 7:30 - 8:54 12 min frequency buses. 8 buses total expected. 7 arrived (need to verify camera later), the last one ran late. The spikes in the graphs around 8 show RTPI inaccuracy as those buses suddenly jumped to low 'min to arrival' and arrived within the 12 minute frequency.

It's a 15 min frequency until rush hour this evening and all buses from 9am-10:15am (I was the victim of the final one) were slow, running between 7 and 10 minutes late, and including one that disappeared. 3 out of 4 scheduled buses within that timeframe arrived.

suicide_circus

If the OP can do this at home why can't the NTA and all their resources manage it?

LeinsterDub

Too a degree the timetable has become a rod to break their own back. If the buses arrive every 12 minutes then it doesn't really matter if the bus is a bit late. Of course the issue is DB have so many routes with a pathetic frequency that they can't shift to an interval timetable.

bebeman

The 13 take so long to complete a journey that DB had to build a toilet at the terminus, AFAIK this has never been done before.
The longer the journey the greater potential of minor problems which all add up to create large delays.

AlekSmart

bebeman wrote: »

The 13 take so long to complete a journey that DB had to build a toilet at the terminus, AFAIK this has never been done before.
The longer the journey the greater potential of minor problems which all add up to create large delays.

Interestingly,it appears that Dublin is'nt the only Capital City with lengthy Bus routes....however it is worthwhile to note how other cash-strapped Civic Authorities are addressing the issue.

https://www.london.gov.uk/press-releases/mayoral/6m-to-improve-conditions-for-bus-drivers

The toilets will be permanent, fully plumbed in, toilets that drivers have a code to access. TfL will work closely with borough councils and utility companies to install the toilets

Crikey !.....really advanced and supe technical stuff there alright.....no mention of it in our 2040 Plan .....yet :rolleyes:

Muahahaha

cherryghost wrote: »

If anyone wants a stop/route run through for a day(or a few, whatever), shoot. My stop is near the Grange castle garage so delays are inexcusable, can't imagine what some stops in town would look like. I'm sure the 145 has some shocking stuff.

I would be interested in seeing it done for the 145 as I use it and have often been left frustrated. But how would you do it on stops away from your house, put a camera up a pole or something??

cherryghost

I wouldn't install a camera, just add a sensor to my home database and start churning numbers. So would be only RTPI reliant. For the most part I think RTPI has been OK.

I've since moved my camera for another project but I'm still running the RTPI sensor. Some interesting patterns emerging on weekdays

Alkers

You should put up a guide/walkthrough so we could crowdstudy the performance en masse. Know anyone looking to do a thesis?

ED E

cherryghost wrote: »

If anyone wants a particular stop/bus/specific route ran through I can, for ya know, ****s and giggles.

Would love to see 1331. Seems to be a total roulette table.

suicide_circus wrote: »

If the OP can do this at home why can't the NTA and all their resources manage it?

cherryghost

Simona1986 wrote: »

You should put up a guide/walkthrough so we could crowdstudy the performance en masse. Know anyone looking to do a thesis?

Sure, will post a crude one tomorrow.

ED E wrote: »

Would love to see 1331. Seems to be a total roulette table.

Any particular route or anything goes?

Zebra3

Funnily enough I was waiting for the 13 on Monday morning (complete one off) at bus stop on the opposite side to Drumcondra station.

At one stage I counted 6 cars (none taxis) all lined up inside the bus lane.

The infrastructure is crap, the enforcement is crap, though even if they were excellent the service would probably still be crap.

ED E

cherryghost wrote: »

Sure, will post a crude one tomorrow.


Any particular route or anything goes?

16 (that stop is northbound) would be my public enemy number 1.

tom1ie

Can we take a look into the 15b please?

cherryghost

ED E wrote: »

16 (that stop is northbound) would be my public enemy number 1.

Done and churning, will post tonight this afternoons and evenings charts

tom1ie wrote: »

Can we take a look into the 15b please?

Any particular stop to monitor?

Simona1986 wrote: »

You should put up a guide/walkthrough so we could crowdstudy the performance en masse. Know anyone looking to do a thesis?

I apologize for the rough guide, making these guides is not my forte
My setup is done via Home Assistant so what you need is:
- Spare PC/Raspberry Pi
- Min 4gb microSD card, definitely try to get 8/16gb size as database can get large.
- LAN cable if possible
- WinSCP (or equivalent program for your system) to install on another system on your network.

1. Install Home Assistant via PC/Raspberry Pi. Instructions are here. You can setup the Pi Wifi during this setup or just plug a LAN cable into it.
2. Once installed, find your machines local IP. Home assistant should be accesible via 192.168.x.x:8123. If you get connection refused, try to forward 8123 on your router.
3. In 'hass.io' option, click the bag icon on top right, this is a repository of add-ons you wish to install. In 'Add-on Repositories' field, put in https://github.com/bestlibre/hassio-addons and save. You should now have 2 populated add-ons, 'Built-In' and 'BestLibre'. From here you want to install 'ssh', 'Grafana Multiarch' and 'InfluxDB'. Read the ssh instructions carefully
4. Once all that is done, on your local machine/laptop/whatever, open WinSCP and ssh to 192.168.x.x:22. Navigate to /config/hass/, there is a file called configuration.yaml. Here is where you're going to add your dublin bus sensor and database creation.
5. Edit configuration.yaml, preferably with Notepad++ as lay out is simpler to read. Add the following lines:

influxdb:
host: 192.168.x.x
database: home_assistant
sensor:
- platform: dublin_bus_transport
stopid: STOP_ID
route: ROUTE_NO

In this configuration file you can also specify login/pass combo, or if you want to enable HTTPS (seperate configuration needed)
6. Go to 192.168.x.x:8123/config/core and hit 'check config'. If it's valid (at this basic stage it should be), then restart core. This should load all your new values into home assistant.
7. In hass.io configuration on the UI, start influxDB and start Grafana. From a terminal (either ssh'd to the Pi/Server, or from a local machine), run this:

curl -i -XPOST http://192.168.x.x:8086/query --data-urlencode "q=CREATE DATABASE home_assistant"

This will create the database file required for Grafana data plotting.
8. Now, open Grafana UI with http://192.168.x.x:3000. Default user/pass is admin/admin. Click Grafana icon on top left and click Data Sources. Click add data source. Name it whatever you want, with type InfluxDB. The URL is 'direct' http://192.168.x.x:8086'. In InfluxDB details type home_assistant as database. Click save and test, you should get a success notification.
9. Now click Grafana icon, and Dashboard, new. In dashboard, add row, add graph. In 'Graph' settings, under metrics select Data Source as home_assistant. Now you want to select from drop down in FROM row:

WHERE domain = sensor AND entity_id = next_bus
SELECT field(value) last()

And under display tab, select 'Null value connected' from drop down.

Sit back and chill! Your graphs should be generating. You can create timed 'alerts' to monitor/draw a graph based off DB frequency.

If you want to access Grafana/Home Assistant externally from the network, you need a domain. At this point I recommend enabling HTTPS as described earlier.
1. Create a domain with https://www.duckdns.org/, and point it towards your ISP provided IP (you can fetch your IP from https://whatismyipaddress.com/).
2. On your router, forward ports 8123, 3000, 8126 from your server/pi IP address. You should now be able to access your server setup via http://whateveryourdomainis.duckdns.org:8123 (Home Assistant) or http://whateveryourdomainis.duckdns.org:3000 (Grafana)
3. In Grafana, edit your data source again, and change direct url to 'http://whateveryourdomainis.duckdns.org:8086'. Everything should now be accessible externally or internally.

Home Assistant is very versatile and you can combo up some other sensors, like I have used a Camera motion sensor graph and matched it up against Dublin Bus monitoring. A lot of devices are already supported and smart devices already on your network may be instantly picked up by Home Assistant. If you're going to constantly edit configuration.yaml it's probably a good idea to edit via UI instead of logging in and editing the file manually all the time.

cherryghost

ED E wrote: »

16 (that stop is northbound) would be my public enemy number 1.

Yikes. Am I right in saying practically every bus ranlate? One bus in 15m after 6pm frequency actually ran almost 30m after delays. The late buses are a disaster. 2 buses all day arriving on time or early.

Cookie_Monster

nothing should ever appear above the yellow line, right?
As in if the frequency is 10 mins, a bus should never be more than 10 mins away, being 12 means it's late in some form or other.

cherryghost

Cookie_Monster wrote: »

nothing should ever appear above the yellow line, right?
As in if the frequency is 10 mins, a bus should never be more than 10 mins away, being 12 means it's late in some form or other.

Yes, though in some cases the bus estimated time to stop issue accelerated so sometimes you need to double check the graph. No mistake about that 16 bus though. It's bloody awful and not a one off, it's more or less doing the same this morning.

ED E

Thanks for checking it.

cherryghost wrote: »

Yikes. Am I right in saying practically every bus ranlate?

To be fair to DB, the college green area mess right now doesn't help. My frustration with the 16 service is mostly the no shows, probably need a hunters camera to validate that or make friends with somebody in the apartments above the stop.