[149295] in cryptography@c2.net mail archive
Re: [Cryptography] cheap sources of entropy
daemon@ATHENA.MIT.EDU (James A. Donald)
Sun Feb 2 01:39:33 2014
X-Original-To: cryptography@metzdowd.com
Date: Sun, 02 Feb 2014 16:31:10 +1000
From: "James A. Donald" <Jamesd@echeque.com>
To: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <8D9ADBD2-7E46-4C4C-8C22-7E8EF1B2659C@lrw.com>
Cc: cryptography@metzdowd.com, Theodore Ts'o <tytso@mit.edu>,
Bill Stewart <bill.stewart@pobox.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 2014-02-02 14:47, Jerry Leichter wrote:
> On Feb 1, 2014, at 11:02 PM, James A. Donald wrote:
>> ...Disk read completes at a time that depends on disk turbulence. The real machine now has to do something with the data. Letting it pile up to the next scheduling quantum is going to result in the disk head passing over the next disk sector, resulting in a painfully slow read. So, unless your real machine is crazy inefficient, it is going to immediately wake the consumer of the data at a time that depends on disk turbulence, in the hope that it can read sectors sequentially as the platter spins.
> Your model of how modern disks work is way out of date. To take one very simple example, the notion of missing a block because the sector has already passed under the head hasn't happened in years. Disk firmware buffers entire tracks. If you need sectors n through n+k on a track, the disk firmware will start filling the track buffer as soon as any sector in the range is available, and continue as long as the head is over sectors in that range. Then, depending on where it started, it will do that again starting and sector n. (Actually, for simplicity it may well just buffer the entire track on the theory that there is likely to be another read from the same track "soon", and the data is moving under the head anyway. There's plenty of RAM in a modern disk drive to buffer several tracks.)
>
> Virtualization would be impractical if the hypervisor had to worry about scheduling VM's fast enough to pick off individual disk sectors.
>
> Beyond this ... you're not even going to *see* the real disk. That data will be delivered over fiber channel emulating a LUN, or (probably the majority of the time these days) over an Ethernet, either emulating FC protocols or running iSCSI or even NFS.
The hypervisor is going to switch a process out when it wants data that
is not yet available, rather than switching it on a clock.
If it switches a process in when data is available, rather than
switching on a clock, turbulence is going to show up, even if that disk
is on a network on the other side of the data center.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
