Uber admits to self-driving car 'problem' in bike lanes as safety concerns mount
theguardian.com30 pointsby mrjones7 comments
curl http://datamine.mta.info/mta_esi.php?key=<developerkey> -o /tmp/mtafeed
(6) And you can decode it using protobuffers (protoc is from 2 & gtfs-realtime.proto is from 3) cat /tmp/mtafeed | /usr/bin/protoc -I /tmp /tmp/gtfs-realtime.proto --decode=transit_realtime.FeedMessage > /tmp/decodedmtafeed
(7) Now you have a file full of messages like this: entity {
id: "000170"
trip_update {
trip {
trip_id: "078600_4..S44R"
start_date: "20121228"
route_id: "4"
1001 {
1: "04 1306 WDL/UTI"
2: 1
3: 3
}
}
[ some data removed ]
stop_time_update {
arrival {
time: 1356720373
}
departure {
time: 1356720373
}
stop_id: "635S"
1001 {
1: "2"
}
}
[ some data removed ]
Each "entity" looks like a "trip", i.e. a train. It says where the train is and when it will arrive at various stops. I found more documentation here:
https://developers.google.com/transit/gtfs-realtime/referenc...
and here:
http://httqa.mta.info/developers/pdfs/GTFS-Realtime-NYC-Subw...
But still need to parse it all. It seems to be basically like this:
90us of raw device latency, then software overhead of 22-25us (2-3us driver, 6-7us kernel, 14-15us user space).
So, the 6us access latency quoted in the Anandtech article would be significantly faster than NVMe SSD.