Date: Sat, 8 Sep 2007 23:41:57 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-net@freebsd.org, Kirc Gover <kirc.gover@yahoo.com.au>, Andre Oppermann <andre@freebsd.org> Subject: Re: OS choice for an edge router Message-ID: <20070908220703.Y32678@besplex.bde.org> In-Reply-To: <20070907235622.C410D5B58@mail.bitblocks.com> References: <20070907235622.C410D5B58@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Sep 2007, Bakul Shah wrote: >> This is not the case. Flood ping doesn't reach the limit in any >> way. Have a look at the ping man page and flood ping description. > > Ah yes, I was forgetting about the strict synchrony. Flood ping neither floods nor is synchronous. As documented, it outputs packets as fast as they come back or 100 times per second, whichever is more. The magic 100 was a good approximation to infinity at 1Mbps, but it scales poorly. I see the following behaviour on a 1Gbps network that has a ping latency of ~100 usec: - initially the throughput is ~10 kpps, due to strict synchrony (sp?). The 100 Hz timeout is almost irrelevant because 100 is much less than 10k. - the throughput gradually (after about 1 minute) ramps up to ~120 kpps (equals only about 1/5 of ttcp max transmit-only throughput which saturates the transmitter). My explanation for this is that one side gets behind due to random delays and/or accidental sync with the 100 Hz timeout. Then the synchrony is not per-packet, but per burst of packets, where the burst size is some combination of the random delays, the magic 100, and the software and/or hardware queue lengths. The magic 100 is hard to increase much, since it is implemented as a timeout and timeouts have limited resolution. Utilities like ttcp have similar problems from this -- they tend to leave the network idle while they are waiting for a timeout, or are reduced to busy-waiting. On the same systems that have the highly variable ping throughput of 10-120 kpps due to the ramp-up: Modifying flood ping to actually flood gives a throughput of ~170 kpps at a cost of approximately doubling the latency. Modifying flood ping to be synchronous gives a constant throughput of ~8kpps. Apparently my ping throughput was never initially 10 kpps -- 10 is after some ramp-up, while 8 is consistent with the latency. The average latency at the time of measurement was 122 uS but I misremembered it as 95 uS. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070908220703.Y32678>