Test Tree Regression Tests
I have done a few tests with delay / loss, in particular the instances specified on
http://linux-net.osdl.org/index.php/DCCP_Testing#Regression_testing
Without delay/loss, I get line speed (92.0 Mbps from e100 to e1000, 95.0 Mbps from e1000 to e100).
This was for t seconds; the following test runs were all done for t = 20 seconds.
1) Light Loss (40 msec RTT, 1 %loss)
------------------------------------
* calculated value: 3.20 Mbps (s = 1424)
* Test runs: 3.21 Mbps, 3.19 Mbps, 3.18 Mbps
2) Heavy Loss (150 msec RTT, 10 %loss)
--------------------------------------
* calculated value: 134.34 Kbps
* test runs:
(a) with a FIFO length of 1000 at the bridge 209 Kbps, 186 Kbps, 182 Kbps
(b) with a FIFO length of 10,000 at the bridge 197 Kbps, 176 Kbps, 134 Kbps
(I am using different FIFO length since I know from experience that otherwise the bridge can also incur loss.)
=> I actually have a question here, regarding the variability.
I am setting the same loss in either direction, i.e. on the bridge I do
tc qdisc add dev eth0 root netem delay 75ms loss 10% tc qdisc add dev eth1 root netem delay 75ms loss 10%
I note that on http://linux-net.osdl.org/index.php/DCCP_Testing#Network_emulation_setup
different loss values for forward/return are used. Has anyone further experience with this? I wonder if feedback loss has heavier implications than forward loss?
Script I used: http://www.erg.abdn.ac.uk/users/gerrit/dccp/testing_dccp/tfrc_test.tc
Quoted 9 lines · Gerrit Renker
2) Heavy Loss (150 msec RTT, 10 %loss)
--------------------------------------
* calculated value: 134.34 Kbps
* test runs:
(a) with a FIFO length of 1000 at the bridge 209 Kbps, 186 Kbps, 182 Kbps
(b) with a FIFO length of 10,000 at the bridge 197 Kbps, 176 Kbps, 134 Kbps
Quoted 3 lines
(I am using different FIFO length since I know from experience that otherwise the bridge can also incur loss.)
Can you post scripts for altering the fifo length? Is that equivalent to the following for rate-limited? (from test page) /sbin/tc qdisc add dev lan0 root handle 1:0 netem delay $1ms /sbin/tc qdisc add dev lan1 root handle 1:0 netem delay $1ms /sbin/tc qdisc add dev lan0 parent 1:1 handle 10: tbf rate $2kbit buffer 10000 limit 30000
Quoted 11 lines
=> I actually have a question here, regarding the variability.
I am setting the same loss in either direction, i.e. on the bridge I dotc qdisc add dev eth0 root netem delay 75ms loss 10% tc qdisc add dev eth1 root netem delay 75ms loss 10%
I note that on http://linux-net.osdl.org/index.php/DCCP_Testing#Network_emulation_setup
different loss values for forward/return are used. Has anyone further experience with this? I wonder if feedback loss has heavier implications than forward loss?
The reason for me putting zero % loss on return path is that we are testing unidirectional flows. As such I wanted all feedback to come back and if we lost feedback packets it would increase variability. We should test loss of feedback packets for protocol reasons but not so much for performance testing.
Quoted 3 lines
Script I used: http://www.erg.abdn.ac.uk/users/gerrit/dccp/testing_dccp/tfrc_test.tc
Your webserver seems to be down.... No pages on
http://www.erg.abdn.ac.uk/ work at present.
Ian
Signature · 3 lines
Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
| > (I am using different FIFO length since I know from experience that otherwise the bridge | > can also incur loss.) | > | Can you post scripts for altering the fifo length? Is that equivalent | to the following for rate-limited? (from test page) | /sbin/tc qdisc add dev lan0 root handle 1:0 netem delay $1ms | /sbin/tc qdisc add dev lan1 root handle 1:0 netem delay $1ms | /sbin/tc qdisc add dev lan0 parent 1:1 handle 10: tbf rate $2kbit | buffer 10000 limit 30000
It is comparable but not equivalent, since in the above you are using a TBF which will change the nature of the traffic. I use the following (with qlen000):
tc qdisc add dev eth0 root handle 1:0 netem delay ${delay}ms
tc qdisc add dev eth0 parent 1:1 pfifo limit ${qlen}(The same configuration is used on both interfaces.) I found that merely adding the tx qlen of the NIC (via `ip link set ...') does not do much, and that especially if either the delay is slightly longer or the difference in traffic is drastic (e.g. 100Mbps link with a TBF rate of 1 Mbps), a longer FIFO length is needed to avoid packets being dropped at the traffic shaper.
Plus, one gets all the nice statistics about queue drops and requeued etc.
| > I note that on http://linux-net.osdl.org/index.php/DCCP_Testing#Network_emulation_setup | > different loss values for forward/return are used. Has anyone further experience with this? | > I wonder if feedback loss has heavier implications than forward loss? | > | | The reason for me putting zero % loss on return path is that we are | testing unidirectional flows. As such I wanted all feedback to come | back and if we lost feedback packets it would increase variability. We | should test loss of feedback packets for protocol reasons but not so | much for performance testing.
Ah - I see, so this means that for performance testing I'd have to use:?
tc qdisc add dev eth0 root netem delay 75ms loss 10% # the forward path
tc qdisc add dev eth1 root netem delay 75ms # reverse path (no feedback loss)
Maybe we should add a line on the OSDL page, it is something that had slightly confused me.
| Your webserver seems to be down.... No pages on | http://www.erg.abdn.ac.uk/ work at present.
Occasional, short downtime is possible, but usually the webserver runs all the time. It is ok again.
Quoted 10 lines · Gerrit Renker
| > (I am using different FIFO length since I know from experience that otherwise the bridge | > can also incur loss.) | > | Can you post scripts for altering the fifo length? Is that equivalent | to the following for rate-limited? (from test page) | /sbin/tc qdisc add dev lan0 root handle 1:0 netem delay $1ms | /sbin/tc qdisc add dev lan1 root handle 1:0 netem delay $1ms | /sbin/tc qdisc add dev lan0 parent 1:1 handle 10: tbf rate $2kbit | buffer 10000 limit 30000
Quoted 6 lines
It is comparable but not equivalent, since in the above you are using a TBF which will change the nature of the traffic. I use the following (with qlen000):
tc qdisc add dev eth0 root handle 1:0 netem delay ${delay}ms tc qdisc add dev eth0 parent 1:1 pfifo limit ${qlen}
OK - I must confess to not studying the difference in queue disciplines greatly, but I did find quickly the default queue lengths were no use really.
Quoted 6 lines
(The same configuration is used on both interfaces.) I found that merely adding the tx qlen of the NIC (via `ip link set ...') does not do much, and that especially if either the delay is slightly longer or the difference in traffic is drastic (e.g. 100Mbps link with a TBF rate of 1 Mbps), a longer FIFO length is needed to avoid packets being dropped at the traffic shaper.
Plus, one gets all the nice statistics about queue drops and requeued etc.
OK
Quoted 11 lines
| > I note that on http://linux-net.osdl.org/index.php/DCCP_Testing#Network_emulation_setup | > different loss values for forward/return are used. Has anyone further experience with this? | > I wonder if feedback loss has heavier implications than forward loss? | > | | The reason for me putting zero % loss on return path is that we are | testing unidirectional flows. As such I wanted all feedback to come | back and if we lost feedback packets it would increase variability. We | should test loss of feedback packets for protocol reasons but not so | much for performance testing.
Quoted 5 lines
Ah - I see, so this means that for performance testing I'd have to use:?
tc qdisc add dev eth0 root netem delay 75ms loss 10% # the forward path
tc qdisc add dev eth1 root netem delay 75ms # reverse path (no feedback loss)
Yes - I just happened to have a line with loss 0% from my python code which is functionally equivalent to above.
Quoted 2 lines
Maybe we should add a line on the OSDL page, it is something that had slightly confused me.
Agree
Quoted 5 lines
| Your webserver seems to be down.... No pages on | http://www.erg.abdn.ac.uk/ work at present.Occasional, short downtime is possible, but usually the webserver runs all the time. It is ok again.
Fine now.
Signature · 3 lines
Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz
Quoting Ian McDonald:
| > It is comparable but not equivalent, since in the above you are using a TBF which will change the nature
| > of the traffic. I use the following (with qlen000):
| >
| > tc qdisc add dev eth0 root handle 1:0 netem delay ${delay}ms
| > tc qdisc add dev eth0 parent 1:1 pfifo limit ${qlen}
| >
| OK - I must confess to not studying the difference in queue
| disciplines greatly, but I did find quickly the default queue lengths
| were no use really.I have done a little more testing and found that in this setting the FIFO lengths apparently do not have a big impact. But I recall from earlier experiences with TBF and rate-limited traffic that under-dimensioned queue lengths can lead to drops when the traffic is heavy.
| > | The reason for me putting zero % loss on return path is that we are | > | testing unidirectional flows. As such I wanted all feedback to come | > | back and if we lost feedback packets it would increase variability. We | > | should test loss of feedback packets for protocol reasons but not so | > | much for performance testing. | > Ah - I see, so this means that for performance testing I'd have to use:? | > | > tc qdisc add dev eth0 root netem delay 75ms loss 10% # the forward path | > tc qdisc add dev eth1 root netem delay 75ms # reverse path (no feedback loss) | > | Yes - I just happened to have a line with loss 0% from my python code | which is functionally equivalent to above.
I have added that to my script and tested a bit. It didn't decrease the variability drastically (it is still 130 Kbps ... 244 Kbps for the 150ms RTT / 10% loss case and t second runs), but then, we are not dealing with a scientific instrument here; and there are lots of other factors which influence the traffic.
I put the script online on http://www.erg.abdn.ac.uk/users/gerrit/dccp/testing_dccp/tfrc_test.tc
Suggestions for improvements (a pythonised version would certainly be nice) are welcome.