task04: change timings for large payload test

[miri64]

Due to fragmentation the average round trip time of a link-local ping
is about 140ms (depending on distance). This puts a strain on both
packet buffer and reassembly buffer on the sending nodes as it has to
handle at least two packets while it is also working on a reply.

Add to that that the at86rf2xx driver is only able to send when it is
not in receive state (and blocks until it leaves) the pinged node has
problems to get out the data it wants to send the echo replies while it
is being spammed with fragments containing follow-up echo requests.

Because the test is mainly about testing fragmentation, not
fragmentation under stress, I suggest we tweak the test parameters a
bit so the test takes the same time, but with less stress on the node.

Also see #113 (comment)

[danpetry]

With the automated script (i.e. using IoT-LAB), this works if you put the delay up to 300ms. But not 200 ms. I guess there's a longer round trip. Suggest this time instead?

[miri64]

With the automated script (i.e. using IoT-LAB), this works if you put the delay up to 300ms. But not 200 ms. I guess there's a longer round trip. Suggest this time instead?

Mh... Would have been good to provide some output with that, so I could assess. But I guess 300ms should be fine. Will fix

[miri64]

Done

[danpetry]

By my reckoning, for the same reason, the timing should be increased also on:

• test 05 task 02 (static routing test single hop, iotlab-m3, default route)
• test 05 task 04 (static routing test single hop, iotlab-m3, static route)

Re the iot-lab scripts, I'm having a look at it. But 300ms interval works ok for on-desk tests.

[miri64]

By my reckoning, for the same reason, the timing should be increased also on:

• test 05 task 02 (static routing test single hop, iotlab-m3, default route)
• test 05 task 04 (static routing test single hop, iotlab-m3, static route)

Let's do that in a separate PR

[danpetry]

Let's do that in a separate PR

Will open in a minute