Hacker Newsnew | past | comments | ask | show | jobs | submit | mrjones's commentslogin

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.


Even with one client thread, though, shouldn't there be a background OS thread maintaining the FS cache and flushing parts of it? I don't think it should block the client just because it decided it was too full.


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!!


>>liquid nitrogen is ~700x denser than gaseous nitrogen.

One of the coolest LN2 tricks we used to do at our physics demo days took advantage of this - making bubbles the 'fun way'. Take a big pot of boiling water and add some dish soap. Wearing your protective gear, dump a few liters of LN2 into the water/soap mixture, and see it explosively create 700x its volume in bubbles!

Here's someone doing something similar (he uses room-temp water, not hot, so the bubbles come out 'frozen') https://www.youtube.com/watch?v=X5ZAoHxhihU

On your comment about displacing air - in my actual research (when we weren't making LN2 bubbles) we used alot of Liquid Helium (for reference, LN2 at 77K is about 1/4th room temperature, while LHe at 4.2K is 1/70th room temperature). We'd often have superconducting magnet running with fields up to 10T, which IIRC required nearly 100A of current in the freakishly-thin superconducting magnet wire which was submerged in the bottom of the LHe bath in the cryostat. It's possible that the magnet could 'quench' where part of it goes 'normal', immediately heating up due to the huge current, causing more of the magnet to go normal, causing more heating, which eventually boils off all the LHe, releasing HUGE quantities of He gas into the room. Even something simple like transferring LHe from the storage dewar to our cryostat, or cooling down a cryostat the first time, releases huge amount of He gas into the room. I was glad we had an oxygen meter in the lab (which I demanded our adviser buy, she didn't want to waste the money on it at first).


Not just transporting it, but in your kitchen too. A professional kitchen that uses it should have an oxygen monitor so they can evacuate if it goes off.

Also, don't screw a lid onto anything containing it or it becomes a live grenade.


This warning is spot on.

"Since it's odorless and colorless, you probably wouldn't even notice." — I remember being surprised reading a haz-card for liquid nitrogen that said you could suffer serious brain damage from lack of oxygen before noticing anything odd. Humans feel we're suffocating when there's too much CO₂, not when there's too little oxygen.


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: