Re: umass(4)/uhci(4) REALLY slow

From: Bruce Evans (bde_at_zeta.org.au)
Date: 10/01/03

  • Next message: Gerhard Schmidt: "Harddiskproblems" 
    Date: Wed, 1 Oct 2003 15:00:34 +1000 (EST)
To: Nate Lawson <nate@root.org>

    On Tue, 30 Sep 2003, Nate Lawson wrote:

    > Here are "iostat 5" results for my USB thumb drive on a uhci(4) controller
    > with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly.
    > On FreeBSD, it really lags. This is for a cp of a large file to a
    > msdosfs-mounted flash drive.
    >
    > da0
    > KB/t tps MB/s
    > 1.07 41 0.04
    > 1.00 41 0.04
    > 1.02 41 0.04
    >
    > Is there something we're doing on uhci(4) that makes each transfer only
    > 1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec
    > which is still well under the USB 1.1 max speed.

    This is probably due to something we're not doing in msdosfs. 1K is
    probably your msdosfs file system block size. msdosfs is missing support
    for clustering. None of the lower levels (buffer cache, driver, usb)
    in FreeBSD does clustering (the buffer cache has some support for it,
    but this is mostly turned off because the file system doesn't ask for
    it). The lower levels not in FreeBSD (firmware and hardware) apparently
    don't do clustering either. This results in abysmal performance if
    the msdosfs block size is small. It would be twice as abysmal with
    the minimum block size of 512. Similarly for ffs with small block sizes
    and lots of fragments if write clustering is turned off if the drive
    doesn't do it.

    My early model SCSI ZIP100 drive gave similar performance (command
    overhead of about 25 msec = 40 tps). My not so early model ATA ZIP100
    drive now does 230 tps; its tps is almost independent of the block
    size for block sizes <= 4K, so its performance is reduced by a factor
    of "only" up to 8 by using small block sizes.

    The buffer cache also handles small block sizes poorly. If nbuf is
    2048, then a whole 1MB of data can be in the buffer cache for a file
    system with a block size of 512. Using such a file system will soon (*)
    use most buffers for tinygrams and deplete the buffer cache for other
    file systems. However, disks will normally stay cached in VMIO buffers,
    so this only thrashes the disk caches in memory, so it is now worse than
    copying all the data several times per access.

    (*) Only RSN with 41 tps :-).

    Bruce
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Gerhard Schmidt: "Harddiskproblems"

    Relevant Pages

    • Re: umass(4)/uhci(4) REALLY slow
      ... >> On FreeBSD, it really lags. ... > This is probably due to something we're not doing in msdosfs. ... None of the lower levels (buffer cache, driver, usb) ... > in FreeBSD does clustering (the buffer cache has some support for it, ...
      (freebsd-current)
    • Re: umass(4)/uhci(4) REALLY slow
      ... >> probably your msdosfs file system block size. ... work if you throw everything into the buffer cache using bdwrite ... Similarly for read clustering except it is cluster_readand larger ... The file system must be more involved since reads are ...
      (freebsd-current)
    • Re: Increase disk cache and buffers in 5.3?
      ... Set min as being something less than 1/2 of memory ... Luckly, when FreeBSD does get too aggressive in freeing process memory, ... softupdates code by allowing for larger true buffer cache (which is related ... actually did allow for full decoupling of the dirty buffer ...
      (comp.unix.bsd.freebsd.misc)
    • Re: patch for ext2fs unmount problem at shutdown
      ... >>I suspect both that is one possible reason, ... I'm not especially thrilled about it either since the buffer cache code ... > disk errors I would say that the nbusy check should just be commented ... would be a lot of work given the number of file system types we support. ...
      (freebsd-current)
    • Re: NFS client/buffer cache deadlock
      ... > You can assure that this happens in only two ways: ... Why would 2) be a problem on FreeBSD 5.x? ... FreeBSD 6-CURRENT system practicly locks the filesystem down _and_ ... causes all processes to be swapped out in favor of the buffer cache. ...
      (freebsd-stable)