[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nam bug when using random loss modules




Thanks for your reply.

Could you please explain what is the "snapshot". I checked for it on the
ns homepage, but I couldn't find a mention of a snapshot.

I also have another problem. When I run make, there are no errors
reported, but when I run make depend, I get : 
emulate/net-pcap.cc:60: pcap.h: No such file or directory
emulate/arp.cc:50: net/ethernet.h: No such file or directory
It is true. There are no files with such names!

I would like to install the error model after the queue using lossmodel.
Could you confirm that this Simulator::lossmodel would work for a duplex
link?

Thanks,

-Hussein

> 
> I think it should have been fixed in the current nam (and ns) snapshot.
> Previously Simulator::lossmodel and SimpleLink::errormodule does not
> generate any nam traces. You can manually add drop traces of error models,
> however, nam does not show that correctly because of abnormal the
> enqueue/drop order.
> 
> There are two solutions. First, if you are using ns snapshot you can use
> Simulator::link-lossmodel to install the error model (which installs
> an error model after the queue in a simple link), which allow any nam to
> view the trace correctly. Second, if you still prefer installing an error
> model before the queue in a simple link, you can download the current nam
> snapshot, which contains a fix for that. 
> 
> - Haobo
> 
> On Tue, 9 Mar 1999, AL-HUSSEIN ABOU-ZEID wrote:
> 
> > 
> > I've noticed that when you use nam with a model containing a two-state
> > time-based loss model, the animation works correctly up till the first
> > random loss, and after that it does strange things. One of these is that
> > it shows a buffer size that is greater than the maximum buffer size
> > allowed on the link (I am assuming this is a nam bug and not an ns bug).
> > Another problem is that, after the first random loss, it might not show
> > any packets getting through the link, as if the link remained in the bad
> > state for the rest of the simulation time. However, this proves not true
> > when checking the trace file, which implied a bug in the nam and not the
> > ns.
> > 
> > I understand that the two-state and multi-state models are
> > "under-developed" in the version I'm using (ns-v2.1b4a), so maybe someone
> > would be interested in taking this problem into consideration in future ns
> > releases.
> > 
> > Best Regards,
> > 
> >  --Hussein.
> > ------------------
> > Electrical Engineering Department
> > University of Washington, Seattle.
> > 
> 
>