Open SyRenity opened 10 years ago
We update the date from 1.1.2000 to X.X.2014. Thats more then 0.5 seconds )
On Sat, Mar 22, 2014 at 12:27 AM, SyRenity notifications@github.com wrote:
Appears as using immediate jump in time, rather then gradual.
Should be using the following mode:
"Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two."
Reply to this email directly or view it on GitHubhttps://github.com/Spondoolies-Tech/minepeon/issues/18 .
Then maybe time should be saved to write-able storage, and preserved over boots?
On Sat, Mar 22, 2014 at 12:32 AM, zvisha notifications@github.com wrote:
We update the date from 1.1.2000 to X.X.2014. Thats more then 0.5 seconds )
On Sat, Mar 22, 2014 at 12:27 AM, SyRenity notifications@github.com wrote:
Appears as using immediate jump in time, rather then gradual.
Should be using the following mode:
"Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two."
Reply to this email directly or view it on GitHub< https://github.com/Spondoolies-Tech/minepeon/issues/18> .
Reply to this email directly or view it on GitHubhttps://github.com/Spondoolies-Tech/minepeon/issues/18#issuecomment-38331243 .
Not possible, we have no clock on the board to compute difference.
On Sat, Mar 22, 2014 at 12:33 AM, SyRenity notifications@github.com wrote:
Then maybe time should be saved to write-able storage, and preserved over boots?
On Sat, Mar 22, 2014 at 12:32 AM, zvisha notifications@github.com wrote:
We update the date from 1.1.2000 to X.X.2014. Thats more then 0.5 seconds )
On Sat, Mar 22, 2014 at 12:27 AM, SyRenity notifications@github.com wrote:
Appears as using immediate jump in time, rather then gradual.
Should be using the following mode:
"Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two."
Reply to this email directly or view it on GitHub< https://github.com/Spondoolies-Tech/minepeon/issues/18> .
Reply to this email directly or view it on GitHub< https://github.com/Spondoolies-Tech/minepeon/issues/18#issuecomment-38331243
.
Reply to this email directly or view it on GitHubhttps://github.com/Spondoolies-Tech/minepeon/issues/18#issuecomment-38331352 .
Then the following possible: 1) Run ntpdate on boot, before cgminer launch, to hard-sync time to latest NTP. 2) Run ntp daemon, to continuously correct the time.
Yes. But I don't think we need the miner to know the time. I also don't think we need to remember the mining history across reboots.
This is a low priority feature.
On Sat, Mar 22, 2014 at 2:04 AM, SyRenity notifications@github.com wrote:
Then the following possible: 1) Run ntpdate on boot, before cgminer launch, to hard-sync time to latest NTP. 2) Run ntp daemon, to continuously correct the time.
Reply to this email directly or view it on GitHubhttps://github.com/Spondoolies-Tech/minepeon/issues/18#issuecomment-38336819 .
The miner uses the time to show in graphs.
On Sat, Mar 22, 2014 at 2:09 AM, zvisha notifications@github.com wrote:
Yes. But I don't think we need the miner to know the time. I also don't think we need to remember the mining history across reboots.
This is a low priority feature.
On Sat, Mar 22, 2014 at 2:04 AM, SyRenity notifications@github.com wrote:
Then the following possible: 1) Run ntpdate on boot, before cgminer launch, to hard-sync time to latest NTP. 2) Run ntp daemon, to continuously correct the time.
Reply to this email directly or view it on GitHub< https://github.com/Spondoolies-Tech/minepeon/issues/18#issuecomment-38336819
.
Reply to this email directly or view it on GitHubhttps://github.com/Spondoolies-Tech/minepeon/issues/18#issuecomment-38337035 .
@zvisha We do anything with this? (Already got complain from 1st client).
Appears as using immediate jump in time, rather then gradual.
Should be using the following mode:
"Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two."