tahoe-lafs/trac-2024-07-25

put more DYHBs into flight at once when K is larger #1180

New issue

Open

opened 2010-08-15 06:14:25 +00:00 by zooko · 3 comments

zooko commented

2010-08-15 06:14:25 +00:00

Owner

As mentioned in comment:108660, the new downloader code in v1.8.0 will put at most 10 DYHBs into flight at once. This is perfect when K=3, but as K gets larger it is increasingly likely that the hardcoded limit of 10 will induce delay at the beginning of a download or cause the downloader to overlook a better-performing server. As Brian suggested on #448, a better limit would be something like K * 3.

(Note: everyone that I know of uses the default settings of K=3, M=10. The theoretical maximum value of K is 256. Since nobody has tried it, we don't know if there are other problems with using K greater than about 100.)

As mentioned in [comment:108660](/tahoe-lafs/trac-2024-07-25/issues/448#issuecomment-108660), the new downloader code in v1.8.0 will put at most 10 DYHBs into flight at once. This is perfect when `K=3`, but as `K` gets larger it is increasingly likely that the hardcoded limit of `10` will induce delay at the beginning of a download or cause the downloader to overlook a better-performing server. As Brian suggested on #448, a better limit would be something like `K * 3`. (Note: everyone that I know of uses the default settings of `K=3, M=10`. The theoretical maximum value of `K` is 256. Since nobody has tried it, we don't know if there are other problems with using `K` greater than about `100`.)

tahoe-lafs added the

labels 2010-08-15 06:14:25 +00:00

tahoe-lafs added this to the soon milestone 2010-08-15 06:14:25 +00:00

zooko commented

2010-10-22 13:28:43 +00:00

Author

Owner

Hm, did I mark this as "regression" because this makes v1.8.0 perform noticeably worse than v1.7.1 for cases when K >> 3? Because that case is increasingly interesting to me nowadays since (as mentioned in this mail to tahoe-dev), I think people should probably start setting K at least as large as the number of servers on their grid. Perhaps we should even make the default value of K be 30 in future releases of Tahoe-LAFS instead of 3, and make the default value of M be 100. Oh, but what would that mean for the default value of H?

In any case, nobody to my knowledge has measured v1.8.0 to see if it actually performs worse than v1.7.1 does due to this issue about v1.8.0 keeping at most 10 DYHB's in flight at once.

It would be great if someone would benchmark larger K's.

Hm, did I mark this as "regression" because this makes v1.8.0 perform noticeably worse than v1.7.1 for cases when `K >> 3`? Because that case is increasingly interesting to me nowadays since (as mentioned in [this mail to tahoe-dev](http://tahoe-lafs.org/pipermail/tahoe-dev/2010-September/005247.html)), I think people should probably start setting `K` at least as large as the number of servers on their grid. Perhaps we should even make the default value of `K` be 30 in future releases of Tahoe-LAFS instead of 3, and make the default value of `M` be 100. Oh, but what would that mean for the default value of `H`? In any case, nobody to my knowledge has measured v1.8.0 to see if it actually performs worse than v1.7.1 does due to this issue about v1.8.0 keeping at most 10 DYHB's in flight at once. It would be great if someone would benchmark larger `K`'s.

swillden commented

2010-10-22 14:57:32 +00:00

Author

Owner

Replying to zooko:

Because that case is increasingly interesting to me nowadays since (as mentioned in this mail to tahoe-dev), I think people should probably start setting K at least as large as the number of servers on their grid.

Set K to the number of servers in the grid? The e-mail you reference (and the analysis that I've done) recommends setting M to the number of servers in the grid and scaling K to achieve the desired level of redundancy.

Intuition says that setting K=N and M=K*3.33 should achieve roughly the same level of reliability for an expansion factor of 3.33 as setting M=N and K=M/3.33, but I haven't done the math to verify it.

In any case, I think larger values of K and M are definitely a good idea, and getting good performance with larger values is important if we want to encourage people to use them. I'd certainly use them if I had access to a large-enough grid to make it worthwhile.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1180#issuecomment-121425): > Because that case is increasingly interesting to me nowadays since (as mentioned in [this mail to tahoe-dev](http://tahoe-lafs.org/pipermail/tahoe-dev/2010-September/005247.html)), I think people should probably start setting `K` at least as large as the number of servers on their grid. Set `K` to the number of servers in the grid? The e-mail you reference (and the analysis that I've done) recommends setting `M` to the number of servers in the grid and scaling `K` to achieve the desired level of redundancy. Intuition says that setting `K=N` and `M=K*3.33` should achieve roughly the same level of reliability for an expansion factor of 3.33 as setting `M=N` and `K=M/3.33`, but I haven't done the math to verify it. In any case, I think larger values of `K` and `M` are definitely a good idea, and getting good performance with larger values is important if we want to encourage people to use them. I'd certainly use them if I had access to a large-enough grid to make it worthwhile.

zooko commented

2010-11-20 23:29:42 +00:00

Author

Owner

In comment:2:ticket1264 François posted that with 71 servers, raising the DYHB limit from 10 to 60 made only a 1-second difference in the total download speed. This may indicate that this ticket is not very important for downloading larger files but is important for downloading smaller files.