Brian, > Please eyeball a couple of the download-status pages and see if you can > learn anything about the number of servers being selected. I imagine > that on your local grid, all the servers are identical, but since the > performance variations we've seen on the testgrid/v-grid have been > closely correlated to server-selection, it'd be good to find a way to > rule that out here.
My environment destroys the grid as soon as the testing is done. I could artificially keep it alive, but then I have very little experience interpreting the download information pages. > What I'd love to have is a test framework in which we could simulate > multiple servers (of varying CPU speeds) connected by virtual pipes with > controllable latency and bandwidth limits. Then we could run an > experiment like measuring download speed as the bandwidth limits are > raised, where I'd expect to see it taper off as we approach the > CPU-speed limit. (I remember writing this desire up on a whiteboard at > allmydata about four years ago and labelling it "and also, I want a > pony"). A lot of the performance measurements we've been making are at > unlabled points along some axes of CPU-speed, network-speed, and share > distribution.. being able to label those points and compare apples to > apples would probably help us understand what's going on a lot better. Your pony interests me. A lot. For the past couple years, actually, as I've been disappointed by some software at work I've been thinking occasionally about an auto-prefetching data stream that would prefetch at the measured rate of consumption in order to eliminate the read latency without prefetching too much (which hurts CPU caching). A bandwidth goal is a fundamental part of this; fixing it to a given value is a subset of what I'd wanted to do anyway. I haven't gone beyond sketching some notes for this idea. (I'm on the wrong team at work to implement this there.) But having a real-world application for it could give me an incentive to go create this on my own. It's not a large project but I don't have a lot of hobby time anymore. Hmmm... -- Kyle Markley _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
