Wahooo – brought a 40£ workstation – whacked in a Hard drive and got it up and working with a GTX 1050 in the machine and also a GTX 750 on the riser/hub board.
PCI switch expander on a Dell 7010
Had to botch together a longer power cable….
power cable made longer
And now sitting next to my blade server.
PCI switch expander on a Dell 7010
power usage
Power usage on the external card is less than 50w so happy with my power cable bodge.
Usage: ./lokid [options|settings] [daemon_command…]
Options:
–help Produce help message
–version Output version information
–os-version OS for which this executable was
compiled
–config-file arg (=/home/mine/.loki/loki.conf, /home/mine/.loki/testnet/loki.conf if ‘testnet’, /home/mine/.loki/stagenet/loki.conf if ‘stagenet’)
Specify configuration file
–detach Run as daemon
–pidfile arg File path to write the daemon’s PID to
(optional, requires –detach)
–non-interactive Run non-interactive
Settings:
–log-file arg (=/home/mine/.loki/loki.log, /home/mine/.loki/testnet/loki.log if ‘testnet’, /home/mine/.loki/stagenet/loki.log if ‘stagenet’)
Specify log file
–log-level arg
–max-log-file-size arg (=104850000) Specify maximum log file size [B]
–max-log-files arg (=50) Specify maximum number of rotated log
files to be saved (no limit by setting
to 0)
–max-concurrency arg (=0) Max number of threads to use for a
parallel job
–zmq-rpc-bind-ip arg (=127.0.0.1) IP for ZMQ RPC server to listen on
–zmq-rpc-bind-port arg (=22024, 38158 if ‘testnet’, 38155 if ‘stagenet’)
Port for ZMQ RPC server to listen on
–data-dir arg (=/home/mine/.loki, /home/mine/.loki/testnet if ‘testnet’, /home/mine/.loki/stagenet if ‘stagenet’)
Specify data directory
–test-drop-download For net tests: in download, discard ALL
blocks instead checking/saving them
(very fast)
–test-drop-download-height arg (=0) Like test-drop-download but discards
only after around certain height
–testnet Run on testnet. The wallet must be
launched with –testnet flag.
–stagenet Run on stagenet. The wallet must be
launched with –stagenet flag.
–regtest Run in a regression testing mode.
–fixed-difficulty arg (=0) Fixed difficulty used for testing.
–enforce-dns-checkpointing checkpoints from DNS server will be
enforced
–prep-blocks-threads arg (=4) Max number of threads to use when
preparing block hashes in groups.
–fast-block-sync arg (=1) Sync up most of the way by using
embedded, known block hashes.
–show-time-stats arg (=0) Show time-stats when processing
blocks/txs and disk synchronization.
–block-sync-size arg (=0) How many blocks to sync at once during
chain synchronization (0 = adaptive).
–check-updates arg (=notify) Check for new versions of loki:
[disabled|notify|download|update]
–fluffy-blocks Relay blocks as fluffy blocks
(obsolete, now default)
–no-fluffy-blocks Relay blocks as normal blocks
–test-dbg-lock-sleep arg (=0) Sleep time in ms, defaults to 0 (off),
used to debug before/after locking
mutex. Values 100 to 1000 are good for
tests.
–offline Do not listen for peers, nor connect to
any
–disable-dns-checkpoints Do not retrieve checkpoints from DNS
–max-txpool-weight arg (=648000000) Set maximum txpool weight in bytes.
–service-node Run as a service node
–block-notify arg Run a program for each new block, ‘%s’
will be replaced by the block hash
–extra-messages-file arg Specify file for extra messages to
include into coinbase transactions
–start-mining arg Specify wallet address to mining for
–mining-threads arg Specify mining threads count
–bg-mining-enable enable/disable background mining
–bg-mining-ignore-battery if true, assumes plugged in when unable
to query system power status
–bg-mining-min-idle-interval arg Specify min lookback interval in
seconds for determining idle state
–bg-mining-idle-threshold arg Specify minimum avg idle percentage
over lookback interval
–bg-mining-miner-target arg Specify maximum percentage cpu use by
miner(s)
–db-type arg (=lmdb) Specify database type, available: lmdb
–db-sync-mode arg (=fast:async:250000000bytes)
Specify sync option, using format
[safe|fast|fastest]:[sync|async]:[[blocks]|
[bytes]].
–db-salvage Try to salvage a blockchain database if
it seems corrupted
–p2p-bind-ip arg (=0.0.0.0) Interface for p2p network protocol
(IPv4)
–p2p-bind-ipv6-address arg (=::) Interface for p2p network protocol
(IPv6)
–p2p-bind-port arg (=22022, 38156 if ‘testnet’, 38153 if ‘stagenet’)
Port for p2p network protocol (IPv4)
–p2p-bind-port-ipv6 arg (=22022, 38156 if ‘testnet’, 38153 if ‘stagenet’)
Port for p2p network protocol (IPv6)
–p2p-use-ipv6 Enable IPv6 for p2p
–p2p-external-port arg (=0) External port for p2p network protocol
(if port forwarding used with NAT)
–allow-local-ip Allow local ip add to peer list, mostly
in debug purposes
–add-peer arg Manually add peer to local peerlist
–add-priority-node arg Specify list of peers to connect to and
attempt to keep the connection open
–add-exclusive-node arg Specify list of peers to connect to
only. If this option is given the
options add-priority-node and seed-node
are ignored
–seed-node arg Connect to a node to retrieve peer
addresses, and disconnect
–hide-my-port Do not announce yourself as peerlist
candidate
–no-igd Disable UPnP port mapping
–out-peers arg (=-1) set max number of out peers
–in-peers arg (=-1) set max number of in peers
–tos-flag arg (=-1) set TOS flag
–limit-rate-up arg (=-1) set limit-rate-up [kB/s]
–limit-rate-down arg (=-1) set limit-rate-down [kB/s]
–limit-rate arg (=-1) set limit-rate [kB/s]
–save-graph Save data for dr monero
–rpc-bind-port arg (=22023, 38157 if ‘testnet’, 38154 if ‘stagenet’)
Port for RPC server
–rpc-restricted-bind-port arg Port for restricted RPC server
–restricted-rpc Restrict RPC to view only commands and
do not return privacy sensitive data in
RPC calls
–bootstrap-daemon-address arg URL of a ‘bootstrap’ remote daemon that
the connected wallets can use while
this daemon is still not fully synced
–bootstrap-daemon-login arg Specify username:password for the
bootstrap daemon login
–rpc-bind-ip arg (=127.0.0.1) Specify IPv4 address to bind RPC server
–rpc-bind-ipv6-address arg (=::1) Specify IPv6 address to bind RPC server
–rpc-use-ipv6 Allow IPv6 for RPC
–rpc-login arg Specify username[:password] required
for RPC server
–confirm-external-bind Confirm rpc-bind-ip value is NOT a
loopback (local) IP
–rpc-access-control-origins arg Specify a comma separated list of
origins to allow cross origin resource
sharing
ran out of RAM…. so…
Swapping swap
So a year ago I brought one of these….
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
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
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
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
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
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.)
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.
sudo apt-get install dirmngr
https://www.gnupg.org/documentation/manuals/dirmngr/
sudo apt-key list
ubuntu’s key servers – you should verify these yourself…..
sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys E0B11894F66AEC98
sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 7638D0442B90D010
sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 8B48AD6246925553
Debians Key servers
apt-key adv –keyserver keyring.debian.org –recv-keys 0x1827364554637281
backports repo
sudo nano /etc/apt/sources.list
deb http://ftp.debian.org/debian stretch-backports main (contrib nonfree)
sudo apt-get update
now install – need to tell it what to install….. and from where
sudo apt-get install -t stretch-backports cacti
So today a coin is worth around 15p and electricity is 14p/kw/hr.
So first of all lets deal with the money side. I’m generating 900H/s using 365j/s (w) of energy. Scaling this upto a day’s hashing, thats 77MH/day and earns around 26ETN/day. It uses 8.76Kw/day which is £1.22/day. So the ETN is worth £3.90 and it costs £1.22 to generate. That’s a profit of £2.68 per day. Winner winner, chicken dinner.
So the hardware I’m using…. 2 old desktops and 2 old laptops.
PC 1 – Intel Core2 Quad Q9300 maybe? (has VM’s running on it which are more important than mining). Has a 750Ti installed. No AES NI support on proc.
PC 2 – Intel Core2 Duo (doesn’t do anything other than host a GPU (with the CPU mining also). Has a 750Ti installed. No AES NI support on proc.
Laptop 1 – Intel quad core? Has AES NI support.
Laptop 2 – Intel quad core? Has AES NI support.
Given that this was all old hardware, i’m not seeing any negative impacts of running this, and the extra heat is useful this time of year I think it’s a thumbs up for now.
So I’ve been working for a few weeks on this idea, and now I kinda have a working prototype. The idea is for a web based copy of something like the Gnome System Sonitor utility found in many Linux distro’s. I need it web based so I can install and monitor web server I don’t have root access (shared hosting platforms) while some rather intense scripts run. Here’s a quick clipping of my very prototype, prototype. Black is actual and red is 3 sample moving average. I admit it looks nothing like the Gnome System Monitor, but it’s a step towards what I want to achieve.
webserver-system-monitor
Things that I need to do next;
My prototype code is available here; https://github.com/crazy-logic/webserver-system-monitor
Design note: want it to be JSON so that a user can mod the front end to monitor more than one system, and it seems sensible.
Here’s some commands (see video for more instructions);
sudo nano /lib/systemd/system/x11vnc.service
[Unit]
Description=x11vnc service
After=display-manager.service network.target syslog.target
[Service]
Type=forking
ExecStart=/usr/bin/x11vnc (your switches)
ExecStop=/usr/bin/killall x11vnc
Restart=on-failure
[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable x11vnc
systemctl start x11vnc
and if you want to see if it’s working ok try
systemctl status x11vnc
So recently I’ve noticed that the site is struggling quite badly to process the data – the database has grown to just shy of 2.5GB and well it’s not optimised is any way at all.
So there’s 95173 teams from my last data collection and of those 2158 have a score of 0 and 164 have no WU. IE these are unused teams. So in total over the last 5 months, that’s generated an extra ~300k of history records that are not needed at all. Then there are the teams who are not active, also having many records that I don’t really need to worry about creating.
To put things into context – this is a pruning exercise. The DB is too big, so the useless data needs to go. Given that in the 5 months my team has risen to the top 3000 teams with less than 2 machines running for that time, I don’t think this will affect the data validity or usefulness of the site long term.
So to keep the ship from sinking I think it’s time we removed the teams with no WU or Score from the history (after creating a backup). When I say no WU or score I actually mean all teams with less than 10 WU and less than 200 score.
So “SELECT * FROM `teamhistory` where score < 200″ yields 974,625 records and “SELECT * FROM `teamhistory` where wu < 10″ yields 4,459,439 records. Given there’s around 14,000,000 records, removing 30% of them should see a massive speed up in future queries.
So after deleting some records, the table seems to have shrunk, but I think I will have to review how I keep team history in the future and the size of the fields in the table as it has grown way too fast from January till now.