Earthling on Mars wrote:
Two or three frames have been missing from the epilogue sequence, as recorded by mscha's site, every day ever since Landing
went up. Apparently imagebot, unlike mscha's bot, is not encountering this mustard for some reason.
Oh, of course. @mscha's epilogue page
and I conversed on this issue shortly before the TymiversaryT
. At one point @mscha
seemed to be using an algorithm that makes the following assumptions:
- his computer's clock and the xkcd servers' clock are synchronized to within less than the datagram propagation time between them, and
- a single poll at precisely 0 seconds past the hour (according to the server's clock) is sufficient to get the answer from a given server for that particular hour, and
- polling multiple xkcd servers is enough to overcome any flaws in results from an individual server.
reported that one of the xkcd
servers was 7 seconds slow (see this post
and this post
). Note the first assumption implicit in his statement that "IMO: a well-configured server should always be running NTP, and thus always be within a few milliseconds of actual time"
I tried to explain that there is no way the first two assumptions could reasonably be expected to work, and invoked our shared memory of delayed ONGs during the hallowed mips of the original Revelation of Time. I explicitly suggested that You could check at :05, :15, :30, :45 and :55, and use a majority 3-out-of-5 vote to determine which frame is the correct one. @mscha
replied (by PM on 20140324) "That does make some sense"
, but pointed out that one can check the HTTP headers of the results, and from them can determine whether a server's clock is behind, thereby pointing out my first assumption above was not actually being assumed. In other words, @mscha
seemed to believe that if the time in the server's header is as expected, then the contents of the server response can be used and that's good enough. We never got as far as discussing the internal timing between the different bits of software within an xkcd
server, the distrubuted nature of the multiple xkcd
servers, and how these could cause us to still get the previous epilogue timeframe if it's only, say, 27 milliseconds past the ONG when the request is handled.
I don't like conflict so I dropped the discussion. There was also discussion of oldpixbot frequency
and the Sadness (@mscha
deliberately left the Present for a while in anticipation of it) and perhaps these distracted me from this particular @mscha
debate to engage in other more important @mscha
debates — I no longer remember.
Eventually, my response to this was to implement the imagebot
Looking at @mscha
's page now, I can see that it is still suffering from a race condition
, apparently since early November. You can see delayed letters in the Nov 17th
results, where the previous hour's epilogue frame was reported by @mscha
. (There is also a "C" at the 01:00 position on 20141118 that I still can't explain.)
I hypothesize that the implementation of the Rosetta lander xkcd
strip required a change in the software architecture that tells xkcd
servers when to deliver a new frame of a comic, and that this change exposed the vulnerability of @mscha
's assumptions in a way that the old architecture did not.
If OTTers are interested I'll aggregate the data from the various imagebot
s and make a webpage on mrob.com that shows the epilogue frames for the period I have been collecting it.
IF WE HAVE MEMEIFIED YOU FOR SOME MYSTERYONGS,T
PLEASE RE-CONFIRM THAT WE GOT ALL MYSTERYONGS WE SCHIZOBLITZED,
OR CONFIRM TO US THAT YOU WON'T MEMEIFY OUR RECKONING
WE SCHIZOBLITZED THE MYSTERYONGS FOR.
or "Timiversary" if your name is Tim.?
(It's one of BHG's Best Practices for Well-Prepared SysadminsTM
, just in case your webcomic server needs to be repurposed as a missile tracking system.)
(Edit: Fixing typos)