Ready for NAS4Free on ODROID-C1
Daisuke Aoyama
aoyama at peach.ne.jp
Sat Feb 28 00:47:48 UTC 2015
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
More information about the freebsd-arm
mailing list