From owner-freebsd-arm@FreeBSD.ORG Sat Feb 28 00:47:47 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D53FB1 for ; Sat, 28 Feb 2015 00:47:47 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2EBB5E6 for ; Sat, 28 Feb 2015 00:47:47 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id C5E926811E; Sat, 28 Feb 2015 09:47:38 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 9E2F568118; Sat, 28 Feb 2015 09:47:38 +0900 (JST) Message-ID: <822338A1698D483190FD602C32DD70F4@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Lars Engels" References: <1DA948EA255F4963ACBC0EBE7D046401@ad.peach.ne.jp> <34D37D2811D246BEB11080D19F03FECE@ad.peach.ne.jp> <20150224154713.GS52053@e-new.0x20.net> In-Reply-To: <20150224154713.GS52053@e-new.0x20.net> Subject: Re: Ready for NAS4Free on ODROID-C1 Date: Sat, 28 Feb 2015 09:47:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 00:47:48 -0000 Hi, >> I miss previous mail, USB HDD is formatted by NTFS. >> So, NAS4Free can use NTFS USB drive without any additional tool/step. > >That's probably why the write speeds are so slow? Have you tested >writing to a UFS formatted USB HDD? Yes, around 6MB/s writing is cap of dwc_otg.c. I'm digging carefully. At this time, I find out two problem in dwc_otg.c. >> TAILQ_FOREACH(xfer, &sc->sc_bus.intr_q.head, wait_entry) >> dwc_otg_xfer_do_fifo(sc, xfer); Not depend on CPU power: dwc_otg_host_channel_alloc() returns an error many times by "compute needed TX FIFO size" and busy(dwc_otg_enable_sof_irq). It causes state reset and retry after next SOF(HS mode microframe is 125us). Note: host have max 16 endpoints and FIFO is not so large. Depend on CPU power: dwc_otg_update_host_transfer_schedule_locked() scans all intr_q few times. Under heavy load, the function is called every SOF 125us! (8000 times per second) I think this is expensive cost on RPi. Note: 1MB request make DFLTPHYS(64KB) x 16 SCSI request, and 16 SCSI request make 3(cmd/data/status) x 16 = 48 USB request on intr_q. 1 USB request = 512B x 128 transaction. Above reason, dwc_otg.c can't get over 6MB/s easily and unstable performance. (depend on CPU power and system load) If you want debug on dwc_otg.c, you must check/print within 125us, otherwise you get wrong frame info or missing frame. Also you must think about NRZI encoding and bit stuffing in frame. I feel that it is necessary to split intr_q to pending and running. Regards, -- Daisuke Aoyama