On Thursday 07 August 2003 23:33, Toad wrote: > 3. We have requirements on a per packet basis. We need messages to be > sent *QUICKLY*, as in a few hundred milliseconds, less than a second > at most, but trailers are not so urgent - but we don't want trailers > to be starved to death either (we have unfortunately seen quite a lot > of this recently). OS-level traffic shaping would probably risk > adding massive latency, and would not know about the packet types - > unless we tell it, which means more JNI. JNI is universally known to > be evil.
In that case, it might be worth revising this comment in freenet.conf: # If nonzero, specifies an independent limit for outgoing data only. # (overrides bandwidthLimit if nonzero). Not entirely accurate. If you need exac t limiting, do it at the OS level. outputBandwidthLimit=25000 A few comments, from someone who has never glanced at a line of freenet code. Output bandwidth is the limiting resource, especially for those of us on asymmetrical connections. With a few GB in the datastore, the input data rate seems to settle down at around 60% of the output data rate - in my case at least - so output bandwidth would still be the limiting resource even with a symmetrical connection. Why is the default datastore size as small as 256MB? The price of disc drives is down to something in the order of 1 Dollar/Pound/Euro per GB. My guesstimate, based on observation of how the download rate drops as the datastore fills up, suggests that 2 GB datastores could allow maybe 20% more throughput on the freenet as a whole. Your download is somebody else's maxed-out uplink. It would be useful to have a stat showing what percentage of uploaded data came from the local datastore and what percentage had to fetched from somewhere else. (Incidentally,most of the stats mean absolutely nothing to me. Is there a crib sheet anywhere to explain what they all mean?) To minimise the effect of freenet on the latency of other network apps, it helps to keep the output rate steady and non-bursty. Bursty clogs up router buffers. Non-bursty also implies that we are making full use of the assigned bandwidth up to the limit, every second. Perhaps freenet should output all data through something like the token bucket filter in the Linux kernel, which shapes the traffic beautifully. Perhaps this filter should be preceded by something which implements a service order table - giving first dibs to stuff which require low latency. As far as uploads are concerned, it makes sense to operate a first-come, first-served policy, but with enough parallel streams to keep the filter input topped up at all times. Once the output rate has reached its limit, further requests should be refused. This will absolutely not slow the network down. Although the node will handle fewer requests at a time, it will complete each one faster. Thus the number of requests served per hour should be much the same as for a maxed-out node, but with lower delays. 'Excess' traffic will instead be diverted to nodes that aren't maxed out, which seems like a smart move to me. -- Richard Lamont _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
