Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde From: bde@runx.oz.au (Bruce Evans) Subject: Slow floppy reads Message-ID: <1993Mar29.073659.4283@runx.oz.au> Organization: RUNX Un*x Timeshare. Sydney, Australia. References: <JKH.93Mar27011054@whisker.lotus.ie> <C4MIq3.I1A@nmrdc1.nmrdc.nnmc.navy.mil> <1p5hqg$kfc@smurf.sub.org> Date: Mon, 29 Mar 93 07:36:59 GMT Lines: 40 In article <1p5hqg$kfc@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > >Side question: Why is 386bsd so slow when reading floppies? >A Mac under A/UX is about twice as fast _writing_ them... Because a null seek is done between reads. The seek does nothing except delay 16 to 32 msec. This causes the next sector to be missed no matter how fast the system. Large block sizes work OK. But you can only control the block size by using the raw device. The enclosed patch contains a kludge to avoid doing the null seeks. On my system this makes floppy speed only slightly slower than on certain other operating systems :-). It breaks the support for 2 drives, but that's already broken. *** fd.c~ Mon Jun 29 14:25:24 1992 --- fd.c Mon Aug 17 23:53:36 1992 *************** *** 252,256 **** --- 252,267 ---- dp->b_active = 1; fd_drive = unit; + #if 0 + /* + * Arrghhh. This causes a seek (usually null) and a 16-32 msec head settle + * delay (300+ msec head settle delay for writes). I think 0 msec head settle + * is best for reads (newer drives seems to waste a sector time or two by + * forcing more but on older 1.2M drives it was usually possible to keep up + * with the rotation while seeking 1 track during the index hole gap) and only + * 15 msec is required for writes. fd_track needs to be per-drive so hacking + * it out here may cause trouble if several drives are used. + */ fd_track = -1; /* force seek on first xfer */ + #endif /* 0 */ untimeout(fd_turnoff,unit); fdstart(unit); /* start drive if idle */ -- Bruce Evans bde@runx.oz.au