hmm yeah it was quite a nightmare, but @hunterlester was a saint for guiding me through the steps!! Thanks very much for doing that but hopefully it wont be required anymore! Barely got half way through it!
@hunterlester have you done anything with these new APIs yet? I was about to dive in. The mock FFI’s with mock routing etc
Very pleased to see @nbaksalyar in the commits for safe_client_libs
I’m a fan. He wrote a great tutorial that helped me to start learning rust lang and to start thinking about systems development.
Well now I need to know where I can find this tutorial? 
@whiteoutmashups amazing ping you got there!
uh I just had some scary minutes trying to figure out how fast that was. guess I’m in 
Is that something you could upgrade where you are? I upgraded my upload speed from 5Mbps to 10Mbps for a nominal amount perhaps $15.
2017 is looking good, keep it up folks!
Yes - this is the kick in the behind I neeed to go for an upgraded package at home.
I have seen upload speeds >1Mb/s but not reliably.
At work there will be plenty bandwidth but right now that is not an option for the next couple of weeks because balls-up - Thankfully not my balls up but no less annoying cos we are desperate to play with vaults and get on with development.
Yeah mine is about the same on Comcast but Frontier does some great deals on 50/50 even 100/100 is not bad, so I may switch.
Congrats on the finishing the refactor! 
I still feel that the nucleus that is routing needs more resources. It is after all the make or break of this project. Without it working smoothly, most of this work is of little use. Crust stands second in its current state IMO (works well). Apps while extremely important for overall adoption could also stand to wait. Had this been done earlier, I believe we would be in a much better position.
My suggestion would be to work furiously on routing with ALMOST all available resources. Then after stability and efficiency is achieved, break away from routing and split the resources between API finalization and Crust maturity. If and when routing shows issues then resources can be allocated to it proportional to the perceived manpower deemed necessary to achieve stability. Otherwise this pattern of very slow but steady development until about august of every year then a major refactor or delay until the beginning of the following year will likely continue.
Without routing, we only have apps, API’s, and libraries that cannot connect together. So in effect it’s what we already have now in a world without SAFEnet. App development will be blazing fast when enthusiastic devs know with confidence that their work will undoubtedly hit a working network. These people will, because of their enthusiasm, join in on API development as it is nowhere near as hard as routing. At this pace I see at the very least another year of tweaking before the network is efficient enough to label it BETA.
Given how new the recent refactored routing code is, it stands to reason that it will take even longer when you consider the fact that the previous routing library had been “though out” long before its implementation. In that time the better design wasn’t realized until a new mind (Andreas) was introduced. Surely this will happen again and again. This is my reasoning behind my suggestion. Everyone on the Maidsafe team is very competent. Given a short crash course I’m sure they could get to a point where they can better scrutinize the code and provide invaluable ideas regardless to their lack of specialization. They could speed code review, testing, and translate chunks of pseudo code created during brainstorming sessions into something usable in rust.
Money is limited and Routing is draining the community however exuberant some pretend to remain. If routing were completed given all available resources, the rest would naturally come together as it all requires less advanced programming capabilities. Even limping along financially; the knowledge and experienced gained from the routing battle would make it a breeze to finish off the remainder. Routing being like the CPU of any system. Without it nothing comes alive. Crust being the motherboard as it allows all the components to connect to the CPU and as a result to each other. I’m preaching to the choir of course. 
I’m sure this post won’t change things but I thought I’d try. If routing is not secure and 90% reliable by august, I see the same pattern repeating itself. While it might THEN be true that there will be a bunch of cool shiny app available. They will then sit on the backburner awaiting something that should have been there from the start. Without reliable storage and transmission there is little reason to move from current solutions like Freenet. Those future changes will introduce further unfamiliarity at a much later date than would have POTENTIALLY otherwise occurred. Then the cycles repeats itself. Reiteration and refactoring is inevitable but it can be handled more quickly.
I would rather have a rock solid network (routing) with a an incomplete API and buggy apps that can be worked out by the greater community, than a perfect API and great apps that can only provide a freenet equivalent experience due to the routing layer that can ONLY be matured by a handful of specialists. Honestly, if the team found itself with 3 - 4 months left of funds how would that be handled if no investors or further funding were on the horizon? Wouldn’t it be logical to then devote all resources to the most important aspect of the network? If so, why wait or rather why have us wait until then?
Again I fully grasp the importance of all the other work being done, but routing is too experimental to have be developed with nearly the same level of resources as SAFE specific version of things proven to already work. Even Crust is a matter of building transport layers that punch through routers. Not a trivial task but nowhere near as uncharted as the desired performance and state of routing. Without routing any experimental aspect of an app can’t be tested. The only thing that can be done as of yet is to build their shell (GUI, Functions, etc).
I’m not here to be negative. I just feel that priorities could use a little rearrangement. Ultimately it is up to you @dirvine. If you still disagree and continue forward on the same path then all I can say is good luck and godspeed. I’m ever hopeful and cheering for you all. May the universe provide you all with the strength and clarity to make this dream a reality.
Cheers,
Are you achieving this speed because of IPV6? I’m using IPV4/ AnnexM and getting 0.82Mb/ps on Internode.
I am on HFC with the speed pack 100Mbs/2Mbs
Didn’t Internode/iiNet/(Now TPG) have a 2Mb/s upload option for their ADSL2+ years ago?
Wow @stark that was very powerful and very well written, I’ve asked that many times over the years and it would be great to hear why!
I’ve read the response on the dev forum but I’m still not convinced it’s the right route ← pun…
Seriously though. I hope they strongly consider diverting more resources to routing. The current path seems slow and backwards.
They don’t quote specific speeds for their Annex M profiles, but I just changed profiles to the highest speed:
From: ADSL2+ Annex M Low Latency To: ADSL2+ Annex M Very High Speed
Downloads went from 9.42 ->19.8
Uploads went from: 0.82 ->1.19
So, although I’m testing over the 1 Mb/s threshold, there is the prospect of instability with this profile
Currently there are 6 devs in routing 3 in core/crust and 2-3 in front end. Viv and myself spend most of our hangout time in routing, so possibly add another effort score again in routing. It really is getting a lot of attention. Through recruitment we hire for the areas matching skills, not all Engineers are suited to routing though. When interviewee’s show those skills then it’s likely they go there to that library. The last few months have seen routing go from 3 - 6 people so it is being invested in and staffed as quickly as we can at the moment.
As we find more people we do really push forward much quicker, but there is a few month process of getting to know the system as far as routing alone is concerned. There are a few other parts to this question really, but the 10,000 foot view is tha routing gets more resource than all other areas combined at the moment.
Thank you for this very nice report, I’m eager to test vaults from here too ! Looks like things are getting really close to the point of non return
“a spot checked capability” what is it ?
Maybe for the people with no technical background, someone could explain (in a short list, which next big steps are missing, towards a functioning Beta launch, after the home vaults are functioning properly?
Really appreciaciate all the hard and great work!
To clarify, 1 MB/s is 8 Mbit/s. With the current settings, anyone with 6 Mbit/s should be able to join at the first attempt to complete the challenge, however. We’re still testing, though, and we might also do public tests with different settings.
Note that it will still take a while to even get the chance to do the challenge: Every section will only profile one candidate at a time for five minutes, then accept or reject it, and then profile the next candidate. So if a lot of people are trying to join the network, it will take a long time to get accepted as a candidate. Five minutes later, the vault gets accepted as a node or rejected.
This is a per-section limitation, though, not a per-network limitation: So every five minutes, at most as many nodes can join as the network currently has sections.
