On Wednesday 14 Aug 2013 18:24:44 Vladislav Sterzhanov wrote: > - Added Plotting > - First results brought by them > _________________________ > > | From now on the branch requires JFreeChart to compile, due to appearence > of basic plot facilities in LinkStatisticsToadlet > > | Revelations: I'm almost sure that it's me who breaks some inner logic > severely, but even after dozens of sanity checks results are as follows (10 > Mib transfer): > > [image: Встроенное изображение 8]
HTML is filtered out by the mailing list, please post the image somewhere and link to it inline. > > So, the doubts here are mainly related to the fact that amount of data in > flight (blue) steadily increases as the time goes on, though it was > expected to chaotically increase and decrease as the new data is tranmitted > and acked, but only in bounds of congestion window size (red). > Suspitions: > - dynamically decreasing maxPacketSize? - No, in context of any given > link with stable MTU it's always held constant currenty if I'm not mistaken Yes, at present the max packet size is constant. > - lineary increasing inaccuracy between reported acked and transmitted > size? the most obvious reason for it, but I've thoroughly inspected the > sending callstack and it seems to include all the headers-overhead in > reports.. > > But anyway, if to look at short-run tests (where the impact of the > described lapse is not so huge) it's evident that fred never fills up the > congestion window fully - as I see it, the major reason for it can be in > full-messages vs bytes measuring of cwnd size - any urgent-to-send ack > message will count as a full-size one for PeerContext thus not allowing it > to send others efficiently - investigation and plotting is currently going > that way (after the bugfix of the issue above). Here's one of such (100Kib): Hmm, interesting. We should only count messages with actual content, or maybe have a minimum size threshold, shouldn't we? > > [image: Встроенное изображение 7]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
