Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Jul 2014 02:03:47 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt

Hi Katja,

Thank you for posting this update.

On Wed, Jul 16, 2014 at 01:34:39PM +0200, Katja Malvoni wrote:
> I implemented 35 instances of bcrypt on ZedBoard where each instance uses 3
> BRAMs and computes single bf round in one clock cycle. 2 BRAMs are used to
> store S-boxes and 1 BRAM to store other data (P-box, expanded key, salt and
> cost). Clock frequency is 71 MHz. Utilization is:
> Number of Slice Registers:                     5,911 out of 106,400    5%
> Number of Slice LUTs:                         27,837 out of  53,200   52%
>  Number of occupied Slices:                  10,584 out of  13,300   79%
> Number of RAMB36E1/FIFO36E1s:           105 out of     140   75%
> 
> Performance is 3346 c/s (40.58 c/s for cost 12). It is lower than expected
> (I expected it will be bit more than 3754 c/s which was achieved with 70
> instances, 2 clock cycles per bf round). If I measure time, communication
> time is 4 ms while computation time is bit more than 6 ms. This gives ~3500
> c/s which is more than 3255 c/s (1/((4+6)/1000/35). I don't know where this
> other time is spent.

Yes, it's puzzling why this runs slower than 70 2-cycle instances do.

> If I fully use BRAMs, 46 instances fit. Performance in that case is 4075
> c/s (with -te=50). For cost 12 it is 53.28 c/s. Clock frequency is 71 Mhz,
> utilization is:
> Number of Slice Registers:                     6,825 out of 106,400    6%
> Number of Slice LUTs:                         35,877 out of  53,200   67%
> Number of occupied Slices:                  11,129 out of  13,300   83%
> Number of RAMB36E1/FIFO36E1s:           138 out of     140   98%
> (everything was tested on the "zed" system)

This looks good, but as you're aware we're now getting 64.66 c/s at cost 12
with your earlier 112 instances design, after I modded my ZedBoard
yesterday adding the extra wire and 3 capacitors. ;-)

> I'll implement 56 instances with 4 BRAMs per core and see if these will
> perform as expected.

Yes, please.

BTW, I just found this abstract:

https://labh-curien.univ-st-etienne.fr/cryptarchi/workshop14/abstracts/zimmermann.pdf

They got 24 bcrypt cores running at 200 MHz on ZedBoard, thus claiming a
4x improvement over your results from last year.  They don't mention how
many cycles per round.

While your new results have already improved by a factor of ~4 for cost 5
and a factor of ~8 for cost 12, I think you'll also need to try to
increase the clock rate.  As I suggested in April, after you get 56
1-cycle instances working, a next step would be to turn that design into
112 2-cycle instances but with higher latency of BRAM lookups.  And
moving initial S-boxes into the FPGA bitstream (into each core) will
probably help reduce not only communication overhead, but also the
longest path which is currently limiting the clock rate.  In fact,
perhaps this is something you'd need to do before going for higher
latency BRAM lookups.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