Device time difference more than 600 seconds

[nixxonZ]

Hi, what happens if I try to sync with my friend that lives in another time zone? Is it going to work or it's gonna tell me sync stopped: device time difference more than 600 seconds?

[nixxonZ]

Never mind, I just found that in Preferences/Advanced when you set sync max time to 0 it works.

[GreatMarko]

Sync references all times back to UTC when determining which files is newer/whether files have changed or not. The "sync_max_time_diff" setting is not to account for devices in other timezones, its to account for devices that have incorrect times regardless of whatever timezone they're in.

For example, if it's 5 past a particular the hour in my timezone, and it's 5 past the corresponding hour in your timezone, yet your device's clock is incorrectly showing it as 25 minutes past the hour, Sync will fail (as the difference between 5 past the hour and 25 past the hour is greater than 600 seconds)

[JuRist]

I have the same problem, but is it a good solution, to set sync max time to 0? Could it be, that then correct syncing is not assured?

[Harold Feit]

The correct solution is to fix your system clock and timezone information so that it's correct.

[JuRist]

You are right, that was it! On the NAS was a wrong time. Now it runs!

[HerrimanCoder]

This device time difference message is bogus. I have 2 servers in different datacenters. I have verified their system clocks are within 5 seconds of each other. Both same time zone and nearly identical time. Yet this error message continuously appears. I had to go change the setting to 0 as stated by others, in order for it to work.

 

Is this a bug in bittorrent? Why does it think the devices have different time settings when in fact they do not?

[GreatMarko]

This device time difference message is bogus. I have 2 servers in different datacenters. I have verified their system clocks are within 5 seconds of each other. Both same time zone and nearly identical time. Yet this error message continuously appears. I had to go change the setting to 0 as stated by others, in order for it to work.

 

Is this a bug in bittorrent? Why does it think the devices have different time settings when in fact they do not?

 

It may seem a silly/obvious question, but even though you've checked the times are the same - are the dates on your two servers also the same?

 

Have you synced both devices to the same NTP time server, just to make sure?

[stanha]

Well, I can verify that there seems to be something funky going on with device time difference too great message.

But it is too funky to describe in one sentence or less.

[Firon]

If your date is wrong, then unix time will be wrong too.

[HerrimanCoder]

The date on each server is identical. I just double-checked to be sure I wasn't being stupid. March 19, 2014 @ 1:47 PM Mountain Time. Both servers. Still no explanation.

 

I say it's a bug in BitTorrent.

 

It's working for me because I set sync_max_time_diff to 0...but I'm nervous that this approach could have unwanted side effects.

[stanha]

The date on each server is identical. I just double-checked to be sure I wasn't being stupid. March 19, 2014 @ 1:47 PM Mountain Time. Both servers. Still no explanation.

I say it's a bug in BitTorrent.

It's working for me because I set sync_max_time_diff to 0...but I'm nervous that this approach could have unwanted side effects.

This is certainly something I'd like to know for sure.

On which node did you set max_time_diff 0? Only on the node that would refuse to sync? Or on a master (r/w) node as well?

- No point in barking up the wrong tree.

[RomanZ]

HerrimanCoder,

 

I know no other errors that bring the same message. It is either time difference, or the timezone difference. Could you please collect debug logs from either of affected peers?

 

It contains the time value for local and remote peer, so I can decode it and let you know which of peers looks to be problematic.

 

BTW, you can also check how GMT looks like on your servers from console. Just run "date -u" in terminal for Mac and Linux or "for /f %%x in ('wmic path win32_utctime get /format:list ^| findstr "="') do set %%x" for windows (in Win you might need to put it in batch file).

[stanha]

Here is my log file [...]

It is not longer relevant.

[stanha]

Reliance on clock time

First of all, the amount of views of this thread is 3,787. This, by itself, indicates that this issue if one of the most important issues of all.

In my personal opinion, it has to be placed as the priority 1 item on the priority list and, as soon as it is resolved so it no longer affects a significant number of people, a new release needs to be made, regardless of all other issues that are resolved or are in semi-resolved state.

It would be great to see a new version within the next few days. That is how critical this issue seems to me personally.

