Weekly Updates for the GSoC 2013 New Timestamp and Library API of Chen Li

This page is the weekly updates of my project.

Sep 23, 2013 - 12th week

Done:
  • Finished all documents and test cases.

Sep 16, 2013 - 11th week

Done:
  • Finished almost all documents

Sep 9, 2013 - 11th week

Done:
  • Finished all implementation work.

Sep 2, 2013 - 10th week

Done:
  • Finished converstion between GPS timescale and any version of TZ databse(timescale)
  • Finished converstion between two IERS-A timescales.

TODO:
  • Write documents and wiki pages

Aug 26, 2013 - 9th week

Done:
  • Modify the source code of "date" to make it convert local time to any timezone
  • Modify the source code of "tzload()" in "localtime.c" to make it load different version of TZ data according to one parameter. Differernt version of TZ data will be stored in /usr/local/etc/zoneinfo/.v/(VERSION)/ .
  • Examine how TZ code modify TZ environment variable without have influence on other application. -- By change array "environ".
  • Use "time2posix()" and "posix2time()" to do conversion between UTC and GPS time.

TODO:
  • Put pieces of code together to make a integrated one.

Aug 19, 2013 - 8th week

Done:
  • Read source code and document of program in TZ code expect zic and tzfile.
  • Compile and install newest version of TZ code and TZ data, know how they work together.
  • Begin to change TZ code to make it support different version of TZ data.

Aug 12, 2013 - 7th week

Done:
  • Decide the design and implementation method of timescale conversion with harlan
  • Examine how zic work and how linux read compiled binary timezone data
  • Read source code of zic and tzfile

Aug 5, 2013 - 6th week

Done:

Jul 29, 2013 - 5th week

Done:
  • Discuss with Martin, Terje and Harlan about several cases of abnormal expected error value, such as a computer that has hibernated for a long time, or a computer that has just booted and has not talked to a trusted time source.
  • Port my work to a 64-bit kernel and test it. It seems 'clock_settime()' will call 'settimeofday()' in 32-bit kernel, that means we only need to insert some code in 'settimeofday()' and don't need to modify the 'clock_settime()'. If everything are the same in 64-bit kernel, it will be much eaiser to maintain the source code.
  • Combine all the syscalls into one, return a struct of values including the expected error, the offset and etc.

Jul 21, 2013 - 4th week

Done:
  • Add several variables in kernel to record the expected error value: last_jiffie_value and expected_error_value, the first is set to jiffies_value every time 'settimeofday()' or 'clock_settime()' is called. When user call 'get_new_timestamp()', it will read this value and jiffies from kernel, and figure out how long have passed, mulitiple it with a ratio, that is the expected_error_value.
  • Do an experiment about what will incluence the jiffies and uptime(/proc/uptime), it shows that 'clock_settime()' and 'settimeofday()' will not influence the jiffies and uptime, but adjtimex will make jiffies and uptime goes faster or slower. This may cause expected_error increase slower or faster, I don't know whether we need to take that into consideration.

Problems:
  • So far, I have added three syscalls to kernel, I don't know whether I should combine them together and make only one syscall.
    • Harlan has no idea - maybe Martin or Terje have ideas.
  • Need to determine the reference value of expected error. For example, what value will it be when the system didn't talk to a time source for a week?
    • last base error + 15 usec/sec*1 week, if you are using a full time-value for the error.
  • The value of jiffies will overflow and return to 0 when the system has been booted for 198.8 day ((2^32 -1)/250=17179869.18 seconds, it is 17179869.18/86400=198.84 days), if we create a periodic function to update the expected_error_value, it will be all right. Otherwise we have to know whether the value of jiffies has overflowed in the past. One solution is to use jiffies_64, this will not overflow in several million years, but this jiffies_64 variable is not supported by kernels under version 2.6.
    • I have no idea - that's a Linux thing. I also have no idea how this will map to other OSes.

Jul 14, 2013 - 3rd week

Done:
  • Add a counter in /kernel/time.c to increase the discontinuity counter every time 'settimeofday()' or 'clock_settime()' was called.
  • Add a new syscall to copy the value of discontinuity counter to user space
  • Add a new syscall to clear the value of discontinuity counter
  • Add a function to set offset value in timestamp

Problems:
  • Need to find a way to compile the kernel faster. It need about 1 hour to compile the kernel every time I have modified the source code

Jul 07, 2013 - 2rd week

This week is mainly used for implementation and testing of set_offset() function, and use adjtimex to gradually adjust system clock to accurate time.

If the offset time if positive, then make system clock little faster until offset decrease to 0. And make system clock slower if offset is negative. The highest speed of adjustment is 1 second per 10 second. It means that we can make system clock increase 9 or 11 second in every 10 actually second.

What's more, I have done some preparation work for discontinuity conter. There are some problem to be solved, like the source code of 'gettimeofday()' and 'settimeofday()' is difficult to locate.

Jul 01, 2013 - 1st week

In this week, I have finished the following API functions:
  • int my_gettimeofday(time_struct* ret,int CLOCK_ID);
  • int compare_timestamp(time_struct* t1, time_struct* t2);
  • time_struct subtract(time_struct* ts, f_fp* delta);
  • time_struct add(time_struct* ts, f_fp* delta);
  • f_fp get_offset(time_struct* t1, time_struct* t2);

It can be compiled into a shred library (.so) file, and can be called by other programs easily.

So far, all the code have been tested. There are several test cases, such as positive/negative offset for add/subtract function, and different cases for two timestamp argument of compare_timestamp/get_offset function.

The next period will mainly used for a module that monitoring the discontinuous of system clock(maybe more than one), in addition to offset field of timestamp.

All my previous design is for absolute clock, now we need to take relative clock into consideration, so some field and API function of this new timestamp may need to change.

I will disscuss with harlan about this.

-- ChenLi - 15 Jul 2013
Topic revision: r13 - 08 Feb 2014, HarlanStenn
 

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Network Time Foundation Community Wiki? Send feedback