[Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow HighPrecision::Div()
code at nsnam.ece.gatech.edu
Tue Nov 24 04:28:32 PST 2009
--- 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.
More information about the Ns-bugs