But, hey, everyone has freedom to do what they please in this world...

Here is the most detailed reasoning I could come up with on this subject:

Well, I am seeing somewhere around 30% of people that can not start syncing because of this "time is off by more than 600 seconds" message.

And that is no longer simply a matter of joke or stupidity on the part of users. It seems that current approach is fundamentally incorrect, at least if it causes such severe problems.

May be it would be better to keep the same logic but to sample the current time on both nodes and offset the accounting for the potential time difference by the value of their clock difference. The clock difference is a matter of pragmatic fact, and not of a theory of "perfect world" where everything is synced to atomic clock and time zones are set correctly.

In my case, currently there are 2 nodes that can not sync, and for DAYS, sitting on this share.

In one case, their clock seems to be exactly +1 hr. and 19 seconds off, and on the second node -1:05:09 (HH:MM:SS). So, it seems their time zones are off by one hour and in the second case, the time is off by additional 5 mins 9 secs.

As I mentioned before, I have displayed a message in my device name about setting the time correctly, and, strangely enough, there seems to be no change. I am not sure they are so dumb that they can not see the message with the URL pointing them to the document describing this issue.

But the fundamental question is: why can't the sync, at least initially?

Secondly, how much significance and impact the incorrectly set time may have on the overall state of data compared to total refusal to sync?

Even if time is off by and hour, or even several hours, what is the statistical chance that there will be a significant negative impact on the state of the data set?

If one file happens to have been updated and it happens to be that the update was done within the time of clock difference, the chance of which is pretty much close to 0, and it happens that you download or upload the older version of it to the node that has its time set incorrectly, what seems to be the problem, at least in comparison to total refusal to sync the entire data set?

Yes, theoretically, it is a problem, because the older file version may get downloaded to the node that has its time set incorrectly and step on a newer version that exists in other r/o nodes. But, even in that case, they still have the the archives.

- Well, statistically speaking, one or few more files might be potentially affected, but ONLY if there is no r/w node on-line and the other r/o nodes think that your version is older than theirs and so they do not want do download your version of the file.

But what impact does it have on the entire data set compared to total refusal to sync ANYTHING, just because in SOME cases your clock difference may affect a single file?

Does it make ANY sense, logically speaking?

Ok, fine, you might have some argument. But then, even if your argument is really valid, you do not download or propagate ONLY files that fall within the range of the time difference between the nodes, that is, if you find ANY of such files. Most likely, their number will be 0. But all other files that have their time stamp outside the range of clock mismatch must not be affected.

There needs to be an estimation of comparative tradeoffs you have to pay for such severe measure as not syncing the entire data set.

What are the ADVANTAGES of refusing to sync, even if some file is off by an hour or so, and it happens to be the file that has been updated on one of the nodes?

The statistical chance of such a coincidence is probably on the order of 0.0001%, in the BEST case. But the probability that you will affect the entire data set or significant part of it rapidly approaches 100%.

So, what is your payback for this "feature"?

Does it make sense?

May be the very idea of "file stamp is in the future" because of the time zone differences need to be reexamined or the very mechanism of relying on the file time stamp differences has to be looked at.

At least one of the nodes I have described above should sync. Because its time is not in the future, but in the past from what the r/w node thinks it should be.

Otherwise, the net effect would be equivalent to you not being able to do the FTP transfer to the site, which has a "newer" version of the file and it might look like you are making some mistake. And even if you do, at least you should be prompted with a message "do you really want to do this" or something of that kind.

As I understand this issue, the time stamp seems to be utterly irrelevant. Because the hash of the file CONTENTS is used. In this case, no matter whether some file has the time stamp in the future or in the past, it seems to be not as relevant as the file contents.

One of the main rules of logic, as I understand it at the moment, ALL the nodes have to have EXACTLY the same contents as the master (r/w) nodes, regardless of anything. Otherwise there is a database consistency issue.

Yes, if there is no r/w nodes currently on line and files on both ends have different contents and different time stamps then the assumption is made that the fresher file "wins". But then, if there is clock difference between the nodes, it needs to be accounted for in order to find out which version is newer.

It does not seem to make much sense to prevent the syncing of the entire collection because of such things, at least during the INITIAL sync, which should be allowed unconditionally, no matter what, at least if there is an r/w node present on-line, it seems.

I just hope this issue gets resolved, and pretty soon. Because I see these errors every day, morning to night and on several different shares. And I am not sure how many people had to eventually give up and leave the share, which is considered to be something very undesirable in our situation.

This does not make any sense to me. There seems to be something fundamentally wrong somewhere, unless we are simply dealing with some plain bug.

[GreatMarko]

First of all, the amount of views of this thread is 3,787. This, by itself, indicates that this issue if one of the most important issues of all.

In my personal opinion, it has to be placed as the priority 1 item on the priority list and, as soon as it is resolved so it no longer affects a significant number of people,

It would be great to see a new version within the next few days. That is how critical this issue seems to me personally.

I am seeing somewhere around 30% of people that can not start syncing because of this "time is off by more than 600 seconds" message.

Where are you arriving at a figure of your issue affecting "30% of users"!?? Other than yourself, only one other user has commented in this thread since July last year that they have that they have experienced this issue - don't forget, this thread is over 8 months old now - of course it's going to have had a few thousand views in that period of time!! - it doesn't mean that 3,787 people have all encountered this issue!!

 

Now, don't get me wrong, I'm not dismissing your issue or saying you've not encountered it - but I think your perception of the scale of this is massively overestimated!

 

I appreciate your frustration, but If, as others have suggested in this thread checking, you believe your device clocks to all be correct, and yet you still encounter this issue, then please follow the instructions here for reporting your issue. The developers can then review your report/logs and will respond accordingly.

[stanha]

Where are you arriving at a figure of your issue affecting "30% of users"!??

As to the number of messages on this thread, sorry, I am not quite concerned as to the density of reply messages vs. total messages during given span of time. Secondly, the sheer fact that you see not many replies on this thread is not a meaningful parameter to me. Because if I see a thread with the same exact problem I have, it does not mean I have to POST on that thread just to say the same thing they are saying. Some people may not post just because they may feel shy or afraid to look "stupid", and this is a fact to me, not a theory.

But the very fact that 15 people a day read this thread means that some of them, if not many, keep reading it again and again. Why, if the problems has no significance as you seem to imply here?

Fortunately or unfortunately, but I am a troubleshooter by profession and about all I do quite often is to identify the problem and then solve it. So the system is stable, predictable and clean. And that is what they pay me for.

So, there is no such a concept as "small problems" in my mind. It is all a matter of tradeoffs and priorities.

I have learned with time to never ever ignore ANY kind of problem or a bug, just for the sake of adding more and more features while old features do not quite work "under some unusual conditions".

To me, about the most important criteria for any s/w product is robustness and the most detailed and precise documentation. But the features and "bells and whistles" can wait. The program should behave like a tank under any and all conditions, usual, "unusual", conceivable or not. That is priority number one in my book.

Burying your head in the sand do not just quite cut it in the s/w business. That is probably the toughest business to be in, and especially in the Silicon Valley. And that is the context I am talking about.

In today's world of high standards of quality and robustness, any kinds of problems just do not fly. It is much easier to turn off the people from your product then to get their initial interest, and once that happens, you lost "the customer" forever.

As to "Where are you arriving at a figure", I get it from elementary statistics of the number of people that I am seeing on this share and other shares as well compared to the number of nodes that have the error message. As I said, I am seeing this message every day. Why? - I have no idea.

Now, don't get me wrong, I'm not dismissing your issue or saying you've not encountered it - but I think your perception of the scale of this is massively overestimated!

It depends on which specific facts you base your judgement on.

How do you arrive at the "MASSIVELY overestimated" qualification of the issue?

Do you have statistics to prove something?

Have you run the public polls?

Can you place your particular judgement on relative importance of such an issue in other cases or applications?

I appreciate your frustration,

I am sure you are!

And I also appreciate your appreciation and compassion and I hope you appreciate my appreciation as well.

And I hope you appreciate the fact that in our particular case, seeing a number of people that had to eventually abandon the share because they could not even start syncing, is a critical issue in our case, if you do not mind, even from the standpoint of an image it creates in people's minds. Because we are dealing with the issues of utmost importance and urgency on a scale, I am not sure you can sufficiently appreciate, if you are not aware of the issues. But that is a matter of subjective judgement.

And I hope there is a reason for you to post or even bother about such an insignificant issue, as you seem to present it. Why bother?

Do you have a SOLUTION that I do not know about, that can make those error messages go away in a general public situation?

but If, as others have suggested in this thread checking, you believe your device clocks to all be correct,

I can not check the correctness of time or time zone set on other nodes. Because it is a general public situation. All I can see is my BTSync logs reporting time difference.

and yet you still encounter this issue, then please follow the instructions here for reporting your issue. The developers can then review your report/logs and will respond accordingly.

Thanks for the link.

I did exactly what you have proposed, and thank you for your idea.

I am kind of curious at this point to see their response if any, especially in the context of their claim that "Having right problem description and logs will mean that your problem will be fixed in a matter of hours." (the original bold font is preserved).

I'd LOVE to see that fixed "in a matter of hours". That might make me LOVE BTSync and never part with it even if some other guys develop something even better, unless of course it will be an Open Source solution, in which case I'd prolly say: "see ya later, aligater".

But the idea of BTSync is great. I have to admit.

And it arrived just in time in the context of global events.

In my personal opinion, there is probably no s/w product at this moment that is as significant as sync on p2p basis, especially with reliable and trustable security arrangements. Because at this point, the global and uninterrupted and reliable information exchange is probably the most critical issue of all. I hope you don't mind this qualification.

[stanha]

Strange behavior with time difference error message and syncing

There is no point for reasoning on the issue that is considered as user error.

[RomanZ]

stanha,

 

the timediff in the log looks to be 1 hour. I suggest trying command lines that I've supplied to see what is the UTC time on both your peers. It is likely to reveal the issue.

 

Gents,

I would ask you to stop arguing about severity of the case. Sync Team does it's best to:

1) Cover the most severe issues ASAP

2) Cover as much usability issues as possible

[stanha]

stanha,

the timediff in the log looks to be 1 hour. I suggest trying command lines that I've supplied to see what is the UTC time on both your peers. It is likely to reveal the issue.

Because it a DLS time adjustment issue.

[stanha]

Well, unfortunately, it looks to me that this issues is not being handled in the appropriate manner, but is simply talked away, like it does not exist ...

Well, "tough". No point to provide any reasoning.

[Harold Feit]

stanha: A suggestion to try: change the timezone on all your computers to GMT.

It could be that one of your computers (more likely the mac) has incorrect daylight savings information in its operating system core.

http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_saving_time

[stanha]

stanha: A suggestion to try: change the timezone on all your computers to GMT.

It could be that one of your computers (more likely the mac) has incorrect daylight savings information in its operating system core.

http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_saving_time

Hi Harold,

Thanks for suggestion. Unfortunately, this is a general public situation. I have no way of controlling general public. And I have no way of communicating with the nodes, at least as it stands now.

Since vast majority of users use BTSync in private setting, general public issues have no relevance.

Therefore...

[stanha]

Issue update #6

Right now I have a new node trying to sync.

His time in r/w node log shows -3607, so he wouldn't start syncing.

- Timediff is not a priority item and is considered to be user error.

[RomanZ]

stanha

 

1) It is not very good idea to start switching time \ timezones. BTSync assumes that time always goes forward and it's behavior is undefined if time suddenly leaps back. So it is highly not recommended.

2) So far in this topic I see 2 issues:

 - incorrectly set timezone for user machines (regardless of the reasons which brought PC to such state)

 - Inability to communicate verbally to other peers.

 

For the timezone issue: we are aware of it and will see how can we help users with that. For immediate solution I consider running a command from the console, which displays current UTC time and comparing it to another PC which can't be synced.

 

Just run "date -u" in terminal for Mac and Linux or "for /f %%x in ('wmic path win32_utctime get /format:list ^| findstr "="') do set %%x" for windows (in Win you might need to put it in batch file).

 

 

For the inability to communicate: this is already in wishlist. We'll consider it for future releases.