While the drop in Iranian exports is certainly a sum of many things, the article completely fails to mention the EU sanctions. Notice the very sharp drop in the export volume graph mid-2012? That's the sanctions coming fully to force in July 2012: http://en.wikipedia.org/wiki/European_Union_sanctions_against_Iran#Sanctions

I'd beg to differ by saying it was in a way both human error and faulty design. Essentially the reactor design requires power to keep cool even after shutdown. So far so good. The backup power source (in addition to batteries) was however limited to only two diesel generators, which were unoperational (due to flooding, most likely). This poor backup power redundancy has been noted internationally by several atomic energy safety organizations, and their Japanese counterparts / plant operators were warned years ago. In addition to reactor core cooling power would have presumably been needed also for hydrogen-oxygen recombiners to avoid the hydrogen explosions.

So from how I see it, the current situation is caused by insufficient contingency planning, probably in order to achieve some cost savings. It would have been rather reasonable to make sure that there is backup power available even in the case that some generators get swamped. All in all the wikipedia page (and assurances) about BWR safety features seem to be in stark contrast with the reality at Fukushima.

It's easily possible to do better than random: just decide what would your natural throw at a given point, and then actually do the throw that feels worst to you. With a quick test it seemed to work, got something like 5:4 win ratio with lots of ties too.

Replying to a bygone thread, but here it goes:

Out of your four points only the last one is valid. Your document reference is old, and does not take into account the IEEE1588v2 standard released in 2008. PTPv2 can indeed reach good accuracies over WAN, can be used in unicast mode, can form clock hierarchies with multiple atomic (or equivalent) clocks and has security extensions.

For further info you could read the IEEE 1588-2008 standard, it's relatively readable as far as standards go.

In addition to NTP, there's also IEEE 1588. All of these "clock synch over packet switched network" mechanisms are pretty similar, the differences are mainly in the timestamp filtering and processing. NTP details the algorithms, IEEE 1588 leaves them open to implementation and RADClock has its own algorithms (details unknown at least to me).

This story is also a bit dupeish, as RADClock has been recently featured here. Thus I'll copypaste the relevant parts from my previous reply:
--
(disclaimer: just finished my Master's thesis on a related subject) About the 1588 in general: its main selling point is the ability to do hardware timestamping (when using hardware with support!) of the two-way timing messages between master and slave. This eliminates the very significant timing jitter that happens in the software stack before the messages are timestamped. For reference, commercially available master-slave implementations using IEEE 1588 achieve synchronisation within tens of nanoseconds within LAN, and microseconds to tens of microseconds within WAN, depending on network conditions.

So overall I think that while RADclock might be ok as an alternative between NTP and IEEE 1588, it doesn't really bring anything new to the table. Some of the stuff in the Rideaux/Veitch paper has also been used with IEEE 1588 for quite some time, for instance the filtering for fast timing packets is a necessity for accurate synchronisation with IEEE 1588.
--

Like the sibling post says, there's no need to have very high quality oscillators anywhere in the system. A GPS-synched grandmaster with an OCXO should have pretty good holdover properties in case it loses the GPS signal for some time (hours-days).

The slaves can also have OCXOs to enable long time periods for filtering and whatever clever averaging algorithms the slave happens to use to recover the clock after it has been degraded in transit. It's interesting to note that contrary to NTP, IEEE 1588 does not define the clock recovery algorithms, so they are typically proprietary in commercial products.

(disclaimer: just finished my Master's thesis on a related subject) PTPd is ok, but not in itself up-to-date at the moment. It doesn't implement the most recent IEEE 1588-2008 standard, which has significant improvements compared to the 1588-2002. About the 1588 in general: its main selling point is the ability to do hardware timestamping (when using hardware with support!) of the two-way timing messages between master and slave. This eliminates the very significant timing jitter that happens in the software stack before the messages are timestamped. For reference, commercially available master-slave implementations using IEEE 1588 achieve synchronisation within tens of nanoseconds within LAN, and microseconds to tens of microseconds within WAN, depending on network conditions. So overall I think that while RADclock might be ok as an alternative between NTP and IEEE 1588, it doesn't really bring anything new to the table. Some of the stuff in the Rideaux/Veitch paper has also been used with IEEE 1588 for quite some time, for instance the filtering for fast timing packets is a necessity for accurate synchronisation with IEEE 1588.

Yeah, it sure does have a nice GUI for dual screen configuring. That nice utility also doesn't recognise my second monitor at all which makes the whole point kind of moot for me. The available refresh rates for the only monitor are 50Hz and 53Hz which results in some nice tearing when moving windows around. nvidia-settings (I'm using the restricted drivers for my 8800) does recognize the second monitor and has the correct refresh rates available but the settings don't stick. Overall I'm still sticking with WinXP + UltraMon which is a really nice setup for dual monitor use. I'd rather do something useful with the time that would be spent mucking with problematic dual monitor support in Gutsy.