> "Edward J. Huff" <[EMAIL PROTECTED]> > > > Bytes waiting to be sent recent average is 100 MiB.=20 > > That takes about 5 hours to send at 6k/sec. =20 > > This is insane.
Right. >You click a link in fproxy then wait HTL*5 hours > to get the result? I think a timeout appears somewhere, long before > that data being transferred from that queue, so transferring it is > pretty useless 5 hours later. OK, alchemy: > > 6 kbytes/sec= 360 kbytes/minute. > > What if we set a limit on this > "Bytes waiting to be sent", and the limit would be the > bandwidthlimit (bytes/sec) * 60, so the amount of data > we can transfer in one minute. If more data is waiting > we QR. Good, except for the fact that we are trying to teach other nodes about our performance and that we wont do if we just QR them. As it is now.. The reason that your node got to answer that query was that the requestor(s) deemed your node the fastest for that particular data.. Or that there is a bug in NGR causing it to wrongly choose your node over some other ones.... > Also, as it was discussed, maximum key size should be > reduced to something like 64 kbytes. This helps the > trailers finish intact, less likely being damaged, and > a trailer blocks 1 connection for much less time. > > And we shall limit the number of trailers being sent > at the same time as they slow each other down. > edonkey works the following way: > > You set the bandwidth limits, upload say 6 kbytes/sec, > the download is automatically limited to maximum 4 times > of upload, in that case 6*4=24 kbytes/sec, and maximum > 4 nodes can download at the same time, each with > 6/4= 1.5 kbytes/sec in average. If one takes the data > slower the others comsume more bandwidth. This is not very feasible in freenet system since every node might be relaying the data than a query located from another node... If other nodes are slow we might well end up using much less that the allowed bw if we limit to a fixed number of simultaneous trailers.. > All the others sending requests are put on a queue, which > is usually several hundred requests long. But edonkey > is non-anonymous file-sharing, you can leave it running > overnight, while freenet with fproxy "promises" humanly > acceptable response times. Same argument applies here.. We don't distinguish between 'local sends' and 'relayed sends'... > I think it would be nice to queue the requests at the > requestor's node, and not letting them out to the > network until some finishes. So each node would have > only a few parallel requests on the network. I know > it's easy to circumvent. That way someone running frost, > or a 600 mbytes FEC insert, could see that he just > generated X thousand requests, and most of them > waiting at his node to get out to the network. And as > it progresses he could see in node diagnostics that the > latest thing he requested will be delivered in Y hours. But we are talking about bw usage problems here, no?.. How to distinguish between those queries that will result in delivery of 1 meg data from those delivering 100 or so bytes? Also what about any requests the node serves for other nodes, do you intend to queue those too? > That way if you just wanna see a freesite and send only > a few requests, you will get it rather quickly. If you > insert/retrieve big files your response time will be hours. A freesite-view might well cause more requests than a big splitfile... If you queue requests you might well end up getting the splitfile faster than the freesite even... /N _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
