Separate names with a comma.
Discussion in 'TiVo Coffee House - TiVo Discussion' started by PSU_Sudzi, Dec 20, 2017.
Thank you, sir!
The last time I saw one of my Tivo's query sjr1/2/3 was on Feb. 4. So maybe they did make a change?
How are you monitoring your TiVo traffic? Are you logging from your router?
Logging from my firewall. I just forced a call from one Tivo and it hit these four servers to set the time.
18.104.22.168 - time-a-wwv.nist.gov
22.214.171.124 - time-d-b.nist.gov
126.96.36.199 - time-a-g.nist.gov
188.8.131.52 - time-d-g.nist.gov
So it looks like Tivo has moved on from hosting their own NTP servers.
Hah!!! That's weird! Reckon they also routed their NTP server IPs to query some other server to maintain the facade? IF not, then it seems weird to change how the "call home" time update works. Their server IPs are largely responding with pretty accurate times.... mostly less than 1/2 second offset, mostly much less.
Having EVERY TiVo in the US query those servers individually instead of querying the pool is, as I understand it, bad form.
That's gonna increase traffic unnecessarily on those 4 Stratum 1 servers....
One possibility is that while making some changes to sjr1/2/3, they redirected all our units elsewhere in the meantime. As you know, a failed clock set can fail the daily call, so maybe this was a preventative measure to prevent failed calls. Or maybe this was a reactive measure, as a lot of people reported failed calls due to clock set failures. Maybe they get changed back, maybe not, we'll have to watch and see.
If they don't get swapped back in a reasonable amount of time, perhaps Ted might inquire. It really is poor form to clog up those Stratum 2 servers with unnecessary traffic.
How much traffic do you really think Tivo boxes generate? Each box hits the server once a day. While there are around 7 million subscribers, I would think MSO boxes would hit their own servers.
Even if they don’t and all boxes hit the same time servers, that’s only a few bytes per box per 26 hours each split across 4 servers. I’m pretty sure the servers can handle the traffic.
The point is that there are customs, courtesies, and rules for using the NTP system.... TiVo is not following them.
TiVo should service its own machines.
I’m pretty sure Microsoft Windows uses the nist.gov servers too or at least has an option to use them.
Yes, but the option, which few people ever know exists OR switch to is a POOL/Global address..... NOT the direct servers listed above. Specifically, time.nist.gov
NIST Internet Time Servers
3. The generic name time.nist.gov will continue to point to all of our servers on a round-robin basis, and users are encouraged to access the service using this name.
The global address time.nist.gov is resolved to all of the server addresses below in a round-robin sequence to equalize the load across all of the servers.
Whether you connect to a server using the name or the IP address, it is a bad practice to “hard-code” a particular server name or address into a device so that these parameters cannot be changed by the end user if that becomes necessary at some future time.
Yeah, they could've just used pool.ntp.org and been done with it like zillions of other devices out there. But that's Tivo, they apparently don't pay enough to get sysadmins that know their stuff. Even basic stuff like this, sadly.
NIST isn't saying that it's bad practice for end devices to use these servers. They are saying the bad practice is to hard code it where the end user can't change it if they go away or have issues (and thus better to use the general dns time.nist.gov. In our case, TiVo is managing this for us as part of our service and should fix it if any of the ones they directly specify go away.
Oh the important parts you left out from your quote of NIST's NTP page was where they *encourage* users to use the generic name (not require or insist) and the 4 second rule which our TiVo's are no where near causing an issue.
"The generic name time.nist.gov will continue to point to all of our servers on a round-robin basis, and users are encouraged to access the service using this name."
"All users should ensure that their software NEVER queries a server more frequently than once every 4 seconds. Systems that exceed this rate will be refused service. In extreme cases, systems that exceed this limit may be considered as attempting a denial-of-service attack."
We ARE the users, and the servers ARE effectively hard-coded, we DID have problems, and we DO NOT have any direct control over how time is served to OUR machines, UNLESS we perform routing trickery to fool the machines into getting time from functional servers.
Nevermind.... I'm not going to argue/explain the point with any of you any further. The quote from the NIST site is really only the tip of the iceberg.
Deal is... there doesn't always have to be a law or a set of ironclad regulations on how things should be done. Customs, practices, recommendations, and "just the right thing to do" are generally much better ways of handling things.
This will be a moot point for me soon anyway, as I will serve my own machines from my personal time server.
Have a great weekend!
Yup, didn't have time to look deeper until just now:
TIME_SVC=/bin/ntpdate -b 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124
Wow, I was late finding this thread, but it explains some odd cut-off programs lately.
And it astounds me. I've maintained NTP servers at two Fortune 500 companies. I can't think of a good excuse for what I'm seeing here.
For a corporation the size of Rovi/TiVo, $3,000 is chump change. And that's what it costs to buy a basic radio clock appliance that can easily handle serving NTP to the entire user base (7,500 NTP packets per second). You can go cheap and get a CDMA-synced clock that uses signals from Verizon and Sprint cell towers; the towers need GPS sync because of how CDMA works. Cell signals usually penetrate buildings, so there's no install cost like there is with GPS (where you have to get Facilities to run wire up to the roof).
That appliance comes with a TCX0 oscillator, which drifts 10 milliseconds a day with no CDMA signal. That means it will continue to serve stratum-1 time for 24 hours. You can upgrade it with an OCX0 oscillator and get 80 microseconds a day, for 35 days stratum-1 with no CDMA signal.
Buy three of those, install them preferably at different data centers, configure them to peer with each other and perhaps the NIST pool, and you should never have NTP issues.
But let's say they're on a real shoestring budget. $70 will buy you a Garmin GPS 18X receiver that you can solder a serial connector onto, plug into your choice of UNIX computer, and get GPS-synced Stratum 0 time. I've got one. My home NTP server is currently reliably synced within 0.007 milliseconds of "real time."
And I can't figure out how their NTP setup was losing upstream connections. The golden rule of NTP setup is the "rule of threes." When you set up an NTP server, you point it to at least three better time sources. That way, not only will one failure not take you out, but if one upstream is flaking out, the other two will "outvote" it. This is basic stuff!
Two minutes off? An offset of 100 milliseconds would be an issue anywhere I've worked. A full second would be a full red-alert, wake-everyone-up fire drill. One minute would result in at least one firing!
Somehow, this more than anything else tells me I need to make plans to move off the TiVo ecosystem after all these years, before it fails completely.
Yep, this is certainly not the only case where stuff that should be taken for granted is a Rivo fail. Guide data is #1, obviously, but this one is #2 I'd say.