Bug 976 - wifi-wired-bridging regression test fails because of rounding errors in mobility model
wifi-wired-bridging regression test fails because of rounding errors in mobil...
Product: ns-3
Classification: Unclassified
Component: mobility models
All All
: P5 normal
Assigned To: Pavel Boyko
Depends on:
  Show dependency treegraph
Reported: 2010-08-07 14:52 EDT by Mathieu Lacage
Modified: 2012-10-03 17:58 EDT (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Lacage 2010-08-07 14:52:04 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.
Comment 1 Josh Pelkey 2010-08-09 19:15:26 EDT
I removed the .mob trace for now so I could get regressions to pass in order to start rigorous testing of ns-3-dev.


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
Comment 2 Mitch Watrous 2012-10-03 14:48:27 EDT
Bug closed.

ns-3-dev changeset:  8009389af158
Comment 3 Tom Henderson 2012-10-03 16:57:52 EDT
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.
Comment 4 Mitch Watrous 2012-10-03 17:58:36 EDT
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.