linux-kernel - Re: floppy question of the hour

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 May 2008 17:49:18 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Gene Heskett <gene.heskett@...il.com>
CC:	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>
Subject: Re: floppy question of the hour

Gene Heskett wrote:
> This is a 250 kilobaud data rate format, the maximum the WD-1773 FDC chip in the 
> target machine can handle, with 18, 256 byte sectors per track, two sides=73728 
> bits to write a track, /250000 (baud rate)=0.294912 seconds to write one full 
> tracks worth of data. 80 tracks=23.59296 seconds to write the whole disk if it 
> were streaming, but it takes 3 minutes and change?  And nearly 2 to read it 
> back as above?  Odd.  With the interleave of 3, I could see 75 seconds maybe 
> for efficient methods.  I also understand this is a one size fits all scene 
> too, and that there must be compromises.
> 
> I format these DD discs in the target machine with an interleave factor of 3 cuz 
> that machines cpu is running at as low as .89MHZ and can't handle the read data 
> any faster than that.
> 
> Is this non-1 interleave responsible for the slowness of the writes or reads on 
> this box?  I can control the interleave on the target box, so I suppose I could 
> test that effect easily enough.

Yes, the interleave slows you down, since after accessing sector 1, the 
head must wait to pass over 3 other sectors before finally reaching 
sector 2, therefore, you can only read 1/4 of the sectors on the track 
each revolution of the disk.  That leaves 4 revolutions at 300 rpm 
giving 0.8s to read a track, or 64 seconds to read all 80 tracks, plus 
seek time.  That still does not explain 3 minutes though... not sure 
what else could be slowing you down.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/