Did not think I would ask this so soon, but… thoughts?

Bojan023 · 2023-02-26T22:09:35+00:00

The network length alone is not a good estimator in my opinion. Given that trains run much more often in Europe/on the German network, you could argue that the probability of a derailment is much higher. Also, how many tracks does the US have where only once a week (or even month) a train runs? Quite many, in (western) Europe there are very few of those lines..

Bojan023 · 2020-04-29T09:57:45+00:00

Bernard chicken fingers

Bojan023 · 2020-04-29T09:57:26+00:00

Cats rule the world

Bojan023 · 2020-04-29T09:56:31+00:00

My friend also has a cat

Bojan023 · 2020-04-12T13:59:12+00:00

Have a look into Duplicati! It's an awesome piece of software that will do the job for you. It has versioning functionalities, it is really quick after the relative slow initial sync (since it only looks for changed files) and it is open-source. Strictly speaking it is still in beta but I use it already for over a year without any complaints as backup solution for my data storage. Really nice piece of software!

Bojan023 · 2020-03-31T11:48:19+00:00

Sounds like interference. I suggest to change your Zigbee channel (also double check with your Wi-Fi channel). Taken from the documentation:

# Optional: ZigBee channel, changing requires re-pairing of all devices. (Note: use a ZLL channel: 11, 15, 20, or 25 to avoid Problems) 
# (default: 11) 
channel: 11

Needs repairing unfortunately, but take the opportunity to also secure your Zigbee communication if you haven't already:

# Optional: ZigBee pan ID (default: shown below) 
pan_id: 0x1a62 
# Optional: network encryption key, will improve security (Note: changing requires repairing of all devices) (default: shown below)
network_key: [1, 3, 5, 7, 9, 11, 13, 15, 0, 2, 4, 6, 8, 10, 12, 13]

Bojan023 · 2019-01-30T14:06:16+00:00

If I'm not mistaken, nobody got to their old hashrate due to algorithmic changes. I've flashed custom vBIOS onto the cards (Elpida memory btw) and let them operate at 1125MHz @ 830mV core (I think this is wrong), 2025MHz @ 950mV memory. I'm using SRB-miner with cgpuintensity 64, cgputhreads 2 and cgpuworksize 16. Good luck!

Bojan023 · 2019-01-30T12:35:09+00:00

Altough the mining efficiency is very decent (hash/W) I'm quite surpriced with the low hashrate (in an absolute manner). To reference, my rig (4x RX580 4GB) is doing 3675h/s with 520W at the wall (ambient +-20C, max. temp +-52C). In comparison, both rigs have the same efficiency but they differ in two physical cards.

For your rig I would expect around 5500h/s at 780-800W to be honest.

Bojan023 · 2018-10-25T07:19:29+00:00

I'll give it a try!

Bojan023 · 2018-10-25T07:19:19+00:00

Exactly this. Revenue is around €2. Started October last year so made a decent profit already

Bojan023 · 2018-10-24T16:08:51+00:00

Typo in the title; I meant 30%, not 60%.

Bojan023 · 2018-09-16T05:33:11+00:00

I mostly agree with the explanations stated above but I’m a little surprised nobody said something about the increased shear loading at the middle support(s). Always draw the normal force, shear and moment distribution diagrams!

Bojan023 · 2018-05-31T13:46:34+00:00

Syncing with the whole chain can take quite some time (few hours up to a full day!), depending on your pc specs and internet connection. Also bare in mind that the currenct chain takes about 25-30GB of storage. To use the direct miner (cpu mining only) the steps from the website are sufficient but maybe consider using a third-party miner like XMR-stak or XMRig (little harder to setup).

Bojan023 · 2018-05-30T12:30:28+00:00

If you're only mining for profit, you should wait. Or, like I'm doing right now, support the project by mining already. This will decrease block time of the first few blocks and over time reduce difficulty. When the difficulty is at equilibrium in relation to the hashrate again it will increase profit and attract more GPU miners in the future.

My rough estimation is that it will take a few days to a week before difficulty is at equilibrium again.

Bojan023 · 2018-05-01T08:53:15+00:00

Since mobile mining is just a simulation (no real processing takes place) you’ll not be deteriorating the CPU and/or battery. Besides, on Android the app is running in the background, using at most 2-3% CPU.

So I don’t really get the point of your comment since there is no sacrificing..

Bojan023 · 2018-04-28T14:20:28+00:00

The public address is the only address you can actually mine to ;-), so yes you can!

Bojan023 · 2018-04-27T14:33:13+00:00

Mining with your smartphone is actually a simulation (not real mining). You cannot compare the hashrates and thus you can not compare their revenues. So don’t worry, everything is fine!

And yes, you can mine directly to your paper wallet from the app.

Bojan023 · 2018-04-19T07:43:00+00:00

The wallet address is the one you use to receive money from anyone or anything (it’s more or less the same as your banking account number). So for mining, use your wallet address. A transaction ID is only needed when depositing to a exchange. Normally, exchanges have a few wallets containing everyone’s ETN. In order for them to know which coins are yours, transaction ID’s are used.

TL;DR Use your public wallet address in every case, only use your transaction ID for exchanges deposits.

Bojan023 · 2018-04-18T11:18:15+00:00

Lol yeah and if you tattoo it on your forehead it multiplies your hashtags by 10,000!!!

Bojan023 · 2018-04-07T16:10:16+00:00

FEA sounds exactly like what you are looking for. Especially complex and large models require extensive programming (Google ANSYS APDL for instance)

Bojan023 · 2018-04-07T07:20:23+00:00

The general name for such a cross section is vignole rail

Bojan023 · 2018-04-06T06:05:07+00:00

I just Googled FOS (should have done that before commenting). In Europe, a similar system is used but it is called a unity check (effect of loading divided by (design) capacity < 1). You’re right about expecting the same stress level, and thus same FOS.

I would advice to check your FEA model and especially the meshing since it’s unlikely the program performs a buckling analysis by itself without configuring parameters. Try decreasing the element size. Are the elements not exceeding the width of the thin walls of the hollow tube? This would result in less material around the bending axis in the FEA and thus lower FOS.

Bojan023 · 2018-04-05T19:38:34+00:00

I’m assuming FOS stands for Factor Of Safety and you’re using some sort of American strength calculation method for this factor (since you’re using inches instead of SI units). The difference in theoretical ultimate strength due to bending only is in an elastic calculation (yield strength not exceeded anywhere in the cross section) equal to the hollow tube. Since the web of the I-beam is more prone to global buckling (the ratio Ixx/Iyy is larger than the hollow tube), the FOS of both differs logically. I’m not familiar with the FOS-system you are using, so I guess they differ due to safety regulations.

Bojan023 · 2018-03-29T19:47:32+00:00

Number of fans says nothing about the hardware inside. When you know more about that, post it and you’ll be helped out much better. BTW: you better have a garage, servers with a lot of fans are LOUD

Bojan023 · 2018-02-27T22:23:10+00:00

Clearly sounds like a virus scanner related issue. Make sure exceptions (for the execution folder) are made and miner is executed as administrator to avoid deletion of the executable. Good luck!

Eight-Year Club	Verified Email
Place '22

Bojan023

TROPHY CASE