[freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
Am Freitag, 2. September 2011, 12:20:02 schrieb Ian Clarke: > On Wed, Aug 31, 2011 at 8:00 AM, Matthew Toseland amphibian.dyndns.org > > wrote: > > > > WE NEED MORE DATA. > > Well, my gut tells me that our existing scheme is likely too complicated to > fix unless we are extremely fortuitous, however I'm happy to be wrong about > that if others think that they have a good understanding of why we're having > problems and how to fix them. If the load balancer does not have some hidden delicacies, there is a very simple check to see if my understanding is right. Since SSKs are mostly unsuccessfull and are about 50% of the requests, the bandwidth limiter essentially targets 50% of the bandwidth. Setting my bandwidth to about 150% of my actual bandwidth should make it guess my bandwidth more correctly, leaving 25% free for bursting?. Currently the mean bandwidth with NLM and AIMDs for me is about 50 kB/s on a setting of 90kB/s outgoing. My line can handle about 120kB/s outgoing. So I set the bandwidth setting to 180kB/s. If I am right, Freenet should then consume about 90kB/s on average. If it stays at 50-60, that?s likely a limitation of my peers ? no useful data ? test would have to be done on a slower line or with more peers. If it goes down or I get very many timeouts, then I?m likely wrong. It would be nice if some other people could replicate that. Note: I just disabled my testnet node to avoid skewing the data. Best wishes, Arne -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110902/bd7a8c0f/attachment.pgp>
[freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
On Wed, Aug 31, 2011 at 8:00 AM, Matthew Toseland wrote: > WE NEED MORE DATA. > Well, my gut tells me that our existing scheme is likely too complicated to fix unless we are extremely fortuitous, however I'm happy to be wrong about that if others think that they have a good understanding of why we're having problems and how to fix them. So this is fine with me provided that its not just data for data's sake, but *actionable* data. By this I mean that the data we collect should give us clear information about what is and isn't working, and hopefully tell us how to fix it. But a bunch of metrics we have no idea how to interpret won't get us anywhere. Ian. -- Ian Clarke Founder, The Freenet Project Email: ian at freenetproject.org -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110902/b9d66c6e/attachment.html>
Re: [freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
On Wed, Aug 31, 2011 at 8:00 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: WE NEED MORE DATA. Well, my gut tells me that our existing scheme is likely too complicated to fix unless we are extremely fortuitous, however I'm happy to be wrong about that if others think that they have a good understanding of why we're having problems and how to fix them. So this is fine with me provided that its not just data for data's sake, but *actionable* data. By this I mean that the data we collect should give us clear information about what is and isn't working, and hopefully tell us how to fix it. But a bunch of metrics we have no idea how to interpret won't get us anywhere. Ian. -- Ian Clarke Founder, The Freenet Project Email: i...@freenetproject.org ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
Am Freitag, 2. September 2011, 12:20:02 schrieb Ian Clarke: On Wed, Aug 31, 2011 at 8:00 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: WE NEED MORE DATA. Well, my gut tells me that our existing scheme is likely too complicated to fix unless we are extremely fortuitous, however I'm happy to be wrong about that if others think that they have a good understanding of why we're having problems and how to fix them. If the load balancer does not have some hidden delicacies, there is a very simple check to see if my understanding is right. Since SSKs are mostly unsuccessfull and are about 50% of the requests, the bandwidth limiter essentially targets 50% of the bandwidth. Setting my bandwidth to about 150% of my actual bandwidth should make it guess my bandwidth more correctly, leaving 25% free for bursting¹. Currently the mean bandwidth with NLM and AIMDs for me is about 50 kB/s on a setting of 90kB/s outgoing. My line can handle about 120kB/s outgoing. So I set the bandwidth setting to 180kB/s. If I am right, Freenet should then consume about 90kB/s on average. If it stays at 50-60, that’s likely a limitation of my peers → no useful data → test would have to be done on a slower line or with more peers. If it goes down or I get very many timeouts, then I‘m likely wrong. It would be nice if some other people could replicate that. Note: I just disabled my testnet node to avoid skewing the data. Best wishes, Arne signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
On Friday 02 Sep 2011 18:20:02 Ian Clarke wrote: On Wed, Aug 31, 2011 at 8:00 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: WE NEED MORE DATA. Well, my gut tells me that our existing scheme is likely too complicated to fix unless we are extremely fortuitous, however I'm happy to be wrong about that if others think that they have a good understanding of why we're having problems and how to fix them. So this is fine with me provided that its not just data for data's sake, but *actionable* data. By this I mean that the data we collect should give us clear information about what is and isn't working, and hopefully tell us how to fix it. As a matter of principle, empiricism requires experimental data. But it's true that sometimes the metrics which are easiest to gather, and most closely related to our expected usage (i.e. good benchmarks), are hardest to theorise about. But a bunch of metrics we have no idea how to interpret won't get us anywhere. Well, the following appear to be justifiable: - We can detect whether the theory about network topology being messed up by local requests is correct. This is directly actionable: If a large proportion of nodes have this problem, we could try the no path folding above htl 16 rule. Of course, this might slow down local requests, and might even make it harder to bootstrap new nodes ... - Throughput data ... I guess some of our existing tests probably give us this, e.g. the daily timings for insert/retrieve, which lately succeed but take rather a long time. I guess we probably have enough here, although arguably we should have a big-file inter-day test (current tests are small files for multiple days or big files for one day). - Build to build comparisons: If we are going to deploy changes to the network we need to be able to compare one build to another. Otherwise, no matter how good our simulations (and odds are they won't be very good, getting the right level of accuracy is hard), we won't know whether it works in practice. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
On Friday 02 Sep 2011 19:31:14 Arne Babenhauserheide wrote: Am Freitag, 2. September 2011, 12:20:02 schrieb Ian Clarke: On Wed, Aug 31, 2011 at 8:00 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: WE NEED MORE DATA. Well, my gut tells me that our existing scheme is likely too complicated to fix unless we are extremely fortuitous, however I'm happy to be wrong about that if others think that they have a good understanding of why we're having problems and how to fix them. If the load balancer does not have some hidden delicacies, there is a very simple check to see if my understanding is right. Since SSKs are mostly unsuccessfull and are about 50% of the requests, the bandwidth limiter essentially targets 50% of the bandwidth. No, it takes into account that SSKs use very little bandwidth (1-2K versus 32K). signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
On Friday 02 Sep 2011 18:20:02 Ian Clarke wrote: On Wed, Aug 31, 2011 at 8:00 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: WE NEED MORE DATA. Well, my gut tells me that our existing scheme is likely too complicated to fix unless we are extremely fortuitous, however I'm happy to be wrong about that if others think that they have a good understanding of why we're having problems and how to fix them. And my gut tells me that scrapping 6 months work sucks, especially when the current performance appears to be well below what it was when I started to deploy NLM, so we should try to salvage it, especially as anything new will probably take another 6 months to argue about, design, simulate, tweak and generally get right. Funny how gut feelings can be so subjective! ;) So this is fine with me provided that its not just data for data's sake, but *actionable* data. By this I mean that the data we collect should give us clear information about what is and isn't working, and hopefully tell us how to fix it. But a bunch of metrics we have no idea how to interpret won't get us anywhere. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] How to gather more data was Re: Beyond New Load Management: A proposal
Am Freitag, 2. September 2011, 23:34:29 schrieb Matthew Toseland: If the load balancer does not have some hidden delicacies, there is a very simple check to see if my understanding is right. Since SSKs are mostly unsuccessfull and are about 50% of the requests, the bandwidth limiter essentially targets 50% of the bandwidth. No, it takes into account that SSKs use very little bandwidth (1-2K versus 32K). That might explain the data I see: Bandwidth: 75 down, 85 up. I expected 90 kB/s. Theory: My claimed bandwidth doubling seems to have overshot, which gave too many timeouts (that is also supported by the volatility of the bandwidth: oszillating rapidly between 50 and 100 - this is with AIMDs on). Best wishes, Arne signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
