mrjones

Actually, the linked paper discusses 112-115us of total read latency for NVMe SSD, not 14-15 (see Figure 5).

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.

Matt Blaze developed a very cool attack against master-key lock systems: http://www.crypto.com/papers/mk.pdf

It requires access to one (non-master) key as well as a lock which is open-able by that key. It also requires being able to generate a modest number of new keys with a key cutter (however significantly fewer than brute forcing the entire space).

IIRC, the attack boils down to: - Start with the known non-master key - Hold all but one of the teeth constant, and try different values of that one tooth until you get a different working key. This other value must be the master key's value. - Repeat until you have the master value for each tooth.

If TSA locks work the same way as the locks described in this paper, a single lock/key seems sufficient to generate the master key.

It would be interesting to see the client/benchmarking program. It almost sounds like it could be single-threaded ... which would mean the delay is an artifact of the benchmark only having one op outstanding, rather than something inherent in the storage layer.

Interesting fact about liquid nitrogen (that I learned from Dave Arnold's book, which is fantastic): liquid nitrogen is ~700x denser than gaseous nitrogen.

So, if you vaporize a moderate amount of liquid in a contained space (e.g. spilling a dewar in a car or elevator): even if you manage to avoid touching the nitrogen itself, the gas can crowd out the oxygen and you can asphyxiate yourself. Since it's odorless and colorless, you probably wouldn't even notice.

So ... if you do try this at home, be especially careful when transporting nitrogen!!

I was looking at this earlier, there's an API too that seems pretty simple to use:

-----

(1) Developer key: http://datamine.mta.info/user/register

(2) The data is in Protocol Buffer format, so get that: http://code.google.com/p/protobuf/downloads/list

(3) The proto definition of the GTFS-realtime feed: https://developers.google.com/transit/gtfs-realtime/gtfs-rea...

(4) Some static data (which has IDs for each station, etc). http://www.mta.info/developers/data/nyct/subway/google_trans...

(5) You can just curl the URL for all the current data (with your developer key):

  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:

In the "entity" - trip_id: "078600_4..S44R" * 078600 is a train id or something * _4.. means it's a 4 train (this is also available on the route_id field) * S means it's heading south * 44R describes the stops this train will make. I'm not entirely sure how to parse this.

In the stop_time_update: - stop_id: "635S" * you can find the stop codes in stops.txt from (4). This one is "635S,,14 St - Union Sq,,40.734673,-73.989951,,,0,635" - arrival / time: 1356720373 $ date -d @1356720373 Fri Dec 28 13:46:13 EST 2012

So, I guess there was a Downtown 4 train, scheduled to stop at union square at 1:46:13. (I downloaded this about about 1:30 Eastern, so that seems right).