Bug 976

Summary:	wifi-wired-bridging regression test fails because of rounding errors in mobility model
Product:	ns-3	Reporter:	Mathieu Lacage <mathieu.lacage>
Component:	mobility models	Assignee:	Pavel Boyko <boyko>
Status:	RESOLVED FIXED
Severity:	normal	CC:	jpelkey, ns-bugs, tomh, watrous
Priority:	P5
Version:	pre-release
Hardware:	All
OS:	All

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.

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

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.