Karl Reichert wrote: >>>>> I'm sorry but I still don't get it. And sorry for the -20/-30 mistake. >>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I read the paper "RTnet -- A Flexible Hard Real-Time Networking >>>>>>>> Framework" at >>>>>> http://www.rts.uni-hannover.de/rtnet/download/RTnet-ETFA05.pdf and I >>>>>>>> have a question concerning chapter 3.2, formula 3. >>>>>>>>> T_slot = T_sched + t_slot - t_offset >>>>>>>>> >>>>>>>>> As far as I understand this formula, the slaves calculate their >> own >>>>>>>> starting point T_slot from T_sched (the planned transmission time >> of >>>>>> master), >>>>>>>> t_slot (slot duration?) and t_offset (offset between master and >> slave >>>>>>>> clock). To my mind, this doesn't makes any sence. Maybe I >>>> misunderstand >>>>>> one of >>>>>>>> the variables, but let me give a small example: >>>>>>>>> T_sched = 15 (absolute time point) >>>>>>>>> t_slot = 10 (duration) >>>>>>>>> t_offset = 20 >>>>>>>>> >>>>>>>>> Then, slave's starting point would be 15+10-20=5 >>>>>>>>> But how is it possible, if the master is the first one sending? I >>>>>> don't >>>>>>>> understand this formula. >>>>>>>> >>>>>>>> Oops, you stumbled over an impreciseness of the variables in that >>>>>> paper. >>>>>>>> They must read T_sched,master and T_slot,slave, i.e. the first one >> is >>>>>>>> related to the master view of time while the second one was >>>> transformed >>>>>>>> to the slave time base. >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>> But still, this doesn't makes sense to me. As I understand the >> paper, >>>>>> formula 2 and 3 should fix potential scheduling jitters (the time >>>> difference >>>>>> between scheduled and "real" sending time on the master). But how can >>>> this >>>>>> be fixed, if the formula deals with the T_master_sched and not the >>>>>> T_master_real (=T_master_xmit)? >>>>>>> Let me give an example: >>>>>>> at the same point of time (the moment the master sends sth), master >>>>>> clock=10, slave clock=30 >>>>>>> the master jitter may be 2, which means that T_master_sched=10 and >>>>>> T_master_xmit=12 >>>>>>> t_travel may be 3 >>>>>>> t_slot (Slot-Length) may be 5 >>>>>>> >>>>>>> t_offset=12+3-35=-30 >>>>>> Hmm, my calculator prints "-20"... ;) >>>>>> >>>>> Okay, I agree, sorry for the mistake. >>>>> >>>>>>> T_slave_slot=10+5+30=45 >>>>>> And that would give 35 then, which is precisely the expected value (5 >>>> us >>>>>> >from the scheduled cycle start 30 us in slave time). 8) >>>>>> >>>>> But if slave starts sending at 35 (which means 15 from master's point >> of >>>> view) then it would send at the same time the master does. The slot is >> 5, >>>> so if master would start exactly at 10, this would work. But because of >> the >>>> jitter, it starts sending at 12, so if it uses his whole 5 ticks long >>>> slot, it would end at 17 and this would clash with slave, which starts >> sending >>>> already at 15. >>>> >>>> I think I see the misunderstanding: t_slot is not the slot size of the >>>> master slot here. It is the slot _offset_ (relative to the cycle start) >>>> of some arbitrary slave (or the master - then t_offset would just be >> 0). >>>> That offset must account for a) the time the preceding slot requires at >>>> least and b) the potential jitter of the preceding slot user. >>> Okay, I think this misunderstanding seems to be in formula 2, not 3. You >> say, the offset must account also the jitter. But to my mind it doesn't. >>> Let's try an example with above numbers: >>> a) not jitter occurs: t_offset = 10 + 3 - 33 = -20 >>> b) jitter is 2: t_offset = 12 + 3 - 35 = -20 >>> T_slave_recv changes from 33 to 35, because of master's jitter of 2 the >> data arrives 2 ticks later at slave. >>> So, as a result, the offset does not take any jitter into account. >> Which is precisely the intention: Make the clock offset estimation >> _independent_ of the synchronisation signal sender jittery. Now you can >> use the _scheduled_ cycle beginning (based on the master clock) which >> comes along with the sync frame to calculate the _scheduled_ slot >> beginning of some slave (based on the respective local slave clock). >> >> Jan >> > Okay, so clock offset is independent from jitter. This is how I also > understood this formula. > And I also agree, with formula 3 I calculate the _scheduled_ slot beginning > of the slave. > But, how do I get the _real_ one, which means, the one that is respecting the > jitter of the master? That's what I don't understand.
But that is not the goal. The goal is to meet the planned transmission dates _even_ if the synchronising master jitters (within known limits) and would otherwise delay (or bring forward) the whole cycle schedule. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
