Aloha! Oh by the way, do you test that keys are wrapped/unwrapped correctly? Just to get a confirmation that the modified AES core works. If that is the case I will update/replace the old core with the new one.
JS > On 23 May 2018, at 07:34, Joachim Strömbergson > <joachim.stromberg...@assured.se> wrote: > > Aloha! > > Just to get some clarifications - what was the number of 2048 sigs/s before > the AES updates? > > A little bit shame not to have numbers that could be compared directly to be > able to confirm the improvements. > > Since you are running w parallel AES cores that way of improving things is > already used. The next thing should be double sys_clk to 100 MHz. That should > drop the wait time. > > After that, removing per block wait by implementing streaming/big data is > probably the next improvement. > > Regards, > JoachimS > >> On 23 May 2018, at 07:14, Rob Austein <s...@hactrn.net> wrote: >> >> Summary: 10.3 sig/sec throughput for 2048-bit RSA with eight Modexp >> cores and four AES cores (Joachim's most recent version). >> AES keyunwrap still dominates, but less of it is thumb >> twiddling waiting for the AES core. >> >> There are some relatively minor improvements we might be able to make >> to the FMC I/O code (remove some vestigial stuff which dates back to >> the bridge board and preemptive tasking, move byteswapping to the FPGA >> where we can do it with wires), but none of it's likely to be radical. >> Might be worth doing anyway, since the ARM is underpowered and some of >> the vestigial stuff chews up ARM CPU time to no useful purpose. >> >> The following call graph excerpt was from a test version of the >> firmware with the "vestigial stuff" removed from the FMC code (seems >> to work, at least, it passed all unit tests as well as a signature run >> with eight clients and validation enabled): >> >> index % time self children called name >> ----------------------------------------------- >> 0.00 51.25 3000/3000 hal_rpc_pkey_sign [4] >> [5] 88.2 0.00 51.25 3000 pkey_local_sign [5] >> 0.00 46.04 3000/3000 hal_ks_fetch [7] >> 0.00 5.21 3000/3000 pkey_local_sign_rsa [19] >> 0.00 0.00 6000/6806031 memset [44] >> 0.00 0.00 3000/33907 hal_critical_section_start >> [122] >> 0.00 0.00 3000/33907 hal_critical_section_end [192] >> ----------------------------------------------- >> 0.00 0.28 37122/6000552 hal_aes_keywrap [57] >> 0.33 45.48 5963430/6000552 hal_aes_keyunwrap [8] >> [6] 79.3 0.33 45.76 6000552 do_block [6] >> 0.76 17.30 6000552/6003854 hal_io_wait [12] >> 1.96 12.44 18001656/19712064 hal_io_write [14] >> 1.05 12.25 12001104/21468882 hal_io_read [10] >> ----------------------------------------------- >> 0.00 46.04 3000/3000 pkey_local_sign [5] >> [7] 79.2 0.00 46.04 3000 hal_ks_fetch [7] >> 0.00 45.82 3000/3000 hal_aes_keyunwrap [8] >> 0.00 0.20 3000/3072 hal_ks_lock [65] >> 0.00 0.02 3000/3024 hal_mkm_get_kek [85] >> 0.00 0.00 3000/6036 hal_ks_index_find [126] >> 0.00 0.00 3000/369530 memcpy [83] >> 0.00 0.00 3000/3024 ks_volatile_test_owner [205] >> 0.00 0.00 3000/6036 hal_ks_block_read_cached [198] >> 0.00 0.00 3000/6084 hal_ks_cache_mark_used [195] >> 0.00 0.00 3000/3072 hal_ks_unlock [202] >> ----------------------------------------------- >> 0.00 45.82 3000/3000 hal_ks_fetch [7] >> [8] 78.9 0.00 45.82 3000 hal_aes_keyunwrap [8] >> 0.33 45.48 5963430/6000552 do_block [6] >> 0.00 0.01 3000/3024 load_kek [98] >> 0.00 0.00 3000/9042 hal_core_free [90] >> 0.00 0.00 3000/3042 hal_core_alloc [110] >> 0.00 0.00 3000/6073 memmove [156] >> ----------------------------------------------- >> 3.12 5.02 31734336/98674308 fmc_write_32 [16] >> 6.59 10.59 66939972/98674308 fmc_read_32 [11] >> [9] 43.6 9.71 15.61 98674308 _fmc_nwait_idle [9] >> 15.61 0.00 98674308/98674308 HAL_GPIO_ReadPin [15] >> ----------------------------------------------- >> >> Be warned that this call graph is not strictly comparable to the >> previous ones: the profiling script had been testing not just multiple >> key sizes but also multiple numbers of clients, I dropped the latter >> in favor of always trying just what should be the optimal number of >> clients (now that theory and reality seem to match there -- >> deliberately running too many clients is useful as a torture test, but >> may not give a very accurate picture of where the time is going for >> the case we really care about). >> >> Full profiling report available if folks want to look at it. Be >> warned that we're already past the point where enabling profiling has >> a significant effect on throughput (current penalty is roughly 2x). >> >> I'll send a copy of the proposed change to the FMC code to Paul and >> Pavel for review before pushing it to master. >> _______________________________________________ >> Tech mailing list >> Tech@cryptech.is >> https://lists.cryptech.is/listinfo/tech > > _______________________________________________ > Tech mailing list > Tech@cryptech.is > https://lists.cryptech.is/listinfo/tech _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech