Date: Wed, 01 Feb 2006 10:53:57 -0600 (CST) From: Sergey Babkin <babkin@verizon.net> To: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <des@des.no>, babkin@users.sf.net Cc: src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, Scott Long <scottl@pooker.samsco.org> Subject: Re: Re: cvs commit: src/release Makefile Message-ID: <9170456.1138812837533.JavaMail.root@vms171.mailsrvcs.net>
next in thread | raw e-mail | index | archive | help
>From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <des@des.no> >Sergey Babkin <babkin@verizon.net> writes: >> 1. It's slow, since BIOSes tend to use USB 1.x speeds, and even that >> not in a really fast way. So the big images are best to be >> avoided. Though probably it's still faster than floppies. > >It is significantly faster than a floppy, and comparable to a CD when >you take into account the time required to spin up the drive and the >slow seek times. It is also a lot less hassle than either (at least >with modern PCs which have USB connectors in front) Well, my experience was with GRUB and with UnixWare loader, and for those the USB drive boot was much slower than an IDE CD boot. The trick is that only one spin-up and seek happen on the CD, after that everything is read strictly sequentially at full CD drive speed. A 30MB image gets loaded from CD in no time, but loading it from an USB flash drive took almost forever, easily half an hour or so. Maybe the BIOSes became more clever since then. Of course, if you read not strictly sequentially, a lot of seeks happen on the CD and the speed plummets. The Really Bad case is when for each 2KB block you read more data than neccessary (say, 4KB), then discard everything beyond the first 2KB, and then do the next read. This causes a seek on every read. You wold normally think that the data would be cached in the drive anyway, but apparently the CD drive caches work in a strict FIFO order. -SB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9170456.1138812837533.JavaMail.root>