That would increase the cpu/storage ratio of the network whe keeping the n*(n-1) intrasection communication overhead small. Seems like it would be easier/simpler to just limit vault sizes to a fixed value so that more sections were needed. Or have I misunderstood the process suggestedĪnother option is to scale Elder sizes as the number of sections grows. This is especially important for promotion reducing the time to promote by about 1/5 or better. Knowing that then the job of moving chunks when adult is promoted/restarted/relocated is shared across many adults saving a lot of real world time. If I understand the storage method then an adult may have other adults (A, B, C) holding some of the chunks and say adults (B,C,D) holding some others and adults (E,F,G) holding others since the 3 closest adults to a chunk will vary depending on the XOR address of the chunk. So while this maybe a simple way of using the elder to buffer a transfer, it may prove impracticable when Node storage sizes get over 500GBīetter for the elders to table the chunks in the Adult being promoted/restarted/relocated and allocate evenly the job of moving the chunks off to the adults holding the chunks. It there is the 2TB adult with 500GB through any one elder then its like 30 hours to receive the data and 30 hours to send it (obviously overlapping) But if more adults are hold various chunks in that adult then the time will be less.īut the worse is the effect on the Elder’s upload link by storing in its cache chunks being moved about. If all chunks were only on 3 other Adults then 111 hours comes down to 25-30 hours. Now if that same Adult also had other Adults that hold its chunks helping out then you’d be looking at lot less. A 2 TB storage node will take a minimum of 110 hours if flat out at 5 MB/s So the Adult being promoted/restarted/relocated will only have to do a portion of its chunks and the other Adults doing their portions.Īnother advantage is the uplink speed of the Adult being promoted/restarted/relocated will not be such a limiting factor on how fast an Adult can be promoted/restarted/relocatedĪt say 40Mbit/Sec upload link, the link nominally can sustain 3 to 5 MBytes/Sec uploads. And additionally the elders rather than storing and forwarding the chunks could instruct the other Adults with the chunks to do the same. Maybe to speed things up rather than going via the elders and only using one Adult you could have a method where the adult sends the chunks directly to the other Adults. This sound elegant but is double handling the chunks. The elders in turn store each chunk to four adults. When an adult restarts or relocates it sends its chunks to the three closest elders to the chunk name and they store as much as possible in their cache.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |