anyone tried running with VIA Padlock extensions?

[ansible adams]

I understand that the VIA C7 line of x86 processors has "Padlock" cryptographic acceleration CPU instructions built in. OpenSSL can support these extensions too.

I've only been able to find AES benchmarks on Padlock (with some very impressive speedup), but it supports SHA-256 acceleration too. According to VIA's website it can do up to 5 Gbit/sec of SHA-256 hashes, which I believe is about 19500 khash/sec! If you can get even close to that performance it should leave the beefiest multicore 64 bit systems in the dust.

Does anyone here have a VIA processor with these extensions? Does bitcoin automatically pick them up, or do you need to rebuild from source? It seems like this inexpensive processor line should be a real coinspinner!

Sun's Niagara hardware has similar cryptographic acceleration, and I believe there are separate cards you can buy for this purpose too, but I think the VIA line packs a mighty big wallop for a mighty small price. Unfortunately I don't have such a processor myself, but I'd be really interested if someone else manages to get the combination working.

[laszlo]

That does sound interesting, I might go pick one of those up to experiment.

[laszlo]

We would need to write code to use this hardware, there is no automatic acceleration, btw.

[Ground Loop]

There's a "drivers/crypto/padlock-sha.c" driver implementation in the standard kernel.

How does the openssl speed benchmark compare to bitcoin's khash/s?

Code:

openssl speed -evp sha256

On my Core2Duo E8500, it's:

Code:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           25568.41k    60726.70k   108968.11k   137848.27k   146604.46k

[sgtstein]

Yep, the openssl acceleration is already built into the kernel.

Check out these for AES benhcmarks on XP. Not sure what for SHA-256 on *nix.
http://www.logix.cz/michal/devel/padlock/bench.xp

[sgtstein]

While this appears to be a good idea for a low power server that can "keep up with the big boys", I think that it isn't the best method for it. It looks like OpenSSL DOES have a CUDA version floating around out there for linux boxes. That would be a HUGE increase over anything we could do in this hardware. I'm still going to be pursuing both paths for now. It would be awesome having both of my "big" boxes crunching for this.

[ansible adams]

There's a "drivers/crypto/padlock-sha.c" driver implementation in the standard kernel.

How does the openssl speed benchmark compare to bitcoin's khash/s?

Code:

openssl speed -evp sha256

On my Core2Duo E8500, it's:

Code:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           25568.41k    60726.70k   108968.11k   137848.27k   146604.46k

That's a good question. I'm not on my home machine right now so I can't compare khash/s to the OpenSSL benchmark. On the largest block size in that benchmark, it looks like your machine does about 1.2 Gbit/sec (146604.46 * 1000 * . So if the VIA chip can reach its full potential it would be about 4 times as fast.

I assumed that since bitcoin appears to be built on OpenSSL you would just need to rebuild it from source on your VIA machine with Padlock-aware OpenSSL, but maybe there is more to it.

I think the most common VIA use right now is in netbooks. I would be pretty amused if a little $350 netbook with this processor could keep up with an i5 or Phenom II. I bet a good CUDA hasher can thrash it, but I wouldn't be surprised if the VIA chip wins on hashes per dollar of hardware and per dollar of electricity.

[jib]

I assumed that since bitcoin appears to be built on OpenSSL you would just need to rebuild it from source on your VIA machine with Padlock-aware OpenSSL, but maybe there is more to it.

Bitcoin uses its own SHA256 code, not OpenSSL's. You'd need to modify Bitcoin to be Padlock-aware or to use OpenSSL's code.

[jib]

5 Gbit/sec of SHA-256 hashes, which I believe is about 19500 khash/sec

Your calculation seems to be based on 256 bits per hash. I think the 5Gbit/sec refers to the amount of data being hashed, not the size of the hash itself. So instead you should be estimating 80 bytes (640 bits) per hash, which is the size of the block header being hashed. And bitcoin actually uses SHA-256 twice for each hash (using the first result as input to a second SHA-256), so add another 256 bits. This means each hash requires processing 896 bits of input, so at 5Gbit/sec you get 5580 khash/sec.

Although, if we consider how SHA-256 works in more detail, it separates the input data into 512-bit blocks (padded to a whole number of blocks). So for the first hash we process two blocks (1024 bits) and for the second hash we process one block (512 bits), making 1536 bits total. At 5Gbit/sec that gives 3255 khash/sec.

This is ignoring the overhead of initialising the hardware for each SHA-256 we do, which might be significant. The 5Gbit/sec figure is probably for throughput when hashing a long stream of data, not for millions of small hashes. So the actual performance might be much lower.

I guess it's worth experimenting with, but it's almost certainly not going to be as awesome as originally claimed.

[Ground Loop]

Excellent insight into how the SHA256 stages are used.
The machine I quoted above seems to run about 1630 khash/sec, so there's one data point.

If openssh is hashing 512-bit chunks at a throughput rate of 60726.70k bytes per second, that's 485 Mbps.
If bitcoin on the same machine is doing 1,630,000 btc-hashes per second, and each btc-hash is effectively 1536 bits (three 512-bit hash inputs) through the same pipeline, that's a whopping 2503 Mbps.

Is bitcoin really running SHA256 at 5x the speed of openssh?

Is each "khash/sec" a whole attempt, or each single cycle through SHA256?

[ansible adams]

Thanks for the hashing analysis from a much more experienced perspective! I am still interested in how this little processor can do... even if I was off by a factor of about 10, it might still be competitive with much more expensive and energy intensive desktop processors. I can get about 2100 khash/sec using all 4 cores of my 64 bit machine when the system is otherwise idle, and that certainly makes the fans blow a lot of hot air. I though it might be possible for VIA to overcome because custom circuits (FPGA or ASIC) for some cryptographic functions have in the past proved orders of magnitude faster than general desktop processors or even GPUs.

[jib]

Thanks for the hashing analysis from a much more experienced perspective!

I'm not "experienced", I'm just another random person who reads stuff on the internet. Please don't trust anything I say :p

[theymos]

Is each "khash/sec" a whole attempt, or each single cycle through SHA256?

It's a whole attempt.

[sgtstein]

I had been needing a fun system for a home server anyway... So, I just picked up a mobo/cpu combo of Newegg tonight. VIA C7-D@1.6GHz. It will be running with 2GB of RAM on a 16GB compact Flash disk(for BitCoin) and a 120GB 2.5" laptop SATA drive for the OS etc. Hopefully I will have this up by the beginning of next week once it gets here and I figure out how to get Linux onto this one. I'll create a thread or continue this one as I build and test for it.

[laszlo]

A 'whole attempt' is actually 3 blocks.  2 blocks of data are hashed to produce a 256 bit result, then that result is padded to make another block and hashed again.  Each block is given the usual 64 pass treatment of SHA-256.  The interesting part that generates the coins uses a simplified implementation in c++ rather than OpenSSL.

[Ground Loop]

If I was building dedicated bitminer hardware, I'd start with something like this:
http://www.xilinx.com/products/ipcenter/Fast_SHA-1-SHA-256_MD5_Hashing_cores.htm

[lfm]

Ok, I got a version 0.3.10 bitcoin running on a C7. It does about 1430 khash/s currently on a 1.8 ghz VIA C7.

It's not clear yet if  we can get it optimized to do the 2 block hash (1 block pre-hashed) instead of the 3 block hash per nonce-attempt. We'll be investigating that.

[lfm]

There's a "drivers/crypto/padlock-sha.c" driver implementation in the standard kernel.

How does the openssl speed benchmark compare to bitcoin's khash/s?

Code:

openssl speed -evp sha256

On my Core2Duo E8500, it's:

Code:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           25568.41k    60726.70k   108968.11k   137848.27k   146604.46k

I was unaware of OpenSSL support. I don't think I have it being used yet. At least I don't see any speed changes no matter what I have tried.

On my VIA C7 1.8 ghz I currently get

Code:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256            3379.47k     8061.39k    14412.11k    18119.94k    19447.70k

so its still kinda slow. I can't tell if this is with VIA support enabled or not.

Trying to figure out OpenSSL support for VIA padlock functions seems like a quagmire from what I see so far surfing the net.

[sgtstein]

Download 0.3.10 HERE!!

---

Trying to figure out OpenSSL support for VIA padlock functions seems like a quagmire from what I see so far surfing the net.

Yea, completely agree there. I've looked into it as well, lots might need to be changed.

[jgarzik]

Download 0.3.10 HERE!!

Thanks for the inspiration.  After reading this, I added VIA padlock support to my CPU miner.