Bugzilla – Bug 976
wifi-wired-bridging regression test fails because of rounding errors in mobility model
Last modified: 2012-10-03 17:58:36 EDT
the title says it all. on a 32bit machine ./waf --regression shows this: ---------- Traces differ in test: test-wifi-wired-bridging Reference traces in directory: /home/mlacage/code/ns-3-dev-ref-traces/wifi-wired-bridging.ref Traces in directory: /home/mlacage/code/ns-3-head/build/optimized/regression/traces/wifi-wired-bridging.ref Run the following command for details: diff -u /home/mlacage/code/ns-3-dev-ref-traces/wifi-wired-bridging.ref /home/mlacage/code/ns-3-head/build/optimized/regression/traces/wifi-wired-bridging.ref Or re-run regression testing with option -v ---------- FAIL test-wifi-wired-bridging diff -u /home/mlacage/code/ns-3-dev-ref-traces/wifi-wired-bridging.ref/wifi-wired-bridging.mob /home/mlacage/code/ns-3-dev/build/debug/regression/traces/wifi-wired-bridging.ref/wifi-wired-bridging.mob --- /home/mlacage/code/ns-3-dev-ref-traces/wifi-wired-bridging.ref/wifi-wired-bridging.mob 2010-08-07 20:49:19.000000000 +0200 +++ /home/mlacage/code/ns-3-dev/build/debug/regression/traces/wifi-wired-bridging.ref/wifi-wired-bridging.mob 2010-08-07 20:49:43.000000000 +0200 @@ -9,8 +9,8 @@ now=2000000000ns node=2 pos=1.169:3.377:0.000 vel=-0.953:-0.302:0.000 now=2000000000ns node=4 pos=21.666:3.894:0.000 vel=-0.020:1.000:0.000 now=3226374827ns node=2 pos=0.000:3.007:0.000 vel=0.953:-0.302:0.000 -now=3999999999ns node=2 pos=0.738:2.774:0.000 vel=-0.935:-0.356:0.000 now=4000000000ns node=3 pos=1.691:12.693:0.000 vel=0.790:0.613:0.000 now=4000000000ns node=5 pos=21.622:9.703:0.000 vel=0.599:0.800:0.000 now=4000000000ns node=4 pos=21.627:5.893:0.000 vel=0.243:0.970:0.000 -now=4789173150ns node=2 pos=0.000:2.493:0.000 vel=0.935:-0.356:0.000 +now=4000000000ns node=2 pos=0.738:2.774:0.000 vel=-0.935:-0.356:0.000 +now=4789173152ns node=2 pos=0.000:2.493:0.000 vel=0.935:-0.356:0.000 which happens because the mobility model is using floating point calculations to calculate event delays and these delays change from one machine to another. Oh, fun.
I removed the .mob trace for now so I could get regressions to pass in order to start rigorous testing of ns-3-dev. changesets: ns-3-dev: http://code.nsnam.org/ns-3-dev/rev/5c11ea507486 ns-3-dev-ref-traces: http://code.nsnam.org/ns-3-dev-ref-traces/rev/d447a2d01164
Bug closed. ns-3-dev changeset: 8009389af158
Well, it wasn't quite "fixed", in that the problem reported originally was not dealt with (that floating-point computations may differ slightly on different platforms)-- not sure how to make this completely portable. What was fixed was as follows: - re-enable the ability to provide ascii-based mobility traces (which had broken somewhere along the way when OutputStreamWrapper code was introduced) -- this necessitated the change to MobilityHelper::EnableAsciiAll in changeset http://code.nsnam.org/ns-3-dev/rev/94215be61edf -- note, due to recent random variable changes, this particular trace does not seem to have the portability problems anymore - provide an example that shows how to generate mobility trace, in the absence of wifi-wired-bridging. This is checked into src/mobility/examples/mobility-trace-example.cc - convert this example also into a regression test. This may or may not fail on multiple platforms; we shall see. Hopefully this particular scenario is safe, and we can regression test the ability to generate these ascii .mob files. - extend the ns-3 test code and macros to perform ascii-based file comparisons, along the lines of what Craig did for pcap-based file comparisons.
If this bug shows up again, a possible fix is to create a function that compares 2 mobility files to see if they match up to some tolerance in the time, position, and velocity for every mobility line rather than forcing the double values created on different machines to be exactly the same.