On Tue, Oct 31, 2006 at 09:59:50PM +0000, Michael Rogers wrote: > toad wrote: > >Because messages in the transfer queue generally are sent after all > >other messages, and are therefore higher latency? > > That might be true for the real code, but in the simulation code we keep > two queues, one for transfers and one for searches. Each time we build a > packet (Peer.pack()), we alternate between putting transfers in first > and putting searches in first. This interleaves transfers and searches > without giving priority to either - I know it's important for searches > to be low-latency, but if we gave them strict priority over transfers it > would be possible for a transfer to keep getting pre-empted by searches > until it timed out.
And there are proposals to deal with this, such as putting in searches first unless searches make up more than X% of the total. Or putting one transfer block in, then filling the rest up with searches, unless there are no transfer blocks or the searches are urgent, in which case we send a packet full of searches. In fact, if searches are more than a small fraction of total traffic, there is something seriously wrong. > > This change just moves DataInserts and ChkDataFounds from the search > queue to the transfer queue, so they never get overtaken by their own > data blocks. In both cases these messages are supposed to be before the data blocks. And having to wait behind many very large messages will increase latency significantly. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20061101/fd5986b4/attachment.pgp>
