[Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow HighPrecision::Div()

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=695





--- Comment #8 from Mathieu Lacage <mathieu.lacage at sophia.inria.fr>  2009-11-24 07:28:31 EDT ---
(In reply to comment #5)
>   Mathieu, could you explain me why do we need 128 bits for time at all? We

That goes back to a long discussion a long long time ago. To make it short:
  - we want to make it easy for model developers to get the same simulation
results on different platforms with different floating point arithmetic units
  - hence, we want to encourage avoiding the use of floating point arithmetic
  - but users still need to make simple calculations which need more precision
than simple integer arithmetic
  - our internal time is 64bits
  - hence, user calculations need more precision than 64 bits
  - hence, the easiest thing to do is to give them 64.64 (128) precision.

> always find high precision arithmetics on top of the profiles (oprofile,
> cachegrind) -- can we try to avoid them using "native" 64 bit time? More

In some models, (say, DcfManager), we use Time because it's convenient, not
because we need to. i.e., a lot of the manager code could work with simple
integer arithmetics. In fact, it was originally written that way.

> globally, I have an impression that ns-3 is too slow to practically simulate
> O(100) wifi stations with dense traffic -- do you agree? 

I suspect that if you try to make 100 stations _interfere_, then, yes, you will
run into interesting problems but mainly because the underlying interference
PHY model is O(n2) and, hopefully, you can easily fix this by using a different
PHY model. Otherwise, I would be happy to help fix any optimization issue you
have with the wifi models to make them useful to you.

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.