On Friday 14 March 2008 19:41, Robert Hailey wrote: > > On Mar 14, 2008, at 12:39 PM, Matthew Toseland wrote: > > > On Friday 14 March 2008 16:29, Robert Hailey wrote: > >> Or maybe it's just that all those blocking within > >> sendThrottledMessage > >> at the same time grab at the available packets, so some may starve? > > > > What it means is we are trying to send more transfers simultaneously > > than will > > fit within the current allowed transmit rate in a reasonable time. > > This > > should be prevented by the current code... > > Are you sure?
Am I sure that the current code prevents us from accepting too many transfers, that there are no other bugs affecting it, and therefore that transfer failures are entirely caused by CPU problems? Certainly not... :| > > All transfers use the same PacketThrottle, and wait for > _packetsInFlight<windowSize. If windowSize==2 and there are 10 > concurrent transfers; it seems to me that there will generally be > about 8 threads trying to grab 2 reservation slots. Possibly. This is bad? > > On the presumption that each transfer has it's own thread, I've > implemented a simple FIFO numerical order for the window (rather than > just a wait()/notify() random order) in r18536. We'll see if it helps > the pSuccess(BlockTransfer) rate, couldn't hurt, no? Ahhh... Yes, if there is a systematic bias, or if we're unlucky, it could be bad... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080315/16202e0d/attachment.pgp>
