From owner-freebsd-arm@freebsd.org Sun Jul 1 20:11:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B57AFDA5EC for ; Sun, 1 Jul 2018 20:11:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4B337C1E0 for ; Sun, 1 Jul 2018 20:11:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w61KBZin029691; Sun, 1 Jul 2018 13:11:35 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w61KBZka029690; Sun, 1 Jul 2018 13:11:35 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807012011.w61KBZka029690@pdx.rh.CN85.dnsmgr.net> Subject: Re: RPI3 swap experiments In-Reply-To: <20180701191741.GA52656@www.zefox.net> To: bob prohaska Date: Sun, 1 Jul 2018 13:11:35 -0700 (PDT) CC: Mark Millard , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 20:11:45 -0000 > On Sat, Jun 30, 2018 at 11:42:00PM -0700, Mark Millard wrote: > > > > > > So I tend to use a powered hub for USB storage. > > > > It occurs to me that a powered hub provides more than power: It provides delay. > Likely not much, but a flash device has none of the rotational or seek delay > of a mechanical drive. At least occasionally, a flash device might respond > quicker than any plausible mechanical one. If the host isn't ready, it'd miss > the response. Most "disk" driver software was written in the days of mechanical > disks, is it possible assumptions about minimum response delay were made? > There's doubtless a "re-training" scheme to get host and device back in sync, > but if the timings remain wrong that would prolong the confusion. IIRC the "delay" through a usb hub, as long as your not doing transactional translation (TT, ie 480 mb/s down to a 12mb/s device) is on the order of microseconds, this is the same weither it is a powered or un powered hub. I doubt that any flash drive can respond faster than a spinning rust drive with a cache can, as the cache is DRAM with tens of nano seconds access time. Flash drives DO have an access delay, the FTL still has to do the mapping funcions, and a page of flash has to be pulled into a read buffer. I actually believe that even the fastest USB flash drives are still slower than any modern spinning rust at this operation. Modern cheap 500G laptop drives are doing well past 140MB/s in a sustained sequestion read operation. I have not seen USB flash sticks that do this. You need to move to SSD type drives to get faster, and it would be rather pointless to run SSD on USB unless your using USB3. -- Rod Grimes rgrimes@freebsd.org