Hi Stefan,

When you say RTC is too slow, what drift did you perceived?

I may add this to the topic. I tried something similiar to measure performance.

First i was a bit irritated that i only get values which are different by one million units, until i looked at the code. https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/rtc/x8... , line 218 return mktime(day, mon, year, hour, min, sec) * 1000000ULL; -> this only returns something which looks like a timestamp, but has no milliseconds at all.

The second thing is the timing. Using the RDTSC call from https://github.com/genodelabs/genode/blob/master/repos/os/include/x86_64/tra... I tried the following time1 = timestamp(); msleep(1000) time2= timestamp(); which showed that a second of wait is quite equal to the number of time cycles.

Then i tried to emasure the rtc call. time1 = timestamp(); sometestvariable = rtc.get_current_time(); time2= timestamp();

Funnilly this seems to take 0.995 seconds.

So RDTSC seems to be better for perf. measurements.... if and only if you have a fixed processor speed (and a x86 compatible which is not from cyrix, and you always take the same cpu, and...). On modern processors if speed steps are used the rate of ticks is not constant (e.g. due to power saving measures triggered by BIOS). Also if you have multiple processors you will always need to look up the corresponding processor. Some newer intel processors return the TSC always according to the fastest possible processor speed (which is fine).

There are more problems doing measurements with TSC. Because of this, microsoft for example gives the advice to never use the TSC and use methods from the windows api. Also in POSIX RDTSC should not be used, but clock_gettime(). So also on linux you should not use TSC but clock_gettime() / CLOCK_MONOTONIC.

Maybe something to think about in future releases of Genode.

Best regards, Wolfgang

-----Ursprüngliche Nachricht----- From: Stefan Kalkowski Sent: Thursday, October 23, 2014 11:31 AM To: genode-main@lists.sourceforge.net Subject: Re: Is there any method to obtain real-world date and time in Genode?

Hello,

On 10/21/2014 07:33 PM, 王硕 wrote:

Dear Norman and all Genodians,

the Genode OS framework is neither Norman's exclusive project, nor limited to the team working at Genode Labs, but at least meant as an open source community project. Although, Norman and the team at Genode Labs have the greatest influence on the project, and are mostly competent contacts, with this mailing list you address *all* Genode developers and enthusiasts. So _please_: avoid addressing people personally in the first place.

I want to obtain‍ real-world date and time in Genode (base-foc), so would you like to tell me how to achieve it. Rtc is too slow, and Rdtsc‍ can't obtain real time.

When you say RTC is too slow, what drift did you perceived?

Joking apart, your problem is a basic problem in computer science not limited, or special with respect to Genode. I assume with "RTC is too slow" you meant that reading the RTC every time you need a timestamp is to expensive. If you look at existent systems like for instance Linux, the problem is solved in the following way: Calendar time is read exactly once while booting, and stored in a variable. From that on another less expensive system timer is used to add periodically wall-clock time to the initial time-stamp.

To break it down to your problem:

* Initially read the RTC time, as well as the RDTSC * Whenever you want to read the current time, read the RDTSC, and add the difference between the actual and the last RDTSC value to your stored calendar time, and you are done

Regards Stefan

---

Shuo Wang, University of Chinese Academy of Sciences.

---

Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho

---

genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hello,

let me add that there is a middle ground between using the RTC driver and the time-stamp counter (TSC), namely the 'Timer::Session::elapsed_ms' function. This function returns the number of milliseconds since timer session was created. By combining it with the RTC driver, the expensive call to the RTC driver could be done at high intervals only. In between, the less expensive 'elapsed_ms' function could be used to obtain time durations at a finer granularity. Still, 'elapsed_ms' does not come for free because it involves an RPC to the timer service.

Ideally, a get-time function would be a mix of the different facilities. The RTC to obtain the coarse time of the day and date, the TSC for high accuracy in the order of microseconds and the 'elapsed_ms' function for accuracy in the order of milliseconds.

It is true that the TSC frequency may depend on the clock speed, speed stepping, power savings etc. For this reason, the TSC values cannot be used as is but they must be calibrated. E.g., the timer service can be used to determine the ratio of TSC values per second. To account for TSC frequency changes during runtime, the ratio could be updated at certain intervals.

As of now, the libc does not provide a convenient function that combines the different facilities for you. But the instruments outlined above should principally enable you to construct a highly accurate get-time function with very little overhead in the TSC-based common case when neither 'Timer::Session::elapsed_ms' nor the RTC is called.

Best regards Norman