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

Re: [ns] Timestamp trouble



My fault ! sorry for being so precipitous in searching
for help: my changes did work ... after doing "make
depend" before "make" :-)
Thanks.



 --- Marcelo Lipas Augusto <[email protected]> ha
scritto: > Hi, Felix.
> 
> I tried to use the already existent UDP timestamp to
> do the same job you
> want. Strangely enough, it seems all generated
> packtets have a zero
> timestamp (what obviously won't work). I guess if
> someone knows how to fix
> this problem, you won't need to write any code, you
> will have only to use
> the existing code.
> **Anyone know what's wrong with the current UDP
> timestamp??**
> 
> Thank you!
> 
> --Lipas
> 
> 
> ----- Original Message -----
> From: "Andrea Josi" <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, August 29, 2001 6:58 AM
> Subject: [ns] Timestamp trouble
> 
> 
> > Dear Felix Ko,
> >
> > i am encountering the same large simulation memory
> and
> > time problems you quoted in
> >
> >
>
http://www.isi.edu/nsnam/archive/ns-users/webarch/current/msg01836.html
> >
> > I need to calculate the packets' end to end delay
> of a
> > multicast traffic. I have tried to apply the same
> > solution you suggested in that
> > mail,  but i am encountering this problem:
> >
> > i have added a field and a corresponding method in
> the
> > common header, "my_ts_"  and  "my_timestamp()"
> >
> > struct hdr_cmn {
> > ..............
> > .............
> >  double ts_;  // timestamp: for q-delay
> measurement
> >  double my_ts_;   <---   this is mine
> > .....
> > ............
> > inline double& timestamp() { return (ts_); }
> > inline double& my_timestamp() { return (my_ts_); }
> > <-- this is mine
> >
> > I've also added a line in udp.cc in the places
> where
> > the original timestamp is used
> >
> > hdr_cmn::access(p)->timestamp() =
> >       (u_int32_t)(SAMPLERATE*local_time);
> >
> > hdr_cmn::access(p)->my_timestamp() =
> > local_time;<--this is mine
> >
> > I have implemented a receiver similar to
> > Agent/LossMonitor; in the recv function i have put
> > these lines
> >
> > hdr_rtp* p = hdr_rtp::access(pkt);
> > start_time_ =
> hdr_cmn::access(pkt)->my_timestamp();
> >
> > The simulation reports an error, which should
> concern
> > multicast forwarding; if i comment the lines i
> wrote
> > before, i get no error !
> > It seems like udp timestamp is used to identify
> > something ...?!!!
> > What was your solution ? (i don't really care to
> make
> > mine work, what i really need is a way to get the
> > packets departure times!)
> > Thanks for your help,
> >
> >                 Andrea Josi.
> >
> >
> > ns: _o29 new-group 2 -2147483648 0 wrong-iif:
> can't
> > read "protocols_(0)": no such element in array
> >     while executing
> > "$protocols_($iface) upcall $code $source $group
> > $iface"
> >     (procedure "_o30" line 9)
> >     (mrtObject upcall line 9)
> >     invoked from within
> > "$mrtObject_ upcall $code $src $group $iface"
> >     (procedure "_o24" line 3)
> >     (Node new-group line 3)
> >     invoked from within
> > "$node_ new-group $src $group $iface $code"
> >     (procedure "_o29" line 3)
> >     (Classifier/Multicast new-group line 3)
> >     invoked from within
> > "_o29 new-group 2 -2147483648 0 wrong-iif"
> >
> >
>
______________________________________________________________________
> > Do You Yahoo!?
> > Il tuo indirizzo gratis e per sempre @yahoo.it su
> http://mail.yahoo.it
> >
> >
>  

______________________________________________________________________
Do You Yahoo!?
Il tuo indirizzo gratis e per sempre @yahoo.it su http://mail.yahoo.it