Residential inverters have a sweet spot at 2.5KW. His system is considerably larger so some of the quotes might have been with several smaller inverters verses one big one. His system is also a LV (low voltage) system, not a HV system. LV systems are bit more complex due to the higher currents involved.
His system is quite a bit larger then the sweet spot. 2.5KW is usually plenty for a California home which is up to code.
California (where I live too) does give utilities a bye on selling power back, but the total usage is calculated over the entire year, not daily, so you benefit from pushing power back into the grid simply by the fact that you pull it out again at night and (often) offset a cumulative return in summer by your winter use. Frankly, it's a bit of a toss-up as to fairness. There are more costs involved to distributing power then just the power itself. It's not really fair to be able to use the utility's infrastructure as if it that cost were $0 simply because you can produce more power on average then you use. You still need the grid for nighttime and (often) winter days, as well as for rainy or cloudy days.
Nobody in their right mind installs a solar system with a battery bank unless they are way the hell out in the boondocks, or off-grid entirely. Grid-tie systems are really the only way to go if you want to be green. Grid-tie systems have 0 maintainance over pretty much their entire 20+ year life whereas systems with battery storage require maintainance every few years and battery replacement (using *expensive* batteries) every 12 years or so.
Light bleaching of solar panels has well known properties. You don't have to physically test a mono or polycrystaline panel for 12 years to know that it will last that long. Or 20, or 25. You can calculate what the degradation curve is and, gee, real life happens to match the curve!
If you are in a windy place then wind will generate a lot more power in less space. Wind tends not to be an option for a home installation, though, your neighbors will take you to court and force you take it down:-)
Standard mono and polycrystaline panels easily last 25 years. Yes, there is a drop in the power they produce... light bleeching destroys everything, frankly. But standard panels are fairly resilient and you can count on 25 years with moderate degradation. Really they work forever, they just get less and less efficient. The panels are only half the cost of the whole system. Replacing panels is easy, it's the initial installation that's a bitch.
The new-fangled stuff... solar built into roof material, or drapes, or windows, or flexible plastic... that stuff doesn't usually last very long and usually has horrible efficiency. I wouldn't touch it with a ten foot poll. Go with standard mono or poly panels.
They definitely last more then 2-3. My poly panels have been installed longer then that and I have not noticed any significant drop-off yet.
Almost. When converting DC to DC the intermediate stage is only AC in the current domain. The actual forward path voltage never goes negative, and therefore never needs rectification. Basically you have one inductor, one diode, the PWM controller, and a capacitor to filter the output. The diode is not used for rectification purposes (at least, nto the traditional rectification you see in a standard AC-DC converter). In a buck converter it provides a current path when the PWM is switched off, and in the boost converter it allows the PWM switch to short the output of the inductor to build the current up.
No. You can't just use a step-up or step-down transformer. For one thing, no such beast exists for DC. Transformers can only be used to step-up and step-down AC. Some sort of high-frequency switching circuit (using a transformer and/or inductor, depending) is needed to step-up and step-down DC with any reasonable efficiency.
But even if you could you have to remember that Solar Panels do not put out a fixed voltage. There's a voltage curve based on the load as well as on the amount of sunlight hitting the panel. You can't just use a fixed step-up or step-down ratio and expect to get a usable voltage out the other end.
The most common method these days is to tie each string in series and use a high voltage DC inverter. The DC input voltage to the inverter is on the order of 200-600VDC, depending on the setup and the time of day.
HV systems tend to be a lot less complex and more reliable then LV systems. LV systems need a lot more high-current parts internally, need to up-convert the voltage instead of down-converting it (down-converting is easier, always), can't use very many diode-like devices due to the voltage drop, and have harder time managing the maximum power point (MPP), and several other reasons. HV systems are also easier and safer to fuse because the current range is a lot lower... it's easier to tell when you have a short. Just easier all around.
You're trying to do a time-cost-of-money calculation. It doesn't quite work that well in real life. If you can't take advantage of compounding (i.e. reinvesting dividends, i.e. not taking any revenue stream out from the investment to do things like, oh, pay the electric bill). If you can manage break-even... taking the required cash out and not increasing or reducing your balance, then inflation still tends to eat away at the value of the basis.
The other problem is simply the stock market itself. Getting 10% a year out of it might be possible over the long haul, but volatility in the time-frame of a decade could give you anywhere from -20% to +20% a year, or worse depending on what you are invested in. Plus if you have to take money out regularly then you have to take profits and you wind up paying a big chunk of those profits in taxes to the government and, depending on your income level, you can even push yourself into a different tax bracket. It isn't cut-and-dry.
On the flip side, it might be possible to take a tax credit for the money spent on the solar system, and if you can manage to spend the money up front it does in fact improve the value of your home and also significantly improves your monthly cash flow. Some people tend to burn their cash reserves regardless of what they think they've saved and burning it on something more worthwhile, like a solar system instead of a vacation, would definitely be an improvement. If you see the solar as a long-term investment then those improvements can, in fact, be more beneficial to you.
In any case, a standard California home does not need a 4KW system. 2KW will do just fine. I have a 2.5KW system and a fairly large house and if I didn't have 12 computers running 24x7 my electric bill would be nearly zero.
You get the most payback by cutting away the top tier electric rate. You hit diminishing returns if you cut away the entire electric bill. A 2KW system costs a lot less then a 4KW system. The best price point for a consumer inverter such as a Sunny Boy is 2.5KW.
I strongly recommend that anyone getting a solar system get it professionally installed. A solar panel system with a high voltage DC inverter setup (~400VDC, typically one or two strings hooked in series), grid-tie (no battery), requires zero maintainance.
Another thing people should consider, even before considering a PV system, is to get a solar water heating system. These don't use PV panels but instead convert sunlight directly into heat (pipes and glass basically). The efficiency is very good and the cost is far lower then a PV system, and will chop off a good chunk of the gas bill from your water heater.
I'm the guy that wrote the Diablo USENET news system.
Oops. Guess I know it better then you do!
There's reality, and there's fantasy. The reality is that the signal to noise ratio pretty much nullified the advantages of the distribution mechanic, and the storage and management costs (even with the massive automation we built into the news systems) made it a pain.
It is actually better to use point-distribution containing just the information you care about then to use a highly distributed model where 99.999% of the stuff flowing in is undesired. Only large commercial companies with highly replicative content, such as a cable provider, reaps benefits from that sort of model. Not even internet radio gets much of an advantage. Anyone remember real audio? They were the only ones trying to use a highly distributed model and the internet overtook them.
Seriously, though. There are very, very few people left who use the USENET for anything real.
I mean, give me a break, the alt groups were a problem 10 years ago, and some ISPs are still carrying them? That's just stupid. When we were carrying the alt groups at BEST we had to set the article timeout for the high-bandwidth groups to 1-day, and that actually did a pretty good job stopping all the idiots trying to download 5000 part port movies over their dialup modems. They just couldn't keep up before the stuff timed out.
ALT had a signal to noise ratio of 1:1000 10 years ago, I'm guessing its more like 1:50000 now. Only a fool carries it. There are plenty of other ways people can exercise their freedom of speech (and most do, in other ways now).
Actually this isn't true. Modern TCP protocols will happily use whatever socket buffer space they are configured for, regardless of the latency, and will not reduce it unless they hit congestion control (meaning dropped packets, meaning you have to implement RED on the receiving side and you really want to avoid doing that if you can help it).
But there are TCP moderation algorithms that will detect the link bandwidth (again, the latency is irrelevant) and actually *reduce* the number of packets queued. TCP-Vegas is one such algorithm. There is another implemented in Dragonfly and FreeBSD which can be enabled with net.inet.tcp.inflight_enable. These algorithms are designed to reduce, but not eliminate, packet backlogs at constriction points along the path between the server and client.
These algorithms must be implemented on the *sending* end, however. Doing it on the receiving end is a much harder problem to solve. It is a good idea to enable it on your servers regardless because it reduces the number of packets backlogged on your router (or wherever your bandwidth becomes constricted) and actually improves the router's own filtering/QOS algorithms. If you have a lot of servers behind a router you can easily blow out the router's packet queues with burst traffic if you don't have this sort of feature enabled.
Your only real choice on the receiving end is to force the packet backlog to shift to a machine under your control, which essentially means creating an artificial bandwidth restriction on your incoming packet stream. I discussed this earlier. It is possible to dynamically adjust the TCP window your receivers advertise but I don't know of anyone who has ever gotten good results from doing that, and it is very hard to build an algorithm to calculate the correct window size the receiving end should advertise.
IMHO, Cisco has the best packet queueing mechanisms that I know of. I've been using their fair-queue stuff for years, and it has only gotten better with each iteration of IOS.
When I went from a T1 to a DSL line to save some money I immediately noticed the missing cisco. That little 2620 was so nice. PF couldn't hold a candle to what the 2620's fair-queue could do so I sat down and wrote a fair-queue implementation for PF (for DragonFly). It still isn't as good as what Cisco has, but it gets a lot closer then the other PF queuing mechanisms get.
I think the bit I'm missing is the batch classification. My fair-queue can still get overwhelmed by dozens of batch TCP connections if I happen to not be able to classify their traffic (and they wind up on the standard queue instead of the bulk queue). The set-up is a priority queue with minimum bandwidth guarantees plus a fair-queue at each priority level.
I keep hoping someone will take up the flag and finish it.
That only works to a point. If you have a single computer you can control the traffic quite well. But if your home network has more then a few computers, all doing different things, PLUS consumer devices such as Apple TV, TiVO, and many other internet-connected devices, the story changes. You will not have control over all the equipment and your only recourse will be active filtering with some sort of queueing mechanic.
Even a home with only computers under your control may not be entirely under your control. If you have a sibling he is not likely going to let you mess around with his downloads.
It is always easier to manage uplink bandwidth from downlink bandwidth, simply by virtue of the fact that you control the actual packet queues.
Downlink bandwidth can be controlled in numerous ways. The easiest way is to actually run the incoming packets through a bandwidth limiter with a very large packet queuing capability. This will cause a ton of packets to build up in front of the limiter and eventually fill the TCP windows of the senders. The packets that get through the limiter will cause a stream of ACKs back from your machines at the desired data rate. The combination of the two will cause the remote senders to band-limit the packets they send to the bandwidth you desire.
when running incoming packets through a limiter you still need to traffic-shape/QOS, priority-queue, or priority-queue + fair-queue the packets going through the limiter. If you don't then your interactive traffic can wind up getting stuck in a packet queue with hundreds of packets in it. In addition to that you may have to control the advertised TCP window or even implement RED on your limiter to prevent the hundreds of packets built up in front of the limiter from turning into thousands of packets.
If you can classify the bulk traffic then you can use virtually any queueing mechanic. If you can't classify all of the bulk traffic then the only mechanic that will work reasonably well is, again, going to be a fair-queue.
Fair-queueing is not the holy grail but it is typically the most effective mechanism when combined with another queueing mechanic, such as a priority queue.
Traffic shaping and QOS will help a little, but the real problem is simply that you can't afford to delay priority traffic by more then one or two full-sized packets on any connection less then a few megabits (meaning: just about all home interconnects). If you wait any longer then that, it becomes noticeable.
Traffic shaping and QOS are not usually able to make that guarantee. A straight priority queue with bandwidth guarantees can, as long as you are able to actually classify the torrent traffic differently from your other traffic.
Part of the problem is that it is often not possible to distinguish between the batch and the interactive traffic with Shaping/QOS. Not only is QOS almost universally set wrong, but the simple fact is that one can mix interactive and batch traffic over the SAME ports (http, ssh, dynamically allocated ports)and that can make it virtually impossible to use traffic shaping or QOS to keep the mess away from your interactive traffic.
The best general solution is to use a straight priority mechanic with minimum bandwidth settings to separate as much of the bulk traffic out as you can, and then run fair-queueing at each priority level to take care of any that leaks through. This will do a very good job cleaning up the traffic. DragonFly has a fair-queue implementation for PF that does this. There is also at least one fair-queue implementation for PF in the wild.
Fair-queueing essentially classifies connections (the one in DFly uses PF's keep-state to classify connections), generates a hash and indexes a large array of mini-queues. One packet is then pulled off the head of each mini-queue. One enhancement I would like to make to the DFly implementation which I haven't done yet is to use the keep-state to actually determine which connections are batch and which are interactive, and have a parameter that allows the queue to give additional priority to the interactive connections by occasionally skipping the hoppers related to the batch connections. A quick and dirty way to do that is to simply check the queue length for each mini-queue.
In anycase, its a problem for which solutions are available. Regardless of what you use it has become apparent in the last few years that the only way one can classify the traffic well enough to properly queue it is by building keep-state knowledge on a connection by connection basis.
For two reasons. First and foremost, low power consumption. Secondly, we have already passed the sweet spot in the storage capacity needed for the applications most people run, particularly on laptops. Add to that the fact that current HD form factors are an extremely good fit for SSD units, and the writing is on the wall.
So what will happen is pretty obvious. Laptops are going to push SSD storage into the mainstream, giving it the critical mass needed to start the research bandwagon rolling, and 5-10 years after that happens hard drives will become the 'new' tape storage and most production systems will be using SSDs.
Even more pointedly, with power costs being the premium concern for data centers these days, and the hard drive being the only thing left in the computer that can't be engineered down to near 0 power consumption when idle (short of spinning it down, which has its own problems), my expectation is that large commercial concerns will see a huge cost benefit to using SSD storage despite the higher front-end cost of purchasing it.
There's no distinction between the two any more, and hasn't been for a long time. The whole point of RISC was to simplify the instruction format and pipeline.
The problem these days is that it doesn't actually cost anything to have a complex instruction format. It's such a tiny, isolated piece of the chip that it doesn't count for anything, it doesn't even slow the chip down because the chip is decoding from a wide cache line (or multiple wide cache lines) anyway.
So what does that leave us with? A load-store instruction architecture verses a read-modify-write instruction architecture? Completely irrelevant now that all modern processors have write buffer pipelines. And, it turns out, you need to have a RMW style instruction anyway, even if you are RISC, if you want to have any hope of operating in a SMP environment. And regardless of the distinction cpu architectures already have to optimize across multiple instructions, so again the concept devolves into trivialities.
Power savings are certainly a function of the design principles used in creating the architecture, but it has nothing whatsoever to do with the high level concept of 'RISC' vs 'CISC'. Not any more.
Well, in this day and age, storage and cpu is essentially free. In the case of a read-only copy of a database you don't even have to back it up (since its already a copy). The customer clearly doesn't want to have to manage a database themselves, they just want to run queries. So you monetize the request and provide the service.
The price you charge the customer will have nothing whatsoever to do with the cpu or storage used by the copy, which is essentially nil, and everything to do with the effort it takes you to set it up and manage it, and beyond that you price the service to what the market can bare for the customer's convenience of access. Sounds like a money maker to me, frankly.
And that is to generate a nightly backup of the database (or even a continuous one-way replication of the database), run it in its own virtual machine, and give the customer access to the backup. It's really that simple. The last thing you want to do is to give the customer direct access to your production database system, no matter what kind of security oracle thinks they can provide it would be a big mistake.
If money (in the form of ridiculously expensive oracle licenses) is a concern, then just create a daily backup and run the copy in mysql for the customer.
This is kinda silly. If there is junk on your laptop you don't want anyone to see, then don't put it on your laptop. Just store it on your home server and download it via ssh after you've gone through customs if you need faster access to it.
-Matt
Need a new system call to really fix this.
on
The 25-Year-Old BSD Bug
·
· Score: 4, Interesting
The problem is that the stdio directory scanning routines cache multiple directory entries with a single getdirentries() system call, but then may try to 'seek' into the middle of that buffer later on.
Any filesystem based on a non-linear-file directory format, such as a B-Tree, will simply never produce consistent offsets or indices within such a buffer.
The only way to *REALLY* fix this is to add a cookie field to the filesystem-independant dirent structure (and if your BSD isn't using a filesystem-independant dirent structure, it needs to be first fixed to do that). lseek()ing to a directory cookie works just fine, and always will (or at least will far more robustly then trying to scan a re-cached buffer from getdirentries()).
When DragonFly went to a filesystem-independant dirent structure I very stupidly only added ~40 reserved bits to the dirent structure, instead of the 64 we need to properly implement per-entry directory cookies. I'm still pissed at myself for that gaff.
In anycase, a per-entry directory cookie effectively solves the problem. The only other way to get such cookies, if it can't be embedded in the dirent structure, is to create a new system call similar to getdirentries() but which also populates an array of directory cookies. FreeBSD and DragonFly have kernel implementations of readdir which supply per-entry directory cookies so it is really just a matter of creating the new system call and then making libc use it.
I caught the tail-end of the bubble memory era, even bought a few chips and played with it, but it became extinct very quickly (probably due to dynamic ram going into volume production just as the TRS/Atari/Apple/Commodore era took off.
Yah. TCP-Vegas is what I modeled net.inet.tcp.inflight_enable on FreeBSD/DragonFly after. I didn't quite agree with Vegas's algorithm so I implemented a somewhat different one, but the result is basically the same.
These protocols work on the transmit side (trying to do the same thing on the receive side is a lot harder). They use round trip times to figure out whether excessive packet backlog is occuring on intermediate routers, and reduce the TCP window size accordingly in an attempt to reduce that backlog.
The feature is very good at dealing with fixed bandwidth constrictions... for example if someone is on a slow speed line (on either side). It is not really designed to handle congestion in the middle of the network. Personally speaking, every server I've ever run turns that feature on. It can be tuned to not be overly conservative and still have the effect of cutting the packet backlog routers have to deal with considerably. E.G. if a router's backlog due to your servers is, say, 40 packets, the feature will cut the backlog down to 10 packets.
What I've noticed the most, particularly since I'm running about a dozen machines over a DSL line (just now switched from the T1 I had for many years), is that packet management depends heavily on how close the packet is to the end points. Packet management also very heavily depends on whether the size of your pipe near the end point is large relative to available cross country bandwidth, or small (like a DSL uplink).
When the packet is close to an end point it is possible to use far more sophisticated queueing algorithms to make the flow do precisely what you want it to do. It's important for me because my outgoing bandwidth is pegged 24x7. Packet loss is not acceptable that close to the end point so I don't use RED or any early drop mechanism (and frankly they don't work that close to the end point anyway... they do not prevent bulk traffic from seriously interfering with interactive traffic), and it is equally unacceptable to allow a hundred packets build up on the router where the pipe constricts down to T1/DSL speeds, (which completely destroys interactive responsiveness).
For my egress point I've found that running a fair share scheduler works wonderfully. My little cisco had that feature and it works particularly well in newer IOS's. With the DSL line I couldn't get things working smoothly with PF/ALTQ until I sat down and wrote an ALTQ module to implement the same sort of thing.
Fair share scheduling basically associates the packets with 'connections' (in this case using PF's state table) and is thus able to identify those TCP connections with large backlogs and act on them appropriately. Being near the end point I don't have to drop any of the packets, but neither do I have to push out 50 tcp packets for a single connection and starve everything else that is going on. Fair share scheduling on its own isn't perfect, but when combined with PF/ALTQ and some prioritization rules to assign minimum bandwidths the result is quite good.
Another feature that couples very nicely with queueing in the egress router is turning on (for FreeBSD or DragonFly) the net.inet.tcp.inflight_enable sysctl. This feature is designed to specifically reduce packet backlogs in routers (particularly at any nearby bandwidth constriction point). While it can result in some unfair bandwidth allocation it can also be tuned to not be quite so conservative and simply give the egress router a lot more runway in its packet queues to better manage multiple flows.
The combination of the two is astoundingly good. Routers do much better when their packet queues aren't overstressed in the first place, only dropping packets in truely exceptional situations and not as a matter of course.
The real problem lies in what to do at the CENTER of the network, when you TCP packet has gone over 5 hops and has another 5 to go. Has anyone tried tracking the hundreds of thousands (or more) active streams that run through those routers? RED seems to be the only real solution at that point, but I really think dropping packets in general is something to be avoided at all costs and I keep hoping something better will be developed for the center of the network.
Slashdot Mirror
Residential inverters have a sweet spot at 2.5KW. His system is considerably larger so some of the quotes might have been with several smaller inverters verses one big one. His system is also a LV (low voltage) system, not a HV system. LV systems are bit more complex due to the higher currents involved.
His system is quite a bit larger then the sweet spot. 2.5KW is usually plenty for a California home which is up to code.
California (where I live too) does give utilities a bye on selling power back, but the total usage is calculated over the entire year, not daily, so you benefit from pushing power back into the grid simply by the fact that you pull it out again at night and (often) offset a cumulative return in summer by your winter use. Frankly, it's a bit of a toss-up as to fairness. There are more costs involved to distributing power then just the power itself. It's not really fair to be able to use the utility's infrastructure as if it that cost were $0 simply because you can produce more power on average then you use. You still need the grid for nighttime and (often) winter days, as well as for rainy or cloudy days.
Nobody in their right mind installs a solar system with a battery bank unless they are way the hell out in the boondocks, or off-grid entirely. Grid-tie systems are really the only way to go if you want to be green. Grid-tie systems have 0 maintainance over pretty much their entire 20+ year life whereas systems with battery storage require maintainance every few years and battery replacement (using *expensive* batteries) every 12 years or so.
-Matt
Light bleaching of solar panels has well known properties. You don't have to physically test a mono or polycrystaline panel for 12 years to know that it will last that long. Or 20, or 25. You can calculate what the degradation curve is and, gee, real life happens to match the curve!
If you are in a windy place then wind will generate a lot more power in less space. Wind tends not to be an option for a home installation, though, your neighbors will take you to court and force you take it down :-)
-Matt
Standard mono and polycrystaline panels easily last 25 years. Yes, there is a drop in the power they produce... light bleeching destroys everything, frankly. But standard panels are fairly resilient and you can count on 25 years with moderate degradation. Really they work forever, they just get less and less efficient. The panels are only half the cost of the whole system. Replacing panels is easy, it's the initial installation that's a bitch.
The new-fangled stuff... solar built into roof material, or drapes, or windows, or flexible plastic... that stuff doesn't usually last very long and usually has horrible efficiency. I wouldn't touch it with a ten foot poll. Go with standard mono or poly panels.
They definitely last more then 2-3. My poly panels have been installed longer then that and I have not noticed any significant drop-off yet.
-Matt
Almost. When converting DC to DC the intermediate stage is only AC in the current domain. The actual forward path voltage never goes negative, and therefore never needs rectification. Basically you have one inductor, one diode, the PWM controller, and a capacitor to filter the output. The diode is not used for rectification purposes (at least, nto the traditional rectification you see in a standard AC-DC converter). In a buck converter it provides a current path when the PWM is switched off, and in the boost converter it allows the PWM switch to short the output of the inductor to build the current up.
Hey, I found two wiki's:
http://en.wikipedia.org/wiki/Boost_converter
http://en.wikipedia.org/wiki/Buck_converter
-Matt
No. You can't just use a step-up or step-down transformer. For one thing, no such beast exists for DC. Transformers can only be used to step-up and step-down AC. Some sort of high-frequency switching circuit (using a transformer and/or inductor, depending) is needed to step-up and step-down DC with any reasonable efficiency.
But even if you could you have to remember that Solar Panels do not put out a fixed voltage. There's a voltage curve based on the load as well as on the amount of sunlight hitting the panel. You can't just use a fixed step-up or step-down ratio and expect to get a usable voltage out the other end.
-Matt
The most common method these days is to tie each string in series and use a high voltage DC inverter. The DC input voltage to the inverter is on the order of 200-600VDC, depending on the setup and the time of day.
HV systems tend to be a lot less complex and more reliable then LV systems. LV systems need a lot more high-current parts internally, need to up-convert the voltage instead of down-converting it (down-converting is easier, always), can't use very many diode-like devices due to the voltage drop, and have harder time managing the maximum power point (MPP), and several other reasons. HV systems are also easier and safer to fuse because the current range is a lot lower... it's easier to tell when you have a short. Just easier all around.
-Matt
It's at least 90%, usually better. For example, the Sunny Boy inverters run 92-96% efficiency, and have for at least a decade.
-Matt
The other problem is simply the stock market itself. Getting 10% a year out of it might be possible over the long haul, but volatility in the time-frame of a decade could give you anywhere from -20% to +20% a year, or worse depending on what you are invested in. Plus if you have to take money out regularly then you have to take profits and you wind up paying a big chunk of those profits in taxes to the government and, depending on your income level, you can even push yourself into a different tax bracket. It isn't cut-and-dry.
On the flip side, it might be possible to take a tax credit for the money spent on the solar system, and if you can manage to spend the money up front it does in fact improve the value of your home and also significantly improves your monthly cash flow. Some people tend to burn their cash reserves regardless of what they think they've saved and burning it on something more worthwhile, like a solar system instead of a vacation, would definitely be an improvement. If you see the solar as a long-term investment then those improvements can, in fact, be more beneficial to you.
In any case, a standard California home does not need a 4KW system. 2KW will do just fine. I have a 2.5KW system and a fairly large house and if I didn't have 12 computers running 24x7 my electric bill would be nearly zero.
You get the most payback by cutting away the top tier electric rate. You hit diminishing returns if you cut away the entire electric bill. A 2KW system costs a lot less then a 4KW system. The best price point for a consumer inverter such as a Sunny Boy is 2.5KW.
I strongly recommend that anyone getting a solar system get it professionally installed. A solar panel system with a high voltage DC inverter setup (~400VDC, typically one or two strings hooked in series), grid-tie (no battery), requires zero maintainance.
Another thing people should consider, even before considering a PV system, is to get a solar water heating system. These don't use PV panels but instead convert sunlight directly into heat (pipes and glass basically). The efficiency is very good and the cost is far lower then a PV system, and will chop off a good chunk of the gas bill from your water heater.
My Solar System
-Matt
I'm the guy that wrote the Diablo USENET news system.
Oops. Guess I know it better then you do!
There's reality, and there's fantasy. The reality is that the signal to noise ratio pretty much nullified the advantages of the distribution mechanic, and the storage and management costs (even with the massive automation we built into the news systems) made it a pain.
It is actually better to use point-distribution containing just the information you care about then to use a highly distributed model where 99.999% of the stuff flowing in is undesired. Only large commercial companies with highly replicative content, such as a cable provider, reaps benefits from that sort of model. Not even internet radio gets much of an advantage. Anyone remember real audio? They were the only ones trying to use a highly distributed model and the internet overtook them.
-Matt
Long live the usenet!
Seriously, though. There are very, very few people left who use the USENET for anything real.
I mean, give me a break, the alt groups were a problem 10 years ago, and some ISPs are still carrying them? That's just stupid. When we were carrying the alt groups at BEST we had to set the article timeout for the high-bandwidth groups to 1-day, and that actually did a pretty good job stopping all the idiots trying to download 5000 part port movies over their dialup modems. They just couldn't keep up before the stuff timed out.
ALT had a signal to noise ratio of 1:1000 10 years ago, I'm guessing its more like 1:50000 now. Only a fool carries it. There are plenty of other ways people can exercise their freedom of speech (and most do, in other ways now).
-Matt
-Matt
Actually this isn't true. Modern TCP protocols will happily use whatever socket buffer space they are configured for, regardless of the latency, and will not reduce it unless they hit congestion control (meaning dropped packets, meaning you have to implement RED on the receiving side and you really want to avoid doing that if you can help it).
But there are TCP moderation algorithms that will detect the link bandwidth (again, the latency is irrelevant) and actually *reduce* the number of packets queued. TCP-Vegas is one such algorithm. There is another implemented in Dragonfly and FreeBSD which can be enabled with net.inet.tcp.inflight_enable. These algorithms are designed to reduce, but not eliminate, packet backlogs at constriction points along the path between the server and client.
These algorithms must be implemented on the *sending* end, however. Doing it on the receiving end is a much harder problem to solve. It is a good idea to enable it on your servers regardless because it reduces the number of packets backlogged on your router (or wherever your bandwidth becomes constricted) and actually improves the router's own filtering/QOS algorithms. If you have a lot of servers behind a router you can easily blow out the router's packet queues with burst traffic if you don't have this sort of feature enabled.
Your only real choice on the receiving end is to force the packet backlog to shift to a machine under your control, which essentially means creating an artificial bandwidth restriction on your incoming packet stream. I discussed this earlier. It is possible to dynamically adjust the TCP window your receivers advertise but I don't know of anyone who has ever gotten good results from doing that, and it is very hard to build an algorithm to calculate the correct window size the receiving end should advertise.
-Matt
IMHO, Cisco has the best packet queueing mechanisms that I know of. I've been using their fair-queue stuff for years, and it has only gotten better with each iteration of IOS.
When I went from a T1 to a DSL line to save some money I immediately noticed the missing cisco. That little 2620 was so nice. PF couldn't hold a candle to what the 2620's fair-queue could do so I sat down and wrote a fair-queue implementation for PF (for DragonFly). It still isn't as good as what Cisco has, but it gets a lot closer then the other PF queuing mechanisms get.
I think the bit I'm missing is the batch classification. My fair-queue can still get overwhelmed by dozens of batch TCP connections if I happen to not be able to classify their traffic (and they wind up on the standard queue instead of the bulk queue). The set-up is a priority queue with minimum bandwidth guarantees plus a fair-queue at each priority level.
I keep hoping someone will take up the flag and finish it.
-Matt
That only works to a point. If you have a single computer you can control the traffic quite well. But if your home network has more then a few computers, all doing different things, PLUS consumer devices such as Apple TV, TiVO, and many other internet-connected devices, the story changes. You will not have control over all the equipment and your only recourse will be active filtering with some sort of queueing mechanic.
Even a home with only computers under your control may not be entirely under your control. If you have a sibling he is not likely going to let you mess around with his downloads.
-Matt
It is always easier to manage uplink bandwidth from downlink bandwidth, simply by virtue of the fact that you control the actual packet queues.
Downlink bandwidth can be controlled in numerous ways. The easiest way is to actually run the incoming packets through a bandwidth limiter with a very large packet queuing capability. This will cause a ton of packets to build up in front of the limiter and eventually fill the TCP windows of the senders. The packets that get through the limiter will cause a stream of ACKs back from your machines at the desired data rate. The combination of the two will cause the remote senders to band-limit the packets they send to the bandwidth you desire.
when running incoming packets through a limiter you still need to traffic-shape/QOS, priority-queue, or priority-queue + fair-queue the packets going through the limiter. If you don't then your interactive traffic can wind up getting stuck in a packet queue with hundreds of packets in it. In addition to that you may have to control the advertised TCP window or even implement RED on your limiter to prevent the hundreds of packets built up in front of the limiter from turning into thousands of packets.
If you can classify the bulk traffic then you can use virtually any queueing mechanic. If you can't classify all of the bulk traffic then the only mechanic that will work reasonably well is, again, going to be a fair-queue.
Fair-queueing is not the holy grail but it is typically the most effective mechanism when combined with another queueing mechanic, such as a priority queue.
-Matt
Traffic shaping and QOS will help a little, but the real problem is simply that you can't afford to delay priority traffic by more then one or two full-sized packets on any connection less then a few megabits (meaning: just about all home interconnects). If you wait any longer then that, it becomes noticeable.
Traffic shaping and QOS are not usually able to make that guarantee. A straight priority queue with bandwidth guarantees can, as long as you are able to actually classify the torrent traffic differently from your other traffic.
Part of the problem is that it is often not possible to distinguish between the batch and the interactive traffic with Shaping/QOS. Not only is QOS almost universally set wrong, but the simple fact is that one can mix interactive and batch traffic over the SAME ports (http, ssh, dynamically allocated ports)and that can make it virtually impossible to use traffic shaping or QOS to keep the mess away from your interactive traffic.
The best general solution is to use a straight priority mechanic with minimum bandwidth settings to separate as much of the bulk traffic out as you can, and then run fair-queueing at each priority level to take care of any that leaks through. This will do a very good job cleaning up the traffic. DragonFly has a fair-queue implementation for PF that does this. There is also at least one fair-queue implementation for PF in the wild.
Fair-queueing essentially classifies connections (the one in DFly uses PF's keep-state to classify connections), generates a hash and indexes a large array of mini-queues. One packet is then pulled off the head of each mini-queue. One enhancement I would like to make to the DFly implementation which I haven't done yet is to use the keep-state to actually determine which connections are batch and which are interactive, and have a parameter that allows the queue to give additional priority to the interactive connections by occasionally skipping the hoppers related to the batch connections. A quick and dirty way to do that is to simply check the queue length for each mini-queue.
In anycase, its a problem for which solutions are available. Regardless of what you use it has become apparent in the last few years that the only way one can classify the traffic well enough to properly queue it is by building keep-state knowledge on a connection by connection basis.
-Matt
For two reasons. First and foremost, low power consumption. Secondly, we have already passed the sweet spot in the storage capacity needed for the applications most people run, particularly on laptops. Add to that the fact that current HD form factors are an extremely good fit for SSD units, and the writing is on the wall.
So what will happen is pretty obvious. Laptops are going to push SSD storage into the mainstream, giving it the critical mass needed to start the research bandwagon rolling, and 5-10 years after that happens hard drives will become the 'new' tape storage and most production systems will be using SSDs.
Even more pointedly, with power costs being the premium concern for data centers these days, and the hard drive being the only thing left in the computer that can't be engineered down to near 0 power consumption when idle (short of spinning it down, which has its own problems), my expectation is that large commercial concerns will see a huge cost benefit to using SSD storage despite the higher front-end cost of purchasing it.
-Matt
There's no distinction between the two any more, and hasn't been for a long time. The whole point of RISC was to simplify the instruction format and pipeline.
The problem these days is that it doesn't actually cost anything to have a complex instruction format. It's such a tiny, isolated piece of the chip that it doesn't count for anything, it doesn't even slow the chip down because the chip is decoding from a wide cache line (or multiple wide cache lines) anyway.
So what does that leave us with? A load-store instruction architecture verses a read-modify-write instruction architecture? Completely irrelevant now that all modern processors have write buffer pipelines. And, it turns out, you need to have a RMW style instruction anyway, even if you are RISC, if you want to have any hope of operating in a SMP environment. And regardless of the distinction cpu architectures already have to optimize across multiple instructions, so again the concept devolves into trivialities.
Power savings are certainly a function of the design principles used in creating the architecture, but it has nothing whatsoever to do with the high level concept of 'RISC' vs 'CISC'. Not any more.
So what does that leave us with? Nothing.
-Matt
Well, in this day and age, storage and cpu is essentially free. In the case of a read-only copy of a database you don't even have to back it up (since its already a copy). The customer clearly doesn't want to have to manage a database themselves, they just want to run queries. So you monetize the request and provide the service.
The price you charge the customer will have nothing whatsoever to do with the cpu or storage used by the copy, which is essentially nil, and everything to do with the effort it takes you to set it up and manage it, and beyond that you price the service to what the market can bare for the customer's convenience of access. Sounds like a money maker to me, frankly.
-Matt
And that is to generate a nightly backup of the database (or even a continuous one-way replication of the database), run it in its own virtual machine, and give the customer access to the backup. It's really that simple. The last thing you want to do is to give the customer direct access to your production database system, no matter what kind of security oracle thinks they can provide it would be a big mistake.
If money (in the form of ridiculously expensive oracle licenses) is a concern, then just create a daily backup and run the copy in mysql for the customer.
-Matt
This is kinda silly. If there is junk on your laptop you don't want anyone to see, then don't put it on your laptop. Just store it on your home server and download it via ssh after you've gone through customs if you need faster access to it.
-Matt
The problem is that the stdio directory scanning routines cache multiple directory entries with a single getdirentries() system call, but then may try to 'seek' into the middle of that buffer later on.
Any filesystem based on a non-linear-file directory format, such as a B-Tree, will simply never produce consistent offsets or indices within such a buffer.
The only way to *REALLY* fix this is to add a cookie field to the filesystem-independant dirent structure (and if your BSD isn't using a filesystem-independant dirent structure, it needs to be first fixed to do that). lseek()ing to a directory cookie works just fine, and always will (or at least will far more robustly then trying to scan a re-cached buffer from getdirentries()).
When DragonFly went to a filesystem-independant dirent structure I very stupidly only added ~40 reserved bits to the dirent structure, instead of the 64 we need to properly implement per-entry directory cookies. I'm still pissed at myself for that gaff.
In anycase, a per-entry directory cookie effectively solves the problem. The only other way to get such cookies, if it can't be embedded in the dirent structure, is to create a new system call similar to getdirentries() but which also populates an array of directory cookies. FreeBSD and DragonFly have kernel implementations of readdir which supply per-entry directory cookies so it is really just a matter of creating the new system call and then making libc use it.
-Matt
I caught the tail-end of the bubble memory era, even bought a few chips and played with it, but it became extinct very quickly (probably due to dynamic ram going into volume production just as the TRS/Atari/Apple/Commodore era took off.
-Matt
Yah. TCP-Vegas is what I modeled net.inet.tcp.inflight_enable on FreeBSD/DragonFly after. I didn't quite agree with Vegas's algorithm so I implemented a somewhat different one, but the result is basically the same.
These protocols work on the transmit side (trying to do the same thing on the receive side is a lot harder). They use round trip times to figure out whether excessive packet backlog is occuring on intermediate routers, and reduce the TCP window size accordingly in an attempt to reduce that backlog.
The feature is very good at dealing with fixed bandwidth constrictions... for example if someone is on a slow speed line (on either side). It is not really designed to handle congestion in the middle of the network. Personally speaking, every server I've ever run turns that feature on. It can be tuned to not be overly conservative and still have the effect of cutting the packet backlog routers have to deal with considerably. E.G. if a router's backlog due to your servers is, say, 40 packets, the feature will cut the backlog down to 10 packets.
-Matt
What I've noticed the most, particularly since I'm running about a dozen machines over a DSL line (just now switched from the T1 I had for many years), is that packet management depends heavily on how close the packet is to the end points. Packet management also very heavily depends on whether the size of your pipe near the end point is large relative to available cross country bandwidth, or small (like a DSL uplink).
When the packet is close to an end point it is possible to use far more sophisticated queueing algorithms to make the flow do precisely what you want it to do. It's important for me because my outgoing bandwidth is pegged 24x7. Packet loss is not acceptable that close to the end point so I don't use RED or any early drop mechanism (and frankly they don't work that close to the end point anyway... they do not prevent bulk traffic from seriously interfering with interactive traffic), and it is equally unacceptable to allow a hundred packets build up on the router where the pipe constricts down to T1/DSL speeds, (which completely destroys interactive responsiveness).
For my egress point I've found that running a fair share scheduler works wonderfully. My little cisco had that feature and it works particularly well in newer IOS's. With the DSL line I couldn't get things working smoothly with PF/ALTQ until I sat down and wrote an ALTQ module to implement the same sort of thing.
Fair share scheduling basically associates the packets with 'connections' (in this case using PF's state table) and is thus able to identify those TCP connections with large backlogs and act on them appropriately. Being near the end point I don't have to drop any of the packets, but neither do I have to push out 50 tcp packets for a single connection and starve everything else that is going on. Fair share scheduling on its own isn't perfect, but when combined with PF/ALTQ and some prioritization rules to assign minimum bandwidths the result is quite good.
Another feature that couples very nicely with queueing in the egress router is turning on (for FreeBSD or DragonFly) the net.inet.tcp.inflight_enable sysctl. This feature is designed to specifically reduce packet backlogs in routers (particularly at any nearby bandwidth constriction point). While it can result in some unfair bandwidth allocation it can also be tuned to not be quite so conservative and simply give the egress router a lot more runway in its packet queues to better manage multiple flows.
The combination of the two is astoundingly good. Routers do much better when their packet queues aren't overstressed in the first place, only dropping packets in truely exceptional situations and not as a matter of course.
The real problem lies in what to do at the CENTER of the network, when you TCP packet has gone over 5 hops and has another 5 to go. Has anyone tried tracking the hundreds of thousands (or more) active streams that run through those routers? RED seems to be the only real solution at that point, but I really think dropping packets in general is something to be avoided at all costs and I keep hoping something better will be developed for the center of the network.
-Matt