1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Clock off in Roamio by 2 minutes

Discussion in 'TiVo Coffee House - TiVo Discussion' started by PSU_Sudzi, Dec 20, 2017.

  1. NorthAlabama

    NorthAlabama tabasco rules

    7,953
    1,056
    Apr 19, 2012
    sweet home, al
    yeah, it's been drifting all weekend. the weirdest part is my sat & sun connections are both overnight, and my tivo clock has remained within 2-4sec, so i'm wondering how i've avoided hitting sjr1. :confused:
     
  2. sakaike

    sakaike Member

    54
    10
    Jan 22, 2002
    Huntington...
    Just out of curiosity, for those folks who are apparently very knowledgeable on this topic, is there a reason why the drift is always in the faster direction? Just wondering...
     
  3. Feb 1, 2018 #303 of 362
    JoeKustra

    JoeKustra in the other Alabama TCF Club

    12,360
    1,616
    Dec 7, 2012
    Ashland, PA...
    Curious. Just forced a service connection on two Roamio boxes. One Hydra. Both failed the first time with a C125 error. I hit select and it showed that ports 123 and 37 were blocked. As if. That happened during the clock set. I went to network troubleshooting, saw both passive tests pass and ran a connection diagnostic. No errors. Went back and reran the service connection and it passed. Perhaps someone is working on the time servers?

    I also applied power to my Mini VOX but forgot to connect the internet. Time was off by 8 hours. Only three days without power.
     
  4. Feb 2, 2018 #304 of 362
    burdellgp

    burdellgp Member

    84
    11
    Mar 27, 2008
    Huntsville, AL
    Only way to know for sure is to know why they are not keeping in sync to begin with. In the past, certain combinations of virtualization servers and guest OSes would cause the clock to tick too often in VMs, so they'd always run fast. I don't know that that's the issue with TiVo's NTP servers (since I thought all such combinations were past end of life at this point). I can't say I've tried to run NTP servers for a large number of clients, but I can't think how I'd set up an NTP server that would act bad the same as TiVo's servers.

    Right now, all three server are completely unsynced (stratum 16):

    $ ntpdate -qv sjr{1..3}.tivo.com
    2 Feb 18:08:28 ntpdate[16728]: ntpdate 4.2.6p5@1.2349-o Thu Oct 26 10:57:33 UTC 2017 (1)
    server 204.176.49.10, stratum 16, offset 1.051599, delay 0.09825
    server 204.176.49.11, stratum 16, offset 0.297541, delay 0.09828
    server 204.176.49.12, stratum 16, offset 0.412517, delay 0.09866
     
  5. Feb 3, 2018 #305 of 362
    morac

    morac Cat God

    10,503
    352
    Mar 14, 2003
    NJ
    I found this thread by accident as I haven’t really noticed a problem on my boxes, but figured I’d try and block sjr1 on my ASUS router running Merlin, but apparently there is a bug in the network filtering service code which causes blacklisting to not work. I could manually add an iptable entry to block sjr1, but that’s kind of a pain to do, so I just left it alone as I have never noticed a problem. Maybe a second or so of. I usually pad everything a minute which works unless I hit the long time padding bug where it doesn’t pad back to back recordings.

    My boxes tend to make connections early in the morning (EST) or early afternoon (like 1:34 pm today). I wonder if that’s why. Hopefully this issue gets fixed though so I don’t have to bother. For what it’s worth sjr1 is only 2.5 seconds off.

    Is there any reason Tivo runs it’s own ntp servers? Also hard coded ip addresses is a bad idea.
     
  6. Feb 3, 2018 #306 of 362
    kdmorse

    kdmorse Well-Known Member

    5,825
    429
    Jan 29, 2001
    Germantown, MD
    On the one hand, the band-aid measures they put in place to keep it from drifting beyond +5 seconds fast, have been working since Monday the 29th. So units shouldn't be ending up wildly off like they were.

    On the other hard, the root problem clearly still remains. sjr1 still likes to march inexorably upwards, until something thumps it. Deviations beyond 1 second are the norm, as is responses of stratum 6 or 16. And all three of them continue to be dreadful ntp servers.

    I'm sure it made sense at the time. You release a product that is absolutely reliant on having a decent clock. It has no internet access, only having any sort of network access during a short daily call using a modem. Open NTP servers are not plentiful, the few that exist frequently change names, ip addresses, or access policies - are rate limited, frequently block abusive users, and specifically say something like "don't point all your users at me, you run a ntp server, you talk to me, point all your users at you". Pointing at other ntp servers also has a trust risk, as you trust them to keep your entire product base sane, and bear the brunt if something outside of your control goes wrong. (One popular ntp server decided it didn't want to foot the bill for the bandwith of serving everyone who didn't read it's terms of service, and just reset it's date to 1980 or somesuch one time). You only get one shot a day, so you have to talk to something you can trust. Finding a reliable open NTP server in 1999 was not an easy task.

    So it made perfect sense to:

    1. Run your own NTP servers
    2. Care for them yourself, ensure that they're accurate.
    3. Point your user base at them.

    Somewhere along the line, they kinda lost track of step #2...

    Now, the world has changed a lot in the past 18 years. But a lot of the daily call methodology hasn't, it still runs along pretty much the same script it has for the last 18 years, with a few changes here and there, but no major architecture changes...

    And the basic idea is still a decent one. Assuming, you know, you actually "run" your ntp servers, not just shove them in the corner and neglect them for years.

    I'm sure this too has legacy reasons. In order to keep it light, the original Tivo linux kernel had every function they didn't need ripped out - and this included name resolution. (This is the reason you had to put a -n on almost all commands, as any attempt to resolve a name would segfault. You had to netstat -r -n, because just netstat -r would crash). So *everything* the box did was by ip address. Much of that has changed over time, but since there was no reason to touch the clock set code, nobody did...

    I'm not saying any of these are *good* reasons. But they're plausible legacy reasons. Were you designing a box today, you'd do things far differently across the board. The vast majority of the Daily Call process is exceedingly archaic by todays standards.
     
    minimeh, sakaike, PSU_Sudzi and 6 others like this.
  7. Feb 4, 2018 #307 of 362
    JoeKustra

    JoeKustra in the other Alabama TCF Club

    12,360
    1,616
    Dec 7, 2012
    Ashland, PA...
    How guide updates are scheduled ->Daily Guide Updates
     
  8. Feb 4, 2018 #308 of 362
    slowbiscuit

    slowbiscuit FUBAR

    4,076
    257
    Sep 19, 2006
    In the ATL
    Yeah I posted this earlier, all you have to do is update Merlin to latest rev which fixes the filter bug. I have blocked both sjr1 and 2 in my router w/Merlin.
     
  9. Feb 4, 2018 #309 of 362
    morac

    morac Cat God

    10,503
    352
    Mar 14, 2003
    NJ
    I’m running 382.1_2, which is the latest non-Beta, and it’s definitely not working on my AC88U. I confirmed this by checking the iptables and seeing that the rules being added by filtering are using a “RETURN” rule, rather than a “DROP” rule, which results in the connections being allowed.

    I dug into the code base and found what I believe the offending code, but so far Merlin is ignoring my bug reports. Blacklisting via Network Services Filter isn't working

    My only work around is to set up my own rule using scripting which is more trouble than it’s worth at this point.
     
  10. Feb 4, 2018 #310 of 362
    DBrunetti

    DBrunetti Member

    85
    21
    Dec 6, 2016
    Connecticut
    Having trouble completing a service connection. Fails on setting clock. First instance was during the night.
     
  11. Feb 4, 2018 #311 of 362
    Rob Helmerichs

    Rob Helmerichs I am Groot! TCF Club

    43,604
    2,658
    Oct 17, 2000
    Minneapolis
    Mine insists that it can't get through my firewall, even though I haven't changed anything.
     
    DBrunetti likes this.
  12. Feb 4, 2018 #312 of 362
    DBrunetti

    DBrunetti Member

    85
    21
    Dec 6, 2016
    Connecticut
    I’m seeing the same message.
     
  13. Feb 4, 2018 #313 of 362
    JoeKustra

    JoeKustra in the other Alabama TCF Club

    12,360
    1,616
    Dec 7, 2012
    Ashland, PA...
    Oh thank God. I've just power cycled my entire network and it still dies on getting time. So it's not me or my router. I was just about to call my ISP.

    BTW, I checked my event log which shows a good connection on 52:179:17:38:123 when I force a windows time update.

    The Port test passes but the network diagnostics fail with a C125.
     
    DBrunetti likes this.
  14. Feb 4, 2018 #314 of 362
    NorthAlabama

    NorthAlabama tabasco rules

    7,953
    1,056
    Apr 19, 2012
    sweet home, al
    my tivo successfully connected this morning about 8am (4 hours later than usual), tcp port and dns tests report "succeeded", but i'm not testing my connection for fear of a failure! :D
     
  15. Feb 4, 2018 #315 of 362
    JoeKustra

    JoeKustra in the other Alabama TCF Club

    12,360
    1,616
    Dec 7, 2012
    Ashland, PA...
    It won't hurt. Just run the Network Diagnostics. No need to do a Service Connection to get the error.

    I think it's fixed.
     
  16. Feb 4, 2018 #316 of 362
    NorthAlabama

    NorthAlabama tabasco rules

    7,953
    1,056
    Apr 19, 2012
    sweet home, al
    it appears so, test connection completed, no errors. ;)
     
  17. Feb 4, 2018 #317 of 362
    Rob Helmerichs

    Rob Helmerichs I am Groot! TCF Club

    43,604
    2,658
    Oct 17, 2000
    Minneapolis
    I just successfully connected (and got another day's data).
     
  18. Feb 4, 2018 #318 of 362
    DBrunetti

    DBrunetti Member

    85
    21
    Dec 6, 2016
    Connecticut
    Yes. Seems to be working again. Tried on Roamio and Mini. Both connected successfully.
     
  19. Feb 4, 2018 #319 of 362
    slowbiscuit

    slowbiscuit FUBAR

    4,076
    257
    Sep 19, 2006
    In the ATL
    *shrug* working fine on my RT-AC86U w/380.69. Confirmed by running w32tm to check NTP blocking per this thread. It did not work until I updated to this rev.
     
  20. Feb 4, 2018 #320 of 362
    ClearToLand

    ClearToLand Old !*#$% Tinkerer!

    988
    134
    Jul 9, 2001
    Central Jersey
    Stratum 2 is something new. sjr1 *WAS* also Stratum 2 a few minutes ago and just changed to 'local clock':
    Code:
    C:\!Util\BAT>w32tm /monitor /computers:sjr1.tivo.com,sjr2.tivo.com,sjr3.tivo.com
    
    sjr1.tivo.com[204.176.49.10:123]:
        ICMP: 68ms delay
        NTP: +0.1731436s offset from local clock
            RefID: 'STEP' [0x50455453]
            Stratum: 0
    sjr2.tivo.com[204.176.49.11:123]:
        ICMP: 67ms delay
        NTP: +0.0530219s offset from local clock
            RefID: time3.apple.com [17.254.0.31]
            Stratum: 2
    sjr3.tivo.com[204.176.49.12:123]:
        ICMP: 68ms delay
        NTP: +0.1251091s offset from local clock
            RefID: time3.apple.com [17.254.0.31]
            Stratum: 2
     

Share This Page