Karl Reichert wrote: > -------- Original-Nachricht -------- > Datum: Thu, 10 May 2007 11:39:22 +0200 > Von: Jan Kiszka <[EMAIL PROTECTED]> > An: Karl Reichert <[EMAIL PROTECTED]> > CC: rtnet-users <rtnet-users@lists.sourceforge.net> > Betreff: Re: [RTnet-users] How do Slaves improve precision of their own slot > starting times? > >> 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 >> > But how is this jittering handled than? To my mind, if the master jitters, > i.e. putting his data later on the wire than planned, than all following also > have to put their data later on the wire, otherwise we get a collision. Or is > therefore the TDMA_OFFSET (from rtnet.conf) defined, which would leave enough > space that jitter doesn't causes any damage?
Precisely the latter. The point is that it wouldn't make much sense to take care of delayed master packets, you would have to do the same for slave packets. And that would mean to evaluate every frame on the wire in order to detect jitters of the preceding slot. Not efficient. 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
