PCIe switching….

So a year ago I brought one of these….

PCIe riser from amazon - https://amzn.to/2GFbeZm (affiliate link)

PCIe riser/switch from amazon – https://amzn.to/2GFbeZm (affiliate link)

It’s a PCI expander based around an Asmedia 1184a chip. It’s a PCIe switch 1 in 4out all PCIe-X1 links to put it simply.

Fujitsu Siemens Esprimo E5925

Fujitsu Siemens Esprimo E5925

My original plan was to attach it to an old Fujitsu Siemens Esprimo E5925, that I had running some VM’s (Core Quad, 8GB RAM and an 128GB SSD). But it didn’t like it at all – Gave me a POST error. At this point I should have done some research – but I didn’t, and I tried in another workstation (6 months later).

RM Server Case - Antec SX1040BII Performance Series II SOHO File Server

RM Server Case – Antec SX1040BII

The workstation was a botched together old RM server tower case, with a PSU from who knows where, with a HP xw4600 motherboard, a core duo processor and some RAM (who cares). It’s running quite nicely heating an outbuilding and doing some mining on some old GTX 750/1050 graphics cards. (The electricity would be used to heat the space wither way, so may as well mine some coins.) I tried it in this – same thing, a POST error – so I guess this doesn’t like it either. Oh well.


Dell 7020 with PCI riser

Dell 7020 with PCI riser

Move on another 6 months. The board is still in my workshop taking up space, so I thought i’ld actually read up on these things. Apparently it’s a PCIe version thing. The Fujitsu and the HP both being either older versions of PCIe or BIOS not supporting all of the v2 features (I think that’s when PCIe switches became a thing). Just because a standard says they support things, doesn’t mean it gets implemented. Anywho. I have many servers in the form of blades that should support it but unfortunately I don’t have any PCIe slots to plug into (anyone fancy getting me a Dell M610x blade?). But I did recently buy a new (second hand) computer for a business purpose. I quickly poped the lid off, plugged a few things in and it seems to just work fine.

lstopo showing the PCIe config

lstopo showing the PCIe config

Great – So I think it’s time to finally put this to use. I know it works in a Dell Optiplex 7020 – so I guess it’s time to buy one of those and retire the Fujitsu’s, the hobbled together machine and converge these and all the VM’s running on them into one machine. (Might even same some $$$ on the elec.)

So I have a UniFi VM, a VPN VM, a PBX VM and some VM’s for managing other things (dev mainly). Currently they all run on a only Lenovo X230 I picked up cheap off eBay, which now has 8GB of RAM and a 128GB SSD… that I stole from the Fujitsu when it may have died a miserable death. Running these VM’s currently costs 16w of electricity – which is about £16 a year (cheaper and faster than running in AWS!!!).

A Dell 7020 MT (mini tower (mATX?)) looks like a good option for me right now. 4 core CPU, 8GB of RAM (maybe pushing for 16GB) and then I can whack an SSD and a large spinning rust in also. But – seems a bit of a waste of my old case…

Dell 7020 MT

Dell 7020 MT

Well actually i’m buying a Dell 7010 instead. Fingers crossed it supports the PCIe switch – not a huge problem if it doesn’t though. (Chipset is the Q77, which has the same PCIe variants as the Q87 in the 7020 I tested.)

Running cli wallets against a remote node

So it should seem pretty obvious that running a wallet cli instance against a remote node will be slower than running it against a local one (same machine even). But what’s the difference?

So i’ve set about finding out by creating 2 wallets, one on Loki blockchain and the other on Graft and then timing the rescan_bc command against each. This rescans the whole blockchain for transactions. So I set up a script to spit out the time, do the scan, then spit out the time. For the first run’s I ran these again hashvaults public nodes, and for the second runs again local nodes I created myself running each with 2*5650 Xeons, 16GB RAM, 80GB SATA I drives. Nothing special going on optimisation wise, programs compiled directly from their githubs without modification.

Loki: 33s remote – 12s local
Graft: 74s remote – 10s local

So clearly local wins – but it’s still slow.

The size of the blockchains are:

Loki 11G, Graft, 19G.
BTC 230G, LTC 21G, XMR 64G, ETN 37G.

I should probably create backup or snapshots so I don’t have to resync ever again as it takes an age.