> > what about basic pcache not on "first response time" (latency) but on "transfer speed" (ticker started when key is requested and stopped when the last byte of > > the requested key is tranferred, resulting into a bytes/sec value, just like on the splitfile information pane) ? > > in fact, everything what's important is the time needed to have this key on our side, not the latency or other things, so it would make sense to actually respect > > that value ;) > > > > > > The tricky part is that there are 32KB files mixed in with 1 MB files > along the keyspace. Mixing results from different file sizes screw up > the RTE vectors because 1 MB files take significantly longer to download > than 32 KB files. One solution might be making the RTE vectors 3 > dimensional with the file size as the third dimension.
True, but I'm not sure this hurts so much if you divide it out to be bytes/sec. The overhead costs would end up counting less for bigger files than smaller ones, but unless there's some real wackiness in the distribution of sizes of requested keys, I don't think that it would make a significant difference. But it is something to consider. You could, of course, just subtract out the setup time, but then you're treating the smaller keys unfairly, instead of the bigger ones. Could you illuminate me (us) on the mathematics of a proposed 3d impl? --hobbs _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
