gbde performance question

From: Heiko Schaefer (hschaefer_at_fto.de)
Date: 05/20/03

  • Next message: Mark Santcroos: "Re: recent ACPI regression" 
    Date: Tue, 20 May 2003 11:08:07 +0200 (CEST)
To: current@FreeBSD.org

    Hey all, especially Poul,

    putting my hardware troubles (still working on those, i am planning to buy
    intel-based, non-el-cheapo hardware tomorrow, if i can get any more
    flipped bits unti then. i've exhausted all possible causes that i care to
    check, by now) aside for a minute, i wanted to ask about the performance i
    see.

    to be blunt, i wonder what is taking gbde so long to do its thing :)
    less bluntly, i'm looking for input if i am interpreting the numbers i see
    correctly, and if they make sense to someone who knows the code.

    my hardware (again) is a amd athlon xp+ 1800, i got 512mb of ddr ram.

    what i do is that i copy data between two local gbde encrypted disks (two
    separate, rather modern - udma 66/100 - disks, on two different
    controllers).

    iostat 1 says something like that:

          tty ad0 ad1 ad2 cpu
    tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
      0 153 60.57 139 8.25 0.00 0 0.00 31.37 285 8.73 0 0 89 2 9
      0 152 60.52 136 8.06 0.00 0 0.00 31.39 284 8.72 0 0 91 0 9
      0 153 60.28 144 8.45 0.00 0 0.00 31.15 294 8.95 0 0 92 2 6
      0 153 58.17 143 8.11 0.00 0 0.00 31.35 282 8.62 0 0 88 2 9

    i get roughtly 9 MB/s throughput on each disk (one disk writing, one
    reading) - and most of the time iostat (just like top) says that my cpu is
    more or less saturated.

    in "ps auwx" i see

    USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
    root 509 37.9 0.0 0 12 ?? DL 9:53AM 22:24.24 (g_bde ad2s1e.bde)
    root 513 34.3 0.0 0 12 ?? DL 9:53AM 11:49.08 (g_bde ad0s1e.bde)

    i figure this is the amount of cpu time that is used by raw number
    crunching (and for example does not include disk-io or anything of that
    sort). that would mean that ~1/3 of my cpu can do ~8 MB/s of gbde's
    crypto. if so, i could estimate that gbde can theoretically process
    roughly 25MB/s on this athlon 1800+.

    that looks like an rather low number to me. sites such as

    http://www.tcs.hut.fi/~helger/aes/rijndael.html

    suggest that on a cpu of that speed, memory bandwidth should be the
    limiting factor when using AES/Rijndael.

    am i overlooking something ?!

    thanks for any insight you can provide on the matter, regards,

    Heiko 

    -- 
Free Software. Why put up with inferior code and antisocial corporations?
http://www.gnu.org/philosophy/why-free.html
_______________________________________________
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: Mark Santcroos: "Re: recent ACPI regression"

    Relevant Pages

    • Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)
      ... That's what I just suggested, Kerry: they're limited by disk I/O, not CPU, and hence CPU utilization *will* be low, even if the disks are working their little tails off. ... A server with very low CPU utilization is a *good* candidate for virtualization, since it's got lots of horsepower left over for other tasks that admins might be reluctant to run on the same OS instance: just hook up some more disks to service the added applicationand let 'er rip. ...
      (comp.os.vms)
    • Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)
      ... That's what I just suggested, Kerry: they're limited by disk I/O, not CPU, and hence CPU utilization *will* be low, even if the disks are working their little tails off. ... A server with very low CPU utilization is a *good* candidate for virtualization, since it's got lots of horsepower left over for other tasks that admins might be reluctant to run on the same OS instance: just hook up some more disks to service the added applicationand let 'er rip. ...
      (comp.os.vms)
    • Re: per-cpu blk_plug_list
      ... > We were surprised to find global lock in I/O path still exists on 2.6 ... Disks are slow. ... void blk_run_queues_cpu(int cpu) ...
      (Linux-Kernel)
    • Non-intuitive performance problem (Solaris 9)
      ... This box serves as an Oracle database ... We immediately experienced poor I/O to the attached (array) ... CPU, as reported by `top`. ... internal disks. ...
      (comp.unix.solaris)
    • Re: gbde performance question
      ... > to compare your numbers with. ... that's why i wonder if gbde does _that_ much more than just nubercrunching ... roughly 10x against what i think raw aes on bulk data should take. ... and if gbde has any sane reason to take as much cpu ...
      (freebsd-current)