ChainBot, hardware decentraliser

https://chainbot.com/

thoughts?

1 Like

Targeted at Bitcoin/Namecoin full nodes.
If you want to run (only) MaidSafe, buy Raspberry Pi or something cheaper and with more RAM.

The main obvious remark is that with Rust we have to wait a wee while to regain ARM support. Other than that, seems like a really well balanced hardware spec for a SAFE node. But yes, it is rather expensive - I hadn’t looked at the price yet.

2 Likes

Nice to have more options, and great to see open source hardware. Pricey though, and overkill for SAFE maybe?

Much depends on how quickly I can push decentralised computing. a quad-core 2 GHz processor is pretty sweet though for such a board

1 Like

i really would like to see decentralised computing soon in maidsafe =)

quad-core that fast really seems cool, but won’t the parallela board ( http://www.adapteva.com/parallella/ ) be more efficient in distributed computing …? of course each core is only 700 mhz but programs being made for parallel computation will be faster with 160.7=11.2GHz than with 4x=8Ghz i suppose … okay not really a huge difference and the parallela board only has 1GB Ram (chainbot 2GB) … but the parallela board is roughly half the price, so …

oh i forgot … parallela 160.7+21.2 = 13.6Ghz (If I remember correctly) But ARM like the raspberry

1 Like

GPU architectures complement general purpose CPU architectures. Much will depend on the application, and support for both only makes sense

1 Like

oh of course you are right! i completely forgot about the GPU =)

but that in mind … it could be a little bit tricky to hand the right task to the right node … i’m not a specialist in these things … but seems to me the ranking system would get pretty complex if you really want to get the best performance for every task …?

There’s nothing to distribute with Parallella…
Data distribution is done by MaidSafe s/w.

1 Like

and if you do have 18 cores to offer maidsafe will be able to accept 18 tasks in parallel i would suppose …
if that wouldn’t be the case only one core of each participant in the maidsafe network could be used … i don’t see how that would make sense … everyone would have to start many instances of maidsafe to be able to offer more than one core to the network …

  • MaidSafe is not going to be CPU-intensive
  • Even if it was, task parallelization wouldn’t buy you anything since data movement between different systems would cost more than one could gain by distributing compute workload across different systems
  • In previous discussions most participants agreed that MaidSafe system will be idle most of the time, with occasional “hits” to fetch a non-cached data chunk.

sorry i don’t mean to be rude … but did you read the posts above?
we were talking about distributed computing inside maidsafe network, which would make maidsafe not only a super-huge cloud but also one extremely cool supercomputer that everybody could use at low cost

sorry that probably was a little bit harsh - i know i’m new here but i’m not stupid - only for a data node it wouldn’t think about needing 18 cpus for 100 dollars if a raspberry costs way less …

oh haha sorry i do want to correct myself … for a farmer it might be wise to take the 18 cores … 18 instances of maidsafe >>> ~6 dollars per instance running (5/18 Watt per instance peak power consumption) - the limiting factors would be your network connection and the Ram … but depending on how much idle time the vaults do have … that might not be a huge problem …

1 Like

Yes, I read the post above. I explained what I think about the parallelization idea (why I think it doesn’t make sense).

But for any given node, the app (whatever it is) would have to fetch data from the network.
What I claim is that this part cannot be efficient because for MaidSafe you would want to buy h/w that is just enough to power MaidSafe. If you wanted to (also) run some other workload (like this parallel stuff), then it would either perform very poorly, OR you’d have to overprovision h/w when you buy it, and after that your parallel apps would have to fetch data they work on from the network which would be inefficient and very likely impact your chances to provide good farming service.

After all it seems you also recognize why it’s a lot of trouble. A hosting company can give you a core of 64-bit Intel CPU, 512 MB RAM and 20GB SSD (should be enough for almost any distributed compute task) for $5/month. Compare that with the additional cost of overprovisioned farming rig and consider which of the two can actually perform useful, chargeable compute work.

hmmm - i would say there is pretty much speculation around here …

in my experience with FEM my pc needed for an e.g. 100MB File and a single ~3GHz cpu + enough Ram 10-15min … so let’s solve it in parallel (100x) with 0.7GHz 100/1003/0.710min/100 = 26 seconds … 1 MB of data to download (of course you need to upload the results again and this is just a very rough estimation) … but i would think there is enough time for down/upload and being busy most of the time … and maybe even farming in between …
I know i’m speculating here too but that is how i think about it and why i think that way … (but maybe i remember wrong… haven’t done simulations for a year… :-\ )

… and we haven’t seen it in action … we don’t know when the first decentralized applications will come (or the ability to implement them ; ) … we’ll see what happens and how we can supply useful compute work =)

oh and again i’ve been too fast … yes with 18 cores you’ll have not 1MB you’ll have 18MB maybe down and up in 26 seconds … you will obviously need a fast upload for that - yes

1 Like

Just a note, for decentralised computing, it would precisely be interesting to run the computation on the node that is storing that data; there is an obvious problem that Self-Encryption would make this impossible (that’s what it is designed for), but data intended to be calculated upon should simply be stored differently then private data.

Yes, of course, that’s what MapReduce does. But apart from data access problem (which could conceivably addressed by “trustless job containers”, or working on public data sets) you’d also need to know where to dispatch jobs which would require that location of data chunks be disclosed to the compute job owner which would pose security risks.

those are the relevant questions indeed ! :slight_smile: happy to keep such discussions going, because they are not all answered at this point

On the resources issue, i think it’s a moot point because parallel computing isn’t about naked efficiency, it’s about speeding things up to give new capabilities.

What I mean is: it might be more efficient to have a single processor and immediate access to all the relevant data, but it is going to take too long. So you waste a lot of time and energy dividing the problem up into little chunks that can be done in parallel. That’s less efficient.

Now regarding SAFE, this would not be attractive to farmers unless they get treated for providing the excess CPU resource needed for this (as @janitor points out). So whether it “works” (or rather what works) will depend on whether farming CPU is adequately catered for. Not at present maybe, but why not add this? zkSNARK might be part of this.

It’s not the only enabling factor, there are no doubt other hurdles, but the opportunity is so immense I think it will be worthwhile to put it mildly!

1 Like

It will almost inevitably be part of enabling distributed computing that routing has some understanding of the ‘computational capabilities’ of the nodes on its network. And as such the related question is indeed how should safecoin be allocated for these resources.

and @happybeing: thank you for bringing up this very valid point on high performance computing: it’s a balancing act, and brute force parallelising it is rarely the best solution.

1 Like

hmmm and as @janitor mentioned the 64bit; parallela and raspberry (i think) 32bit … i assume you’d have to decide to use either everywhere 32bit or every program has to be defined to run on a 32 or a 64 bit machine
(or maidsafe itself could identify and distribute it smart … that would be awesome)