|
Bugzilla – Full Text Bug Listing |
| Summary: | test result divergence for lte-frequency-reuse test | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
| Component: | lte | Assignee: | Nicola Baldo <nicola> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P5 | ||
| Version: | pre-release | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
patch to fix stream assignments
diff of log files patch to fix |
||
|
Description
Tom Henderson
2014-09-17 03:14:45 UTC
Created attachment 1881 [details]
patch to fix stream assignments
The attached patch should be applied, but it does not solve the problem entirely. There is something else going on that needs to be fixed.
To debug further, I enabled LteHelper::EnableLogComponents() and disabled all tests except for test case:
LteSoftFfrAreaTestCase ("LteSoftFfrAreaTestCasePss1", "ns3::PssFfMacScheduler")
When comparing the logging output of the two machines, the simulation log output is the same until the first occurrence of PssFfMacScheduler::DoSchedDlTriggerReq()
in the debugger, around line 1520 of the source file:
if (lcActives == 0)
{
// Set to max value, to avoid divide by 0 below
lcActives = (uint16_t)65535; // UINT16_MAX;
}
uint16_t RgbPerRnti = (*itMap).second.size ();
std::map <uint16_t,SbMeasResult_s>::iterator itCqi;
I found that the value of RgbPerRnti is '3' on Linux, and '8' on OS X when this is first entered.
Here is some more data about the differences between the two platforms. I took these steps 1) disabled all test cases except for the one causing differences, and I applied the patch to assign consistent RV streams (I verified that all calls to "GetValue()" were the same for both machines) 2) ran the following command on both machines "NS_LOG="*" ./waf --run "test-runner --suite=lte-frequency-reuse" > log.txt 2>&1 (this takes a while due to the amount of log data) 3) looked at the first 1000000 lines: head -1000000 log.txt > log.head.txt 3) post-processed both log files to strip all hex memory addresses from the logs, so I could diff them: perl -pi -w -e 's/0x[0-9a-f]+//g' log.head.txt 5) diffed the two log.head.txt files (the machine corresponding to '-' lines is Linux, the machine with '+' is OS X) The initial part of the diff is pretty noisy but the simulation starts at time 0 at line 733245 of this diff. The first (possibly minor?) diff is found in constructing a packet burst: 733345 @@ -491464,36 +484466,36 @@ 733346 0s -1 Object:Object() 733347 0s -1 PacketBurst:PacketBurst() 733348 0s -1 Object:SetTypeId(, 0s -1 TypeId:GetName() 733349 -0s -1 TypeId:GetName(, 77) 733350 -0s -1 TypeId:LookupInformation(, 77) 733351 +0s -1 TypeId:GetName(, 65) 733352 +0s -1 TypeId:LookupInformation(, 65) 733353 ns3::PacketBurst) 733354 0s -1 Object:Check() 733355 0s -1 AttributeConstructionList:AttributeConstructionList() 733356 0s -1 Object:Construct(, ) 733357 0s -1 ObjectBase:ConstructSelf(, ) 733358 0s -1 Object:GetInstanceTypeId() 733359 -0s -1 ObjectBase:ConstructSelf(): [DEBUG] 0s -1 TypeId:GetAttributeN() 733360 -0s -1 TypeId:GetAttributeN(, 77) 733361 -0s -1 TypeId:LookupInformation(, 77) 733362 -0s -1 TypeId:GetName() 733363 -0s -1 TypeId:GetName(, 77) 733364 -0s -1 TypeId:LookupInformation(, 77) 733365 -construct tid=ns3::PacketBurst, params=0 733366 +0s -1 ObjectBase:ConstructSelf(): [DEBUG] construct tid=0s -1 TypeId:GetName() 733367 +0s -1 TypeId:GetName(, 65) 733368 +0s -1 TypeId:LookupInformation(, 65) 733369 +ns3::PacketBurst, params=0s -1 TypeId:GetAttributeN() 733370 +0s -1 TypeId:GetAttributeN(, 65) 733371 +0s -1 TypeId:LookupInformation(, 65) this diff also repeats at 7333421; basically, object construction of PacketBurst seems to generate some different log statements. I'm not sure whether this is of any importance. The first substantive difference that I spotted was shortly after: 733471 -0s -1 LteFfrSoftAlgorithm:DoReportUlCqiInfo() 733472 -0s -1 LteFfrSoftAlgorithm:DoReportUlCqiInfo(): [WARN ] Method should not be called, because it is empty 733473 -0s -1 LteFfrSoftAlgorithm:DoGetAvailableUlRbg() 733474 -0s -1 LteFfrSoftAlgorithm:DoGetMinContinuousUlBandwidth() 733475 -0s -1 LteFfrSoftAlgorithm:DoGetMinContinuousUlBandwidth(): [INFO ] minContinuousUlBandwidth: 6 733476 +0s -1 LteFrSoftAlgorithm:DoReportUlCqiInfo() 733477 +0s -1 LteFrSoftAlgorithm:DoReportUlCqiInfo(): [WARN ] Method should not be called, because it is empty 733478 +0s -1 LteFrSoftAlgorithm:DoGetAvailableUlRbg() 733479 +0s -1 LteFrSoftAlgorithm:DoGetMinContinuousUlBandwidth() 733480 +0s -1 LteFrSoftAlgorithm:DoGetMinContinuousUlBandwidth(): [INFO ] minContinuousUlBandwidth: 8 Here, note that minContinuousUlBandwidth is 6 on Linux but 8 on OS X. Another interesting diff is a little further down, where MultiModeSpectrumChannel::StartTx() only occurs on the OS X machine 734024 @@ -492451,6 +485453,17 @@ 734025 0.001s -1 LteSpectrumSignalParameters:Copy() 734026 0.001s -1 SpectrumSignalParameters:SpectrumSignalParameters(, ) 734027 0.001s -1 LteSpectrumSignalParameters:LteSpectrumSignalParametersDlCtrl Frame(, ) 734028 +0.001s -1 LteSimpleSpectrumPhy:GetMobility() 734029 +0.001s -1 LteSimpleSpectrumPhy:GetDevice() 734030 +0.001s -1 EventImpl:EventImpl() 734031 +0.001s -1 DefaultSimulatorImpl:Schedule(, 0, ) 734032 +0.001s -1 SystemThread:Equals() 734033 +0.001s -1 MapScheduler:Insert(, , 1000000, 51) 734034 +0.001s -1 EventId:EventId(, , 1000000, 4294967295, 51) 734035 +0.001s -1 MultiModelSpectrumChannel:StartTx(): [LOGIC] copying signal parameters 734036 +0.001s -1 LteSpectrumSignalParameters:Copy() 734037 +0.001s -1 SpectrumSignalParameters:SpectrumSignalParameters(, ) 734038 +0.001s -1 LteSpectrumSignalParameters:LteSpectrumSignalParametersDlCtrl Frame(, ) 734039 0.001s -1 LteSpectrumPhy:GetMobility(, m_cellId , 1) 734040 0.001s -1 Vector:CalculateDistance(200:0:0, 0:0:0) 734041 0.001s -1 IsotropicAntennaModel:GetGainDb(, (0, 1.5708)) ---- My sense is that the initial conditions (spectrum values?) of this test case get set up slightly differently for some reason, outside of random variables. The simulation executes about the same until PssFfMacScheduler::DoSchedDlTriggerReq() gets called, at which point the results begin to slightly diverge. There may be more information in this diff about how the simulation setup diverges (before time 0) that I didn't pick out of the noise of Time and SystemMutex log statements. I will attach the compressed diff file as an attachment; perhaps further munging of the diff will yield other ideas. Created attachment 1882 [details]
diff of log files
Created attachment 1933 [details]
patch to fix
Patch from Piotr
---- Bug 1986 FIX user: Piotr Gawlowicz <gawlowicz.p@gmail.com> files: src/lte/model/pss-ff-mac-scheduler.cc url: http://code.nsnam.org/ns-3-dev/rev/b6f6e368aa51 |