Spondoolies-Tech / minepeon

Miner UI
GNU General Public License v2.0
0 stars 3 forks source link

NTP breaks cgminer #18

Open SyRenity opened 10 years ago

SyRenity commented 10 years ago

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."

zvisha commented 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 .

SyRenity commented 10 years ago

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 .

zvisha commented 10 years ago

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 .

SyRenity commented 10 years ago

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.

zvisha commented 10 years ago

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 .

SyRenity commented 10 years ago

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 .

SyRenity commented 10 years ago

@zvisha We do anything with this? (Already got complain from 1st client).