Re: [Bloat] Some results of the latency under load tool

[Jonathan Morton <chromatix99@gmail.com>]

On 20 Mar, 2011, at 11:50 pm, Dave Täht wrote:

> B) Due to the dependence on the gnu scientific library it seems unlikely
> this will build on openwrt. Also, if there is heavy math anywhere in
> this app, it needs to be done outside the testing loop on a non FPU
> enabled processor such as most arms to not skew the test.

I'm aware of the limitations of older ARM CPUs, as I have had to work with them on occasion.  I don't have any with Ethernet at home though.  The maths inside the main loops is limited to calculating time differences, comparing them and determining when to stop - there may be some optimisation possible there, but it's not ridiculous.

The main loops are actually slightly elastic, because recv() will give whatever data is available at the time it is called, and the fattest calculations are only done once per loop.  Under normal circumstances, that should be every 1.2 KB, but it scales up to 64KB if the CPU temporarily can't keep up (or if a lot of data becomes available in one go).

> It ate 17% of cpu on the arm, and ~8% of cpu on davepc.

Looks tolerable to me.  Even my ancient CISC PC can trigger the symptoms well enough.

> Similarly there are rng's in the Linux kernel and hardware sources, I'm
> not sure to what extent you need randomness (I looked at the code  only briefly)

The spew() function uses the PRNG to generate incompressible traffic, since compressibility does matter to some network technologies.  I used GSL purely to get access to a very fast PRNG that still produces good numbers - it's just a shame that this is a relatively large, general-purpose library.  I originally intended to checksum the data and thus ensure that it arrived intact, but I had to delete that feature to get around a race condition.

> So you are saying lower values of hz is horrible?

Yes.  0.02 Hz means the application was waiting 50 seconds for data somehow.

 - Jonathan