You mean 200%. Electricity costs in the UK are $0.06/kWh in bulk.
Offshore wind has a breakeven price of $0.25/kWh.
Things may change in time, and I wouldn't suggest withdrawal of subsidies until we see the potentials and unavoidable drawbacks of the technology. However, to illustrate the point, the UK government recently announced a plan to cut the offshore wind guaranteed purchase price to $0.24/kWh and suddenly a whole bunch of investors threatened to pull out of projects, so the govt backtracked.
A major reason Germany can cope with large amounts of renewables, are because its grid is tightly tied to numerous neighbouring countries. Effectively, the whole of continental Western Europe is tightly interconnected and synchronised.
This allows Germany to use imports/exports to help absorb fluctuations in wind supply outturn. Germany have also been shutting down slow responsing nuclear plants and replacing them with coal and gas turbine plants which are faster to respond.
However, the UK has had significant problems with grid stability after the establishment of a large amount of wind energy. National grid have already increased the maximum allowable "rate of change of frequency" (ROCOF) to 1 Hz/s, because their previous operational limit of 0.1 Hz/s was being continually exceeded due to wind variability. For interconnected systems which depend on ROCOF to detect grid failure (e.g. small scale generation - combined heat power schemes, rooftop solar PV, small scale wind), the previous operational limit was being exceeded frequently enough to result in various "chain reaction" type events. For example, a thermal power plant trips out, causing frequency to fall at a significant but not critical rate - at the same time a random variation in wind output results in a temporary loss of output. Together, this is sufficient to trigger ROCOF protection on embedded generators, causing them to trip off, suddenly withdrawing supply to a grid which already has an excess of demand. Some of these events have been severe enough to trigger emergency load shedding with up to 50k homes disconnected due to low frequency.
I was wondering how this was going to cut power prices. In the UK, which is now the world leader in offshore wind, the levellized cost of off-shore wind energy is approximately $0.25/kWh at the onshore cable termination.
Obviously, this is completely non-viable for a large grid without subsidies (in the UK, these are approximately $0.19/kWh), but for a small grid dependent on expensively imported diesel, this can be a reasonable idea.
It has 7/8 of the processor. In traditional GPU designs, this would mean that only 7/8 of the RAM is addressable and that the RAM data bus is only 7/8 as wide - as parallel modules of both stream processor, L2 cache and memory controller get disabled.
The 1st 3.5 GB operates on the 7/8 wide bus (224 bits); this is the same as on any other reduced core count card. However, nvidia added a new "bypass" bus inside the GPU permit 2 memory controllers to be driven by a single L2 cache module. This avoids the need to reduced addressable RAM in the event of a L2 cache module being disabled. This last memory controller without a dedicated L2 cache module then accesses the top 0.5 GB of RAM via a 1/8 wide (32 bit) bus.
The key point is to allow the reactor to cool for 24 hours or so in a maximally controlled environment - grid power, with backup diesel generators and full tanks for fuel. Once you're through the first 24 hours, the thermal load of decay heat is almost an order of magnitude lower, and much easier to handle.
It is also undesirable to expose the plant to grid transients. Short circuits on the grid, can cause severe mechanical disturbances to the alternator and turbomachinery. In a nuke plant, the LP turbines are typically very large, low speed machines with huge blades. These are susceptible to shock loadings due to their high moment of inertia. In fact, in nuke plant turbines, grid transients are one of the most important factors in determining fatigue life of the turbine assembly.
More over, there is a degree of thermo-hydraulic coupling between the turbine and reactor (or at least the steam generators) - these pressure and heat transients are also a contributor to fatigue life of the primary coolant circuit.
That's not quite correct. There was no some damage to the emergency cooling systems, but it wasn't catastrophic.
At unit 1, the emergency isolation (condenser) cooling system (UPS powered) were manually turned off about 20-30 minutes after the earthquake, because they didn't want to "cold shock" the reactor, and switched instead to alternate methods of cooling (which required AC power). In the confusion that followed loss of AC power, they relied on staff to run outside and check the emergency cooling vents for steam. Staff were not familiar with the volume of steam which should flow from the isolation cooling system (should completely engulf the plant in thick cloud) and reported "faint steam" which was presumed to be due to operation of the isolation cooling system - but was, in fact, residual heat in the vent stacks, as they cooled following shutdown of the isolation condensers. Unit 1 likely suffered total core meltdown within 3-4 hours of the earthquake.
At plants 2 and 3, the emergency cooling system failed after the UPS systems powering the control systems depleted their batteries - a period of about 9 hours after the earthquake. Partial meltdown likely occurred within a few hours of core cooling loss. The extent of core damage is much lower than occurred in unit 1 because the first few hours are when decay heat is highest, and therefore severity of meltdown drops dramatically once through this period.
Fire pumps were brought in to inject water into the reactors at units 2 and 3. In this case, the water pooled in a tank and never reached the reactor. This was not due to a valve fault. The plan to inject water using fire pumps was an ad hoc plan, and the assumption was that the tank was connected to the injection line via a "positive displacement" pump (which would act as an obstruction to flow when unpowered), in fact, the pump was an impeller pump, through which the water could flow with ease. Even if this had worked, this was too late anyway, meltdown would have been near complete by the time the pumps were brought on site, and connections made.
The main lessons learned were:
Don't turn off safety systems during an emergency
Make sure staff are able to recognise the correct operation of safety systems
Ensure that plans for the emergency provision of cooling water are pre-prepared, validated and well rehearsed.
Ensure that emergency portable pumps are available near (but not too near) to site, and that their performance has been validated as acceptable
Ensure adequate redundancy of hydrogen-oxygen catalytic recombiners
Don't forget about the fuel pools.
You raise an interesting point that the interaction of various sensor assist systems can be erratic
In your example, your description cannot be technically correct, although I am not denying that it introduces a degree of instability that would not otherwise exist. Traction control does not, and cannot, apply the brakes. It also does not assume you are or are not in a spin, only that one wheel has lost grip. More advanced systems, e.g. ESC, do detect spin, but they do it with a yaw rate sensor, so it is directly measured, not assumed. The normal operation of traction control is to detect one of the drive wheels spinning faster than the other wheels, and when activated it reduces engine torque (through triggering fuel cut, ignition retard, and/or electronic throttle closure).
One of the things that OEMs found after integrating systems like traction control, stability control, ABS, etc. was that at the boundaries of slip/acceleration/yaw between the systems and normal operation, there were discontinuities in the vehicle dynamics. So, that if you were accelerating, and a drive wheel slipped, there would be a sudden, dramatic reduction in engine torque; or in the event of an impending spin, there would be a dramatic braking of the inside wheel, which could lead to an overcorrection.
Over the last 5 years, the OEMs have realised this, and they have been working very hard to smooth the discontinuities that these systems create. There are all sorts of marketing words for this, e.g. Toyota have "Vehicle dynamics integrated management". All this means is that the sensitivity and power of these systems has been carefully matched to the car and each other, to avoid sudden shocks.
You have made my point (which admittedly I didn't make very clearly). What is useful is a knowledge of anatomy, and knowing what the potential problems are, and careful examination of the raw data of the CT scan. A skilled doctor would have specifically looked for the optic nerve in relation to the tumor. For whatever reason, this was not detected, or not communicated appropriately, resulting in a delayed treatment.
Complex 3D rendering or printing, while it looks impressive, generally isn't all that useful for making the diagnosis - the raw (or minimally processed) data tends to show the anatomical relations most clearly. The raw volumetric data shows everything; a 3D rendering depends upon some sort of thresholding, and the 3D projection necessarily results in occlusion and obscuration of objects. The thing about 3D rendering is that it is immediately recognisable by the lay person, or doctors without specific training in interpretation of CT, whereas the appearance of the anatomy is rather alien to most people when presented as cross-sectional raw data.
As for treating tumors, I'm afraid you're wrong about that. Watch and wait is very important for tumours around the eye and base of skull, because the anatomy here is so complex and fragile that the whole tumor may not be removable, or may be removable only at significant cost (loss of vision, facial disfigurement, risk of infections due to bone holes, etc.) For this reason, if a tumour is only causing minor symptoms, and there is good reason to suspect a benign tumor (i.e. not cancer liable to spread elsewhere in the body), there are often good reasons to delay surgery, until such time as the symptoms resulting from side effects of surgery are likely to be less than the symptoms from the tumor.
3D visualisation is pretty standard on medical imaging software, but it's not really that useful for most situations.
The issue here appears to have been the missed diagnosis of optic nerve compression by the tumor. As it is, a 3D rending/print of a CT scan won't help with that, as both the nerve and tumor will have similar appearances and very low background contrast to normal tissues. Where 3D rendering or printing of CT is useful is for examining the bone.
It sounds like the 3D printing is an interesting factoid tacked onto a story about a misdiagnosis which was corrected after the patient/relatives asked for a 2nd opinion. This, of course, assumes that the diagnosis was wrong in the first place. "Watch and wait" is often far preferable to surgery for slow growing tumours in awkward places.
Most national regulators require that any safety-critical computer systems in nuclear facilities are formally proven correct. Due to the difficulty in producing absolutely bug-free code, and proving that you have done so, a lot of systems continue to rely on pure analog control.
For example, nuclear-grade UPS systems typically offer a feature such as the following:
"Digital logic free. 100% analog control with fully verified behavior. No need for expensive and time consuming software verification"
Similar validation is available for nuclear grade diesel generators and their control systems.
Similar design principles are often applied to the reactor instrumentation, although reactor control is usually digital and verified to the highest level. That typically means no inputs to the system, except the core sensors and core controls. The software uses only a minimal subset of language and OS features - e.g. no memory allocation, no dynamic linking or binding, etc. Calibration and model data must be built into code using a validated code generator and then statically linked into the binary, all memory must be statically allocated at compile time, etc.
The risk is whether less critical systems may be at risk - SCADA and similar systems may be in use for alternator controls, or in switchyard controls. The risk is that grid power to the plant could be interrupted, forcing the plant onto generator power. Or perhaps, other plant might be degraded - non-critical water pumps or plant controls, could mean that under degraded conditions, the plant has less tolerance to a reactor accident.
Realistically, unless you have schematics which detail the control systems in use, it is not possible to determine the severity of a particular attack. Further the interaction between different plant systems may be difficult to predict.
Even if the only realistic target for a cyber attack is the switchyard, that is still highly disruptive and degrades the safety margin of the plant by removing grid power as an energy source.
As a reviewer, I would have rejected the paper because I don't see where either of the references given are cited in the text.
However, they would get a point for being up-to-date in citing RFC2821 rather than RFC 821.
Which is exactly why the "establishment" has been trying to ban it.
No, really! The Republican party had the opposition of "teaching of higher-order thinking skills, critical thinking skills and similar programs" in schools written in their platform document as one of their policy aims.
Why would FTDI have to ensure their driver doesn't break chips that aren't theirs? There's no agreement, licensing, or goodwill.
The problem is that this was not accidental. The FTDI anti-clone code in the driver is very sophisticated and actually performs a "preimage" cryptographic attack, to ensure that the clone chip doesn't detect the invalid configuration and auto-reset to factory defaults. Deliberately and with premeditation setting out to "damage" (which in legal terms includes temporary malfunction or impaired function) hardware is not legal without a court order or similar legal basis.
The 2nd issue, is that of ensuring that they do not inconvenience wholly innocent parties. They failed at this. The FTDI anti-clone code will also deactivate genuine FTDI chips which have been configured with an external configuration memory in certain circumstances. This has been reported by a company which build development boards with numerous FTDI chips in different configurations; they found that the chip with an external EEPROM would get corrupted by new driver, even though the components were obtained from an authorized distributor.
However, a lot of manufacture is contracted out. If you're buying 10 or 20 chips for internal R&D you'll likely get genuine ones.
However, when you find a contract manufacturer and ask them to make 100,000. You require an XYZ, Inc. ABC123 chip and ask the manufacturing contractor to source it. Unbeknown to you, they obtain a counterfeit source. The chip is virtually identical externally, and functionally very similar, so that your product passes validation testing.
You as the device designer and seller may have no idea that you have fake chips on your device. Perhaps, your RMA rate is higher than you expected due to chip failures, or perhaps you are getting a lot of bug reports from the field which are not reproducible on your prototypes, but are on production devices.
This isn't the first time a USB->UART vendor has taken vigilante action against fakes. The vendor Prolific had major problems with low-quality, buggy and slow fake chips, causing major support headaches for customers and themselves. I believe they ended up discontinuing their main product and replacing it with an incompatible version, while poisoning the drivers so that they would BSOD/Kernel panic if they detected a fake chip.
Yes. A company called Supereal is selling enormous volumes of "FTDI" chips into the Chinese market. The chips are labelled with the FTDI name and logo and during the USB negotiation, they announce themselves using the FTDI vendor unique ID, in order to use the ubiquitous and flexible FTDI driver (rather than require any development work for their own driver).
The problem is that the fake chips are buggy and slow compared to the genuine article, causing headaches for USB peripheral designers and support and reputation headaches for FTDI. There is a huge market for USB UART chips, and it is quite competitive, but few of the products on the market are actually as reliable, fast and robust as you would expect them to be. The FTDI FT232RL is one of the best in terms of reliability and has the best drivers, while also providing some handy bonus functionality.
It appears that FTDI have reverse engineered the fake chips and found that they can be reprogrammed. When their driver detects a fake chip, it uses the internal configuration commands to erase the EEPROM memory containing the Vendor Unique ID. With this EEPROM blanked, the chip is unable to complete the device detection process in the OS's USB stack.
The aim was not to find the "best network", but the "best network without redundancy".
The point was that most networks are designed with redundancy in mind, but not all networks require that degree of reliability. For those networks where reliability is not necessary, it would be helpful to know what the lowest cost configurations are.
one or both of them are full of something.
Not necessarily. They could both be right.
The interlock device only defeats the starter. However, if the car lessee is defaulting on lease payments, then it is likely that they are also cutting back on scheduled maintenance and repairs. It is entirely possible that the engine is unreliable and idles poorly, being prone to stall when idling. It is perfectly possible in such a case, for a driver to reach an intersection, have the engine stall, and then be unable to restart it because the interlock has defeated the starter.
And only one variant of one JPEG protocol ever found widespread use.
JPEG actually published both a lossless and a lossy compression algorithm and accompanying file format. The lossless format faded into near total obscurity, apart from some medical software, where the lossless JPEG data would be encapsulated in a medical (DICOM) container. Technically, lossless JPEG is a mandatory part of the DICOM specification, but not every product (free or commercial) supports it, and it's virtually impossible to find an opensource implementation of lossless JPEG outside of limited implementations as part of medical imaging tools.
There have also been a variety of extensions published to the JPEG lossy algorithm - notably extension to 12 or 16 bit depths. Good luck finding any support for these, at all. Again, these formats were nominally supported in the DICOM standard for medical imaging, but were very poorly supported. A flurry of naive new-entrant machine vendors, ended up embracing these "novel" formats, only to cause total chaos for their customers, as they found that the files were unviewable on incumbent viewing software or untransmittable to other systems.
The SAR component of galileo is a separate service to the positioning service. The intention is that it can operate as an EPIRB receiver.
Conventional emergency beacons can be located by satellites, but the resolution is poor (tens of miles) and the time to fix is long (30-60 minutes). The beacon transmits a signal, and suitably equipped satellites detect the beacon, and relay it to ground stations, which then compute the location of the beacon by measuring the change in Doppler shift as the satellite flies by.
The SAR component of galileo was designed with the intention that the overhead satellites would detect the time-of-arrival of the beacon signal and cross reference it with the satellites' atomic clocks, effectively performing a reverse GPS-fix. Such a system would be able to obtain a fix within minutes or seconds, and such a fix would likely have a resolution of 1-2 miles.
The SAR component is not a mandatory service. You can use the passive location service without implementing SAR in a device. You would only use the SAR service, in an emergency locator beacon device.
At the time the galileo SAR system was designed, feedback was a problem with locator beacons. The user had no idea if the signal had been received. Later revisions to the system mean that modern beacons and satellites now offer two big upgrades - the beacons can contain a passive GPS reciever, and can embed the location data in the beacon signal; and the satellite system can transmit feedback to a compatible receiver telling it that it's signal has been received and a position fix made. The Galileo SAR function is therefore rather redundant, but it's often helpful to have a 2nd independent and redundant safety system available, so I can see that it would still get used.
The mining hardware/software will report a realtime hash rate, based upon the operation of the hardware/software.
However, the process of mining is a stochastic random process. Essentially, the job of a miner is to find a partial "hash collision" - essentially, the miner hashes the transaction data and a random nonce, and aims to find a hash as close to 000000000....00 as possible. The bitcoin/alternative network agrees a priori, what threshold counts as a "hit". The miner essentially tries random nonces, until it either gets a hit, or is told that its transaction data is stale, and needs to be refreshed.
Because, in the case of bitcoin, the network sets the target such that on average 1 "hit" is found every 10 minutes worldwide. This means that an individual miner might have to run for weeks or months to get a win and be awarded the (currently) 25 BTC reward for successfully computing a hash below target. In practice, therefore most miners operate on "pools", where a central server coordinates multiple diverse pieces of mining hardware operated by multiple individual operators. The pool operator when they receive a 25 BTC reward, then divides it up amongst the contributors.
The way the individual pool servers account for hash rate is to set a lower hash target, and count the number of "hits" each miner gets. E.g. if the main bitcoin network has target is
Because pools can only detect hashrate by the rate at which "hits" are delivered, the reported hashrate will necessarily vary by virtue of the statistical properties of a stochastic process. The degree of variation depends upon the "difficulty" (target) set by the pool operator, the degree of "smoothing" that the pool operator applies to the displayed statistics, your hash contribution (a bigger contributor, will have a smaller coefficient of variation in their displayed hashrate, again for statistical reasons) etc.
Things are further complicated because many of the affected pools are "multi-coin" pools. The pool server automatically scans multiple cryptocoin networks, and various cryptocoin exchanges, to work out which coin is most profitable, the server will then jump between coins every few seconds or minutes as needed. For various technical reasons, different coins have different "stale" and "orphan" rates - "hits" which should have resulted in new coin creation, but where the hit was rejected (either immediately - stale) or initially accepted, then rolledback (orphan). Some of the alternative coins had rather dubious technical designs which could lead to massive reject rates, and this too could result in displayed hash rates fluctuating like mad.
The final issue is that many pools were often run by rank amateurs, and were targets for hackers/DDos like red-rags are to a bull. DDoSes, random server crashes, bandwidth exceeds, etc. were all common place, as well as various software bugs in "multi-pool" backend software would cause miners to end up disconnected from servers. Smarter miners would have typically have several pools configured on their mining hardware, so that the software could fail-over to another server. However, even that wasn't always successful. I once left my mining hardware unattended for a week, and configured it with 8 pools. When I checked the logs when I got back, there was a period of about 24 hours when the mines were idle, as all servers were off line.
This is the crux of the problem. No one knew what was going on and what to do. Investigations over the last few years have shown that typical TEPCO safety drills were very limited and basic; there was little planning or rehearsal of complex accident scenarios, just basic minor incidents.
There were poor decisions and communication between various designers and operators. Take for example, the situation at reactor 1. After the generators started, the emergency reactor cooling condensers should have switched on to provide cooling. However, operators had found that they were very effective and being unfamiliar with their use were concerned that they would cause thermal shock to the reactor. Not familiar with the operation of this system, the operators decided to manually switch off the condenser system to arrest the temperature drop. They would then switch them on again manually as reactor temp rose again. This worked fine, until the generators failed, removing control and monitoring from this system.
Operators at emergency control, in a separate quake-proof building asked for confirmation of operation, but the control room could not give it. So,workers went out to inspect the reactor building for steam rising from the condenser stacks. They reported some steam rising, and it was assumed that the system was operational. However, the condenser system had never been used or tested since the plants were constructed 40 years ago. No one knew how they worked and how quickly they could cool the reactor, no one knew how much steam was produced during operation. It turns out that the workers sent out for reconnaissance saw only faint steam trickling from the stacks, consistent with the system having been switched off for many minutes, but still containing some residual heat. Had the system been switched on, the clouds of steam would have been so profuse and so dense that the it would have been impossible even to see the reactor building, let alone identify the condenser stacks.
On the assumption that the system was operational, other attempts to provide emergency cooling were suspended or delayed. A steam/battery powered pump system was available to deliver fresh water to the reactor, but without a heatsink (condenser) available, the reactor temperature rapidly rose and so did reactor pressure, eventually overcoming the maximum discharge pressure of the coolant injection system. After a few hours, the UPS controlling this system discharged and it also failed.
After 24 hours, reactor pressure unexpectedly dropped. Operators realised that this might permit external coolant injection and fire engines were called in. There was a huge delay, as the fire engines were unable to reach the site due to debris and some had been destroyed by the tsunami. Subsequent investigation showed that despite massive coolant injection, coolant did not rise in the reactor. The cause was thought to be due to damage to the reactor vessel or a pipe. In retrospect, it probably indicated damage to the reactor following meltdown of the fuel.
There were also design oversights in the emergency systems for the plants. One of the final backup schemes for reactor cooling was the ability to connect fire engines to the reactor to inject coolant. It subsequently became apparent that in units 2 and 3, this water didn't reach the reactor, and collected in a condenser unit instead. This was always going to happen, due to the way in which the water pipes were connected. There was a pump connected between the storage tank and the injection flow pipe. Under normal injection conditions, the pump would have been running, and any additional water from the fire engine would likely have gone towards the reactor, and this presumably was the assumption under which the water injection protocol was developed. However, under power failure conditions, the pump was unpowered. Due to the design of the pump - a rotodynamic (impeller) pump. this pump would have offered little or no resistance to reverse flow when unpowered.
This would not help. The exact offence is "failing to make readable encrypted data".
In order to convict, the prosecution only have to prove that the data is encrypted, that you had control over that encryption and that they have not been able to read it.
Loss of damage of the encryption keys is not a defence. The law was specifically designed this way in order to discourage self-destructing encryption keys, etc.
The only defence against such a prosecution is to keep a backup of the encryption keys available, so that they can be handed over on request.
Once the ISP receives a "put back" notice, they must pass to the original complainant in a timely manner.
The ISP must then wait for 10 days, to give the original complainant time to consider the "put back" notice, and decide whether a court case should commence. After the 10 day waiting period, if the ISP has not received notice of a restraining order blocking the put back because of an impending court hearing, then it is allowed to restore the content.
In order to avoid liability to their customer, the content must be restored with 14 days of receiving the "put back" notice, provided that the complainant has not obtained a restraining order blocking the put back.
At least in the UK's interpretation of this EC directive (the Distance Selling Regulations), digital downloads were NOT excluded. The purchase could cancel the purchase at any time up to 7 days after purchase and receive a full refund. Technically, you could download a software package or a movie, and then change your mind and claim a full refund.
While the Distance Selling Regulations specifically excluded copyright material such as computer software, movies, music, etc. - they do so only in physical form i.e. CDs, DVDs, etc. Downloads are treated as a "contract for a service" which do not fall in the scope of this very limited exclusion.
The ambiguity over digital downloads has caused a lot of heartache for a couple of small software developers that I know - albeit not enough to try to take it to court. I'm not sure that there is any caselaw actually addressing this loophole in the current system.
Slashdot Mirror
You mean 200%. Electricity costs in the UK are $0.06/kWh in bulk. Offshore wind has a breakeven price of $0.25/kWh. Things may change in time, and I wouldn't suggest withdrawal of subsidies until we see the potentials and unavoidable drawbacks of the technology. However, to illustrate the point, the UK government recently announced a plan to cut the offshore wind guaranteed purchase price to $0.24/kWh and suddenly a whole bunch of investors threatened to pull out of projects, so the govt backtracked.
A major reason Germany can cope with large amounts of renewables, are because its grid is tightly tied to numerous neighbouring countries. Effectively, the whole of continental Western Europe is tightly interconnected and synchronised.
This allows Germany to use imports/exports to help absorb fluctuations in wind supply outturn. Germany have also been shutting down slow responsing nuclear plants and replacing them with coal and gas turbine plants which are faster to respond.
However, the UK has had significant problems with grid stability after the establishment of a large amount of wind energy. National grid have already increased the maximum allowable "rate of change of frequency" (ROCOF) to 1 Hz/s, because their previous operational limit of 0.1 Hz/s was being continually exceeded due to wind variability. For interconnected systems which depend on ROCOF to detect grid failure (e.g. small scale generation - combined heat power schemes, rooftop solar PV, small scale wind), the previous operational limit was being exceeded frequently enough to result in various "chain reaction" type events. For example, a thermal power plant trips out, causing frequency to fall at a significant but not critical rate - at the same time a random variation in wind output results in a temporary loss of output. Together, this is sufficient to trigger ROCOF protection on embedded generators, causing them to trip off, suddenly withdrawing supply to a grid which already has an excess of demand. Some of these events have been severe enough to trigger emergency load shedding with up to 50k homes disconnected due to low frequency.
I was wondering how this was going to cut power prices. In the UK, which is now the world leader in offshore wind, the levellized cost of off-shore wind energy is approximately $0.25/kWh at the onshore cable termination.
Obviously, this is completely non-viable for a large grid without subsidies (in the UK, these are approximately $0.19/kWh), but for a small grid dependent on expensively imported diesel, this can be a reasonable idea.
It has 7/8 of the processor. In traditional GPU designs, this would mean that only 7/8 of the RAM is addressable and that the RAM data bus is only 7/8 as wide - as parallel modules of both stream processor, L2 cache and memory controller get disabled.
The 1st 3.5 GB operates on the 7/8 wide bus (224 bits); this is the same as on any other reduced core count card. However, nvidia added a new "bypass" bus inside the GPU permit 2 memory controllers to be driven by a single L2 cache module. This avoids the need to reduced addressable RAM in the event of a L2 cache module being disabled. This last memory controller without a dedicated L2 cache module then accesses the top 0.5 GB of RAM via a 1/8 wide (32 bit) bus.
The key point is to allow the reactor to cool for 24 hours or so in a maximally controlled environment - grid power, with backup diesel generators and full tanks for fuel. Once you're through the first 24 hours, the thermal load of decay heat is almost an order of magnitude lower, and much easier to handle.
It is also undesirable to expose the plant to grid transients. Short circuits on the grid, can cause severe mechanical disturbances to the alternator and turbomachinery. In a nuke plant, the LP turbines are typically very large, low speed machines with huge blades. These are susceptible to shock loadings due to their high moment of inertia. In fact, in nuke plant turbines, grid transients are one of the most important factors in determining fatigue life of the turbine assembly.
More over, there is a degree of thermo-hydraulic coupling between the turbine and reactor (or at least the steam generators) - these pressure and heat transients are also a contributor to fatigue life of the primary coolant circuit.
That's not quite correct. There was no some damage to the emergency cooling systems, but it wasn't catastrophic.
At unit 1, the emergency isolation (condenser) cooling system (UPS powered) were manually turned off about 20-30 minutes after the earthquake, because they didn't want to "cold shock" the reactor, and switched instead to alternate methods of cooling (which required AC power). In the confusion that followed loss of AC power, they relied on staff to run outside and check the emergency cooling vents for steam. Staff were not familiar with the volume of steam which should flow from the isolation cooling system (should completely engulf the plant in thick cloud) and reported "faint steam" which was presumed to be due to operation of the isolation cooling system - but was, in fact, residual heat in the vent stacks, as they cooled following shutdown of the isolation condensers. Unit 1 likely suffered total core meltdown within 3-4 hours of the earthquake.
At plants 2 and 3, the emergency cooling system failed after the UPS systems powering the control systems depleted their batteries - a period of about 9 hours after the earthquake. Partial meltdown likely occurred within a few hours of core cooling loss. The extent of core damage is much lower than occurred in unit 1 because the first few hours are when decay heat is highest, and therefore severity of meltdown drops dramatically once through this period.
Fire pumps were brought in to inject water into the reactors at units 2 and 3. In this case, the water pooled in a tank and never reached the reactor. This was not due to a valve fault. The plan to inject water using fire pumps was an ad hoc plan, and the assumption was that the tank was connected to the injection line via a "positive displacement" pump (which would act as an obstruction to flow when unpowered), in fact, the pump was an impeller pump, through which the water could flow with ease. Even if this had worked, this was too late anyway, meltdown would have been near complete by the time the pumps were brought on site, and connections made.
The main lessons learned were: Don't turn off safety systems during an emergency Make sure staff are able to recognise the correct operation of safety systems Ensure that plans for the emergency provision of cooling water are pre-prepared, validated and well rehearsed. Ensure that emergency portable pumps are available near (but not too near) to site, and that their performance has been validated as acceptable Ensure adequate redundancy of hydrogen-oxygen catalytic recombiners Don't forget about the fuel pools.
You raise an interesting point that the interaction of various sensor assist systems can be erratic
In your example, your description cannot be technically correct, although I am not denying that it introduces a degree of instability that would not otherwise exist. Traction control does not, and cannot, apply the brakes. It also does not assume you are or are not in a spin, only that one wheel has lost grip. More advanced systems, e.g. ESC, do detect spin, but they do it with a yaw rate sensor, so it is directly measured, not assumed. The normal operation of traction control is to detect one of the drive wheels spinning faster than the other wheels, and when activated it reduces engine torque (through triggering fuel cut, ignition retard, and/or electronic throttle closure).
One of the things that OEMs found after integrating systems like traction control, stability control, ABS, etc. was that at the boundaries of slip/acceleration/yaw between the systems and normal operation, there were discontinuities in the vehicle dynamics. So, that if you were accelerating, and a drive wheel slipped, there would be a sudden, dramatic reduction in engine torque; or in the event of an impending spin, there would be a dramatic braking of the inside wheel, which could lead to an overcorrection.
Over the last 5 years, the OEMs have realised this, and they have been working very hard to smooth the discontinuities that these systems create. There are all sorts of marketing words for this, e.g. Toyota have "Vehicle dynamics integrated management". All this means is that the sensitivity and power of these systems has been carefully matched to the car and each other, to avoid sudden shocks.
You have made my point (which admittedly I didn't make very clearly). What is useful is a knowledge of anatomy, and knowing what the potential problems are, and careful examination of the raw data of the CT scan. A skilled doctor would have specifically looked for the optic nerve in relation to the tumor. For whatever reason, this was not detected, or not communicated appropriately, resulting in a delayed treatment.
Complex 3D rendering or printing, while it looks impressive, generally isn't all that useful for making the diagnosis - the raw (or minimally processed) data tends to show the anatomical relations most clearly. The raw volumetric data shows everything; a 3D rendering depends upon some sort of thresholding, and the 3D projection necessarily results in occlusion and obscuration of objects. The thing about 3D rendering is that it is immediately recognisable by the lay person, or doctors without specific training in interpretation of CT, whereas the appearance of the anatomy is rather alien to most people when presented as cross-sectional raw data.
As for treating tumors, I'm afraid you're wrong about that. Watch and wait is very important for tumours around the eye and base of skull, because the anatomy here is so complex and fragile that the whole tumor may not be removable, or may be removable only at significant cost (loss of vision, facial disfigurement, risk of infections due to bone holes, etc.) For this reason, if a tumour is only causing minor symptoms, and there is good reason to suspect a benign tumor (i.e. not cancer liable to spread elsewhere in the body), there are often good reasons to delay surgery, until such time as the symptoms resulting from side effects of surgery are likely to be less than the symptoms from the tumor.
Can someone explain why in the example race condition code given, the theoretical minimum count is 2, and not n_iters?.
3D visualisation is pretty standard on medical imaging software, but it's not really that useful for most situations. The issue here appears to have been the missed diagnosis of optic nerve compression by the tumor. As it is, a 3D rending/print of a CT scan won't help with that, as both the nerve and tumor will have similar appearances and very low background contrast to normal tissues. Where 3D rendering or printing of CT is useful is for examining the bone. It sounds like the 3D printing is an interesting factoid tacked onto a story about a misdiagnosis which was corrected after the patient/relatives asked for a 2nd opinion. This, of course, assumes that the diagnosis was wrong in the first place. "Watch and wait" is often far preferable to surgery for slow growing tumours in awkward places.
For example, nuclear-grade UPS systems typically offer a feature such as the following: "Digital logic free. 100% analog control with fully verified behavior. No need for expensive and time consuming software verification"
Similar validation is available for nuclear grade diesel generators and their control systems.
Similar design principles are often applied to the reactor instrumentation, although reactor control is usually digital and verified to the highest level. That typically means no inputs to the system, except the core sensors and core controls. The software uses only a minimal subset of language and OS features - e.g. no memory allocation, no dynamic linking or binding, etc. Calibration and model data must be built into code using a validated code generator and then statically linked into the binary, all memory must be statically allocated at compile time, etc.
The risk is whether less critical systems may be at risk - SCADA and similar systems may be in use for alternator controls, or in switchyard controls. The risk is that grid power to the plant could be interrupted, forcing the plant onto generator power. Or perhaps, other plant might be degraded - non-critical water pumps or plant controls, could mean that under degraded conditions, the plant has less tolerance to a reactor accident.
Realistically, unless you have schematics which detail the control systems in use, it is not possible to determine the severity of a particular attack. Further the interaction between different plant systems may be difficult to predict.
Even if the only realistic target for a cyber attack is the switchyard, that is still highly disruptive and degrades the safety margin of the plant by removing grid power as an energy source.
As a reviewer, I would have rejected the paper because I don't see where either of the references given are cited in the text. However, they would get a point for being up-to-date in citing RFC2821 rather than RFC 821.
No, really! The Republican party had the opposition of "teaching of higher-order thinking skills, critical thinking skills and similar programs" in schools written in their platform document as one of their policy aims.
Wash post
Why would FTDI have to ensure their driver doesn't break chips that aren't theirs? There's no agreement, licensing, or goodwill. The problem is that this was not accidental. The FTDI anti-clone code in the driver is very sophisticated and actually performs a "preimage" cryptographic attack, to ensure that the clone chip doesn't detect the invalid configuration and auto-reset to factory defaults. Deliberately and with premeditation setting out to "damage" (which in legal terms includes temporary malfunction or impaired function) hardware is not legal without a court order or similar legal basis. The 2nd issue, is that of ensuring that they do not inconvenience wholly innocent parties. They failed at this. The FTDI anti-clone code will also deactivate genuine FTDI chips which have been configured with an external configuration memory in certain circumstances. This has been reported by a company which build development boards with numerous FTDI chips in different configurations; they found that the chip with an external EEPROM would get corrupted by new driver, even though the components were obtained from an authorized distributor.
However, when you find a contract manufacturer and ask them to make 100,000. You require an XYZ, Inc. ABC123 chip and ask the manufacturing contractor to source it. Unbeknown to you, they obtain a counterfeit source. The chip is virtually identical externally, and functionally very similar, so that your product passes validation testing.
You as the device designer and seller may have no idea that you have fake chips on your device. Perhaps, your RMA rate is higher than you expected due to chip failures, or perhaps you are getting a lot of bug reports from the field which are not reproducible on your prototypes, but are on production devices.
This isn't the first time a USB->UART vendor has taken vigilante action against fakes. The vendor Prolific had major problems with low-quality, buggy and slow fake chips, causing major support headaches for customers and themselves. I believe they ended up discontinuing their main product and replacing it with an incompatible version, while poisoning the drivers so that they would BSOD/Kernel panic if they detected a fake chip.
See http://zeptobars.ru/en/read/FT... for an example of a fake chip - labelled FTDI on the outside, but supereal on the silicon.
The problem is that the fake chips are buggy and slow compared to the genuine article, causing headaches for USB peripheral designers and support and reputation headaches for FTDI. There is a huge market for USB UART chips, and it is quite competitive, but few of the products on the market are actually as reliable, fast and robust as you would expect them to be. The FTDI FT232RL is one of the best in terms of reliability and has the best drivers, while also providing some handy bonus functionality.
It appears that FTDI have reverse engineered the fake chips and found that they can be reprogrammed. When their driver detects a fake chip, it uses the internal configuration commands to erase the EEPROM memory containing the Vendor Unique ID. With this EEPROM blanked, the chip is unable to complete the device detection process in the OS's USB stack.
The aim was not to find the "best network", but the "best network without redundancy".
The point was that most networks are designed with redundancy in mind, but not all networks require that degree of reliability. For those networks where reliability is not necessary, it would be helpful to know what the lowest cost configurations are.
one or both of them are full of something. Not necessarily. They could both be right. The interlock device only defeats the starter. However, if the car lessee is defaulting on lease payments, then it is likely that they are also cutting back on scheduled maintenance and repairs. It is entirely possible that the engine is unreliable and idles poorly, being prone to stall when idling. It is perfectly possible in such a case, for a driver to reach an intersection, have the engine stall, and then be unable to restart it because the interlock has defeated the starter.
And only one variant of one JPEG protocol ever found widespread use. JPEG actually published both a lossless and a lossy compression algorithm and accompanying file format. The lossless format faded into near total obscurity, apart from some medical software, where the lossless JPEG data would be encapsulated in a medical (DICOM) container. Technically, lossless JPEG is a mandatory part of the DICOM specification, but not every product (free or commercial) supports it, and it's virtually impossible to find an opensource implementation of lossless JPEG outside of limited implementations as part of medical imaging tools. There have also been a variety of extensions published to the JPEG lossy algorithm - notably extension to 12 or 16 bit depths. Good luck finding any support for these, at all. Again, these formats were nominally supported in the DICOM standard for medical imaging, but were very poorly supported. A flurry of naive new-entrant machine vendors, ended up embracing these "novel" formats, only to cause total chaos for their customers, as they found that the files were unviewable on incumbent viewing software or untransmittable to other systems.
The SAR component of galileo is a separate service to the positioning service. The intention is that it can operate as an EPIRB receiver. Conventional emergency beacons can be located by satellites, but the resolution is poor (tens of miles) and the time to fix is long (30-60 minutes). The beacon transmits a signal, and suitably equipped satellites detect the beacon, and relay it to ground stations, which then compute the location of the beacon by measuring the change in Doppler shift as the satellite flies by. The SAR component of galileo was designed with the intention that the overhead satellites would detect the time-of-arrival of the beacon signal and cross reference it with the satellites' atomic clocks, effectively performing a reverse GPS-fix. Such a system would be able to obtain a fix within minutes or seconds, and such a fix would likely have a resolution of 1-2 miles. The SAR component is not a mandatory service. You can use the passive location service without implementing SAR in a device. You would only use the SAR service, in an emergency locator beacon device. At the time the galileo SAR system was designed, feedback was a problem with locator beacons. The user had no idea if the signal had been received. Later revisions to the system mean that modern beacons and satellites now offer two big upgrades - the beacons can contain a passive GPS reciever, and can embed the location data in the beacon signal; and the satellite system can transmit feedback to a compatible receiver telling it that it's signal has been received and a position fix made. The Galileo SAR function is therefore rather redundant, but it's often helpful to have a 2nd independent and redundant safety system available, so I can see that it would still get used.
However, the process of mining is a stochastic random process. Essentially, the job of a miner is to find a partial "hash collision" - essentially, the miner hashes the transaction data and a random nonce, and aims to find a hash as close to 000000000....00 as possible. The bitcoin/alternative network agrees a priori, what threshold counts as a "hit". The miner essentially tries random nonces, until it either gets a hit, or is told that its transaction data is stale, and needs to be refreshed.
Because, in the case of bitcoin, the network sets the target such that on average 1 "hit" is found every 10 minutes worldwide. This means that an individual miner might have to run for weeks or months to get a win and be awarded the (currently) 25 BTC reward for successfully computing a hash below target. In practice, therefore most miners operate on "pools", where a central server coordinates multiple diverse pieces of mining hardware operated by multiple individual operators. The pool operator when they receive a 25 BTC reward, then divides it up amongst the contributors.
The way the individual pool servers account for hash rate is to set a lower hash target, and count the number of "hits" each miner gets. E.g. if the main bitcoin network has target is Because pools can only detect hashrate by the rate at which "hits" are delivered, the reported hashrate will necessarily vary by virtue of the statistical properties of a stochastic process. The degree of variation depends upon the "difficulty" (target) set by the pool operator, the degree of "smoothing" that the pool operator applies to the displayed statistics, your hash contribution (a bigger contributor, will have a smaller coefficient of variation in their displayed hashrate, again for statistical reasons) etc.
Things are further complicated because many of the affected pools are "multi-coin" pools. The pool server automatically scans multiple cryptocoin networks, and various cryptocoin exchanges, to work out which coin is most profitable, the server will then jump between coins every few seconds or minutes as needed. For various technical reasons, different coins have different "stale" and "orphan" rates - "hits" which should have resulted in new coin creation, but where the hit was rejected (either immediately - stale) or initially accepted, then rolledback (orphan). Some of the alternative coins had rather dubious technical designs which could lead to massive reject rates, and this too could result in displayed hash rates fluctuating like mad.
The final issue is that many pools were often run by rank amateurs, and were targets for hackers/DDos like red-rags are to a bull. DDoSes, random server crashes, bandwidth exceeds, etc. were all common place, as well as various software bugs in "multi-pool" backend software would cause miners to end up disconnected from servers. Smarter miners would have typically have several pools configured on their mining hardware, so that the software could fail-over to another server. However, even that wasn't always successful. I once left my mining hardware unattended for a week, and configured it with 8 pools. When I checked the logs when I got back, there was a period of about 24 hours when the mines were idle, as all servers were off line.
There were poor decisions and communication between various designers and operators. Take for example, the situation at reactor 1. After the generators started, the emergency reactor cooling condensers should have switched on to provide cooling. However, operators had found that they were very effective and being unfamiliar with their use were concerned that they would cause thermal shock to the reactor. Not familiar with the operation of this system, the operators decided to manually switch off the condenser system to arrest the temperature drop. They would then switch them on again manually as reactor temp rose again. This worked fine, until the generators failed, removing control and monitoring from this system.
Operators at emergency control, in a separate quake-proof building asked for confirmation of operation, but the control room could not give it. So,workers went out to inspect the reactor building for steam rising from the condenser stacks. They reported some steam rising, and it was assumed that the system was operational. However, the condenser system had never been used or tested since the plants were constructed 40 years ago. No one knew how they worked and how quickly they could cool the reactor, no one knew how much steam was produced during operation. It turns out that the workers sent out for reconnaissance saw only faint steam trickling from the stacks, consistent with the system having been switched off for many minutes, but still containing some residual heat. Had the system been switched on, the clouds of steam would have been so profuse and so dense that the it would have been impossible even to see the reactor building, let alone identify the condenser stacks.
On the assumption that the system was operational, other attempts to provide emergency cooling were suspended or delayed. A steam/battery powered pump system was available to deliver fresh water to the reactor, but without a heatsink (condenser) available, the reactor temperature rapidly rose and so did reactor pressure, eventually overcoming the maximum discharge pressure of the coolant injection system. After a few hours, the UPS controlling this system discharged and it also failed.
After 24 hours, reactor pressure unexpectedly dropped. Operators realised that this might permit external coolant injection and fire engines were called in. There was a huge delay, as the fire engines were unable to reach the site due to debris and some had been destroyed by the tsunami. Subsequent investigation showed that despite massive coolant injection, coolant did not rise in the reactor. The cause was thought to be due to damage to the reactor vessel or a pipe. In retrospect, it probably indicated damage to the reactor following meltdown of the fuel.
There were also design oversights in the emergency systems for the plants. One of the final backup schemes for reactor cooling was the ability to connect fire engines to the reactor to inject coolant. It subsequently became apparent that in units 2 and 3, this water didn't reach the reactor, and collected in a condenser unit instead. This was always going to happen, due to the way in which the water pipes were connected. There was a pump connected between the storage tank and the injection flow pipe. Under normal injection conditions, the pump would have been running, and any additional water from the fire engine would likely have gone towards the reactor, and this presumably was the assumption under which the water injection protocol was developed. However, under power failure conditions, the pump was unpowered. Due to the design of the pump - a rotodynamic (impeller) pump. this pump would have offered little or no resistance to reverse flow when unpowered.
This would not help. The exact offence is "failing to make readable encrypted data". In order to convict, the prosecution only have to prove that the data is encrypted, that you had control over that encryption and that they have not been able to read it. Loss of damage of the encryption keys is not a defence. The law was specifically designed this way in order to discourage self-destructing encryption keys, etc. The only defence against such a prosecution is to keep a backup of the encryption keys available, so that they can be handed over on request.
The ISP must then wait for 10 days, to give the original complainant time to consider the "put back" notice, and decide whether a court case should commence. After the 10 day waiting period, if the ISP has not received notice of a restraining order blocking the put back because of an impending court hearing, then it is allowed to restore the content.
In order to avoid liability to their customer, the content must be restored with 14 days of receiving the "put back" notice, provided that the complainant has not obtained a restraining order blocking the put back.
The change to digital data is welcome.
At least in the UK's interpretation of this EC directive (the Distance Selling Regulations), digital downloads were NOT excluded. The purchase could cancel the purchase at any time up to 7 days after purchase and receive a full refund. Technically, you could download a software package or a movie, and then change your mind and claim a full refund.
While the Distance Selling Regulations specifically excluded copyright material such as computer software, movies, music, etc. - they do so only in physical form i.e. CDs, DVDs, etc. Downloads are treated as a "contract for a service" which do not fall in the scope of this very limited exclusion.
The ambiguity over digital downloads has caused a lot of heartache for a couple of small software developers that I know - albeit not enough to try to take it to court. I'm not sure that there is any caselaw actually addressing this loophole in the current system.