Vernon, Can you kindly resend me a clean patch over the latest CVS ?
Regards-- Subrata On Tue, 2008-06-03 at 18:53 +0530, Subrata Modak wrote: > I would really apolozise that i played foul with your patch. It gave me > some problem applying on the latest LTP CVS > (http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/realtime). > > $ patch --dry-run -p1 < ../CorrectStartLatencyForScheduleLatency.patch > patching file testcases/realtime/func/sched_latency/sched_latency.c > patching file testcases/realtime/include/librttest.h > Hunk #1 FAILED at 312. > 1 out of 1 hunk FAILED -- saving rejects to file > testcases/realtime/include/librttest.h.rej > patching file testcases/realtime/lib/librttest.c > patching file testcases/realtime/func/sched_latency/sched_latency.c > patching file testcases/realtime/include/librttest.h > patching file testcases/realtime/lib/librttest.c > > I had a forceful merge. So, may be the source is broken somewhere. > > Can you please review the latest CVS and resend me your updates once > again. Sorry for bothering you this much. > > Regards-- > Subrata > > On Fri, 2008-05-30 at 15:14 -0700, Vernon Mauery wrote: > > I spent some time looking at the sched_latency test trying to see why it > > took so long to start the thread. The java version of the test takes > > a comparable amount of time to start the thread as it does for each period. > > The rt-test version was taking an order of magnitude longer. After digging > > through the java documentation, I found that the RealtimeThread does not > > actually start executing until the RealtimeThread.waitForNextPeriod() > > fulfills the time specified in the PeriodicParameters parameter included in > > its constructor. So all the tests are scheduled to run about 1 second > > after the threads are created. This gives the system plenty of time to > > create the thread (a non-realtime code path), set the scheduling parameters > > and then sleep until the specified run time. The start latency as measured > > by the test goes something like this: > > > > start_time = nanoTime() + 1000000000; > > rt = new realtimeThread(sched_param, new \ > > PeriodicParameters(start_time, ...), ..., run); > > > > /* by the rtsj specification, this method will not run until start_time */ > > run() { > > now = nanoTime(); > > start_latency = now - start_time; > > ... > > } > > > > The rt-tests version went something like this: > > > > start_time = rt_gettime(); > > create_fifo_thread(periodic_thread, (void*)0, PRIO); > > > > periodic_thread() { > > now = rt_gettime(); > > start_latency = now - start; > > ... > > } > > > > As you can see, the start_latency is a very different measurement in these > > two cases. In the first, it is basically the initial starting latency as > > measured by the remainder of the loops. In the second, the execution path > > of creating the pthread is also counted in the latency. While this might > > be an important number for us to keep low in our testing, this is not what > > the java test is measuring. > > > > This patch puts the rt-test version in line with the java version. I also > > think this is reasonable since the rt-wiki says that we should _NEVER_ > > create threads on the real-time stage. > > > > Signed-off-by: Vernon Mauery <[EMAIL PROTECTED]> > > > > diff --git a/testcases/realtime/func/sched_latency/sched_latency.c > > b/testcases/realtime/func/sched_latency/sched_latency.c > > index 021ee94..5c65704 100644 > > --- a/testcases/realtime/func/sched_latency/sched_latency.c > > +++ b/testcases/realtime/func/sched_latency/sched_latency.c > > @@ -126,6 +126,9 @@ void *periodic_thread(void *arg) > > int failures = 0; > > nsec_t next = 0, now = 0, sched_delta = 0, delta = 0, prev = 0, > > iter_start; > > > > + /* wait for the specified start time */ > > + rt_nanosleep_until(start); > > + > > now = rt_gettime(); > > start_delay = (now - start)/NS_PER_US; > > iter_start = next = now; > > @@ -279,7 +282,8 @@ int main(int argc, char *argv[]) > > exit(1); > > } > > > > - start = rt_gettime(); > > + /* wait one quarter second to execute */ > > + start = rt_gettime() + 250 * NS_PER_MS; > > per_id = create_fifo_thread(periodic_thread, (void*)0, PRIO); > > > > join_thread(per_id); > > diff --git a/testcases/realtime/include/librttest.h > > b/testcases/realtime/include/librttest.h > > index c298f34..dbc4ab0 100644 > > --- a/testcases/realtime/include/librttest.h > > +++ b/testcases/realtime/include/librttest.h > > @@ -312,6 +312,10 @@ void nsec_to_ts(nsec_t ns, struct timespec *ts); > > */ > > int ts_to_nsec(struct timespec *ts, nsec_t *ns); > > > > +/* rt_nanosleep: sleep until absolute time ns (in nanoseconds) using > > clock_nanosleep > > + */ > > +void rt_nanosleep_until(nsec_t ns); > > + > > /* rt_nanosleep: sleep for ns nanoseconds using clock_nanosleep > > */ > > void rt_nanosleep(nsec_t ns); > > diff --git a/testcases/realtime/lib/librttest.c > > b/testcases/realtime/lib/librttest.c > > index 703d6c8..20cb7a1 100644 > > --- a/testcases/realtime/lib/librttest.c > > +++ b/testcases/realtime/lib/librttest.c > > @@ -398,6 +398,18 @@ void nsec_to_ts(nsec_t ns, struct timespec *ts) > > ts->tv_nsec = ns%NS_PER_SEC; > > } > > > > +void rt_nanosleep_until(nsec_t ns) { > > + struct timespec ts_sleep, ts_rem; > > + int rc; > > + nsec_to_ts(ns, &ts_sleep); > > + rc = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts_sleep, > > &ts_rem); > > + /* FIXME: when should we display the remainder ? */ > > + if (rc != 0) { > > + printf("WARNING: rt_nanosleep() returned early by %d s %d ns\n", > > + (int)ts_rem.tv_sec, (int)ts_rem.tv_nsec); > > + } > > +} > > + > > void rt_nanosleep(nsec_t ns) { > > struct timespec ts_sleep, ts_rem; > > int rc; > > > > There. I just inlined it using Message -> insert file. However, I think > > that > > will still word wrap the file if it is too long. So I am attaching the > > file > > as well. > > > > --Vernon > > > > > Signed-off-by: Vernon Mauery <[EMAIL PROTECTED]> > > > > > > --Vernon > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ Ltp-list mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/ltp-list > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ltp-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ltp-list ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
