Showing posts with label Research. Show all posts
Showing posts with label Research. Show all posts

Monday, January 23, 2012

Running a Linux Machine Part 1

Running a Linux Machine, 1-21-2012

                My brother swears by this OS (I am not sure which distribution, but I believe it to be Debian) for his personal computers, and I've had to use Linux with a GUI for CS 2308, on the machines in the Derrick CS lab. But I've never installed or managed an open-source OS, and I know very little about what makes Linux unique.
                Unix was the product of research at Bell Labs throughout the 1960s, picking up where the previous MULTICS project had died. When Unix came out in 1969 written for assembly language, it was quickly adopted for some machines, but it received almost no publicity. When it was rewritten in C in 1972, it started to gain attention. After that, it became widely used in servers and workstations. Throughout the 1970s, Unix became ubiquitous because it was simply the most convenient, powerful, and complete OS available. It was adopted in over 100,000 machines by 1984. Still, though, it was proprietary software.
                Linux was a free and open-source variant of Unix developed in the early 1990s; its breakthrough was that it was to be for IBM PC-compatible machines.
                The main design aspect uniting all versions of Linux is a common kernel. The kernel is the most important part of the OS; it is responsible for communicating between hardware-level processes and applications that the user wishes to run. Linux has a monolithic kernel, meaning that all OS processes run in the same kernel space and always as administrator. This approach allows for improved performance due to powerful hardware access by all applications. Conversely, the system's stability is dependent on all system components. A buggy driver could crash the system. However, there have been modules developed which can be loaded by the OS at runtime, enabling a minimum amount of code to run in the kernel space, and greatly improve stability, as well as improving the performance and capabilities of the kernel. Although there still are disadvantages of the monolithic kernel, some developers say that it is still necessary to increase the performance of a system.
Fig. 1. Distinction between monolithic, microkernel, and hybrid kernel OSs.

                The quite rare opposite of a monolithic kernel is a microkernel, which only keeps a minimum of code in the kernel, and delegates the running code to different user accounts. A compromise is a hybrid kernel, which is utilized by most PC operating systems, including modern Windows and Mac OS (Windows prior to 1995 were not really operating systems but just DOS shells). These hybrids are basically microkernels which have some additional non-essential code moved from the user space to the kernel space, in order to improve performance while keeping some of the improved stability of the microkernel paradigm. It's obviously a good fit for home computing, or else they wouldn't have 
                The strength of Linux is that it is low-cost (technically free) and easily customizable, making it a good fit for many applications. A majority of web servers (and virtually all supercomputers) worldwide are run with Linux. Desktop computers lagged far behind in adopting Linux, principally because of its complexity for casual computers users, although this has begun to change in the past few years. There are literally hundreds of Linux distributions; Fedora, Debian, and Ubuntu are some popular groups of them.
                Ubuntu, Linux Mint, and PCLinux OS are all good choices for new Linux users who don’t want to learn all the complexities. If the only concern is stability and reliability, CentOS is a good choice. Fedora and Debian are closest to “middle of the road” for ease of use, functionality, and stability.
                Installation of a Linux distribution is similar to that of any proprietary OS, except that many of them are available as free web downloads, in addition to very low cost CDs. I am really not an expert on Linux by any means, but I think I would lean towards Debian installation because of how well-tested it is, resulting in stability and security. It also supports more architectures than any other Linux distro, and has a huge variety of software packages available. There are several graphical and CLI front-ends available.
                Actually, even though I’ve never done a Linux installation and they have a reputation as “geeky” among the uninitiated, it looks like there’s an incredibly detailed set of instructions and guidelines for installing and setting up the system:
                http://www.debian.org/releases/stable/amd64/
               
Other consulted sources:
http://brinch-hansen.net/papers/2001b.pdf      A history of operating systems
http://www.vmars.tuwien.ac.at/courses/akti12/journal/04ss/article_04ss_Roch.pdf    Monolitich                                                                                                                                                               kernels vs. Microkernels
http://distrowatch.com/                                              Information on different Linux distributions


Friday, January 20, 2012

FPGA Capabilities and Concepts

FPGA Capabilities and Concept 1/20/2012

                I believe Dr. Aslan also wants to use his server’s NetFPGA capability for experimentation. In DSP, our prototyping board will be a Xilinx FPGA board.  In this report, I begin research about NetFPGA (beginning with an introduction to FPGA, although I am not highly familiar with it yet) and some about networking in general.
A general-purpose microprocessor has pre-programmed hardware with an instruction set that is immutable and must be obeyed. By comparison, FPGA (“field programmable gate array”) is a form of integrated circuit where the dominant component is interconnect which can be modified into gates by the user. Although some logic components may be present, the user can define many of them using a hardware descriptive language such as VHDL or Verilog. The fact that the behavior of its hardware can be reprogrammed is a compelling advantage of this architecture.
However, FPGA is a recent phenomenon compared to CPUs or its predecessor, ASICs. The very first patents related to programmable logic gates were granted in 1985. By the early 90s, the market was still very small, but by the end of the decade, it was in the billions of dollars. Present-day technology allows for millions of programmable gates.
The NetFPGA architecture is a method of using FPGA to create a networking tool such as a router. The task of using NetFPGA to create an IP router is a common one seen in various academic institutions; approximately 2200 of these boards have been deployed. To start, here are some links I consulted to arrive at the research in this report:
In 2009, I was employed for a few months in DSL tech support (for a local firm called teleNetwork) and we had one week of training, which I do remember being a bit frenetic. I am certain that I learned some information about the theory behind the internet and networking in general, but most of it has left me.
What is a router and how does it work? Routers are pieces of hardware that send and receive data packets between computer networks. A data packet is just a quantity of formatted data. (it is distinct from simple, bit-by-bit transfer on point-to-point networks). The data is sent in octets with a header followed by a body. The header is the forwarding information, while the body is the actual data.
Internet Protocol (IP) is the set of design principles for sending data packets over internetworks (collectively referred to as the internet). The Internet Protocol suite is abbreviate as TCP/IP (Transfer Control Protocol/Internet Protocol) because it contains another protocol (TCP) which controls the flow of information via IP, makes requests for lost data, and orders the transmission so that transfer is maximized.  
I used to work in DSL tech support and I vaguely remember some of the levels of distribution that are involved. The idea of the internet goes back to the ARPANET of the early 1970s, which was designed to connect existing small networks nationwide, and allow survivability of the whole network even if huge portions of the country were destroyed in nuclear war. Privatization of internet access occurred in 1992, and by the turn of the millennium, most Americans had access to internet, either at their residence, at work, or in libraries, schools, or universities.
Nowadays the common home internet setup includes a DSL modem and a router, or an integrated setup called a gateway. A digital signal that contains the requested information is sent (modulated)  over the phone line. A modem will receive (demodulate) the signal.  The purpose of a router is to distribute an incoming signal to a network, which implies multiple machines.
NetFPGA is available in 1G and 10G speeds. The former has a standard PCI form factor and a quad-input gigabit Ethernet NIC.

Fig. 1. NetFPGA board

The makers of NetFPGA claim that because the datapath is entirely implemented in hardware, it is capable of sending back-to-back packets at full gigabit speed, with processing latency of “just a few clock cycles”. It also has enough onboard memory to allow full line rate buffering.
NetFPGA.org has a set of detailed tutorial videos which describe the product and the uses of it:
VIDEO 1: INTRODUCTION
There are three basic uses of the NetFPGA architecture
1.       Running the router kit to achieve hardware acceleration.
An unmodified Linux machine can use the “hardware accelerated Linux router” or router kit to achieve this. It uses one program called RKD (Router Kit Daemon) which monitors the Linux routing table and allows the user to modify the route table using standard commands. If the routing software uses the NetFPGA interface for forwarding, hardware acceleration is provided without any further modifications.

2.       Enhancing existing reference designs.
The reference designs provided include 1)Network interface card (NIC); 2)Ethernet switch; 3)IPv4 router; 4) hardware accelerated Linux router (discussed above); 5) SCONE (Software Component of the NetFPGA), which uses a protocol called PW-OSPF to handle exceptions to the hardware forwarding path..  The reference designs for the NetFPGA 1G board have a pipeline of Verilog modules which can be augmented using the NetFPGA driver. If the user wants, he could create a GUI in this way to visualize the functionality of the NetFPGA hardware.

3.       Building entirely new systems.
Using Verilog or VHDL to design, simulate, synthesize, and download to the board. Not all projects are an adequate fit for existing reference designs. This is more involved than just adding modules on reference designs.

                In addition to the provided material by the NetFPGA organization, there have been contributed designs by companies and universities, including an openflow switch, packet generator, zFilter router, and a DFA-based regular expression matching engine. There is also a wiki and forums on the website.
                The NetFPGA, as labeled by its manufacturers, has two defining features.

I.                    It is a line-rate platform. It can be used to process back-to-back packets, operate on packet headers, including switching, routing and firewall processing. It can also be used for content processing and intrusion prevention of packet payloads. 
II.                  It is open-source hardware. This is similar to open-source software in that all source code is available and has a BSD license. But it is considered more difficult than a software project because hardware components must meet timing and may have complex interfaces. All levels of design must receive adequate testing to ensure that they have consistently correct and repeatable results.

VIDEO 2: HARDWARE
                the NetFPGA architecture contains a Xilinx Virtex II Pro 50 FPGA  with 53,000 logic cells. It also contains block RAMs and two embedded PowerPC processors, enabling higher-level languages to be implemented as well.
                The board also has four onboard RJ-45 gigabit Ethernet ports.
                Onboard memory includes 4.5 MB SRAM (for storing forward table data) and 64 MB DDR2 DRAM (for packet buffering).
                Board has a standard PCI connector to interface with host PC. There is also SATA connectivity, which might be used for connecting multiple boards.
                All reference designs were tested on 32-bit and 64-bit systems. In order to make one’s own designs, one needs to have Xilinx ISE and ModelSim. There are complete prebuild systems (lacking the NetFPGA card) such as the NetFPGA “Cube” (desktop) and rackmount servers, suitable for high-density and high-performance servers.

VIDEO 3: NETWORKING
                Because the NetFPGA uses Ethernet, it places packets within Ethernet frames. IPv4 headers have many fields, including the version field, source and destination fields, TTL (time to leave) field (counter to prevent data being circulated endlessly), header checksum field (makes sure that the header is not corrupted).
                A simplified view of the internet can consider just routers and hosts. The routers forward traffic between hosts. Between two hosts, one host creates a packet with the appropriate header defining where the data is to go (IP address) which is sent to the router connected to that host. The router will consult the forwarding table to find the best place to send it next. Each router will pass the packet along in the same way until it has reached its destination.
                IPv4 addresses have 32 bits, which allows for 4 billion unique addresses. The naïve approach is to simply create a forwarding table with billions of entries, and although this is possible with current memory density, it would make routers more expensive and it would make updating the table extremely costly and time-consuming.
                The actual method routers use is to use grouping. Grouping will place hosts thatare “close” to each other (in terms of the steps required to reach each other) by grouping blocks of IP addresses by closeness. There will still be matching entries for close, but not identical, IP addresses.  The forwarding tables can be improved by sorting the entries from most specific to least specific.  Doing a linear search on the forwarding table will thus always provide the most specific entry first, resulting in the best possible match.
                Going beyond the forwarding table, there is a switching element to send data to the correct port. Further in line there is a queue which buffers the data to be sent. The routing protocol will then determine more closely the topology of the network, and find the shortest possible route to the destination. The routing protocol will update the forwarding table, and maintain a routing table, which is more detailed than the forwarding table. There is also manual control available by CLI in a “management” block.
                 Grouping together only those which are responsible for forwarding traffic (forwarding table, switching component, queue) maybe called the data plane, which processes every packet through the router. Data plane is implemented in hardware.  The other elements can be grouped together as the control plane, which is much slower than the data plane. Control plane is implemented in software, and is more complex than the data plane. As concerns the NetFPGA, the control plane is carried out on the host computer, and the data plane is implemented on the FPGA. For the FPGA, instead of a forwarding table, switching component, and queue, these repsonsibilities are carried out by an “output port lookup”, “input arbiter”, and “output queues”, respectively. NetFPGA includes two versions of the control plane: SCONE and the router kit (which doesn’t actually implement in software but in hardware).
VIDEO 4: REFERENCE ROUTER
                The reference router uses FPGA hardware to achieve the functionality of the data plane. The control plane can be managed by SCONE and a Java GUI. The GUI is not strictly necessary but it makes understanding the routing table much easier.
In this example, the lecturer considers a setup of 5 computers with NetFPGA installed. They are not all connected to each other, but all of them are in the network. If one wants to stream video from one computer to another, the NetFPGA will use the router kit to stream the data along the shortest path. If a link on the shortest path is broken, the video will continue to play for a few seconds from buffered data, and then stop. The SCONE will talk to other computers on the network and recognize that the topology has changed. Each SCONE will update its routing to reflect this changed topology. Each one will consequently find the next shortest path which is available, and resume the streaming. When the broken line is reconnected, SCONE will update the routing table and resume streaming via the shortest path, albeit without interruption of the video this time.

VIDEO 5: BUFFER SIZING
                The router reference design can be modified to experiment with buffer sizing. Buffers are needed in routers to handle congestion, internal contention, and enable pipelining. Congestion buffers are the largest and most important. Congestion happens when a router is receiving packets at the same time. The buffer will hold as many as possible in the order they arrived, and drop those that simply cannot fit. The “TCP sawtooth” refers to a drop in the TCP window size (number of outstanding, unacknowledged  packets) corresponding to when a packet is lost. Buffers must be sized large enough to absorb the variations in the traffic arrival rate and ensure a constant departure rate equal to the output link capacity.
                Most commercially available equipment cannot modify buffer sizes as needed to experiment and come up with ideal sizing for the network demands.
                With NetFPGA you can adjust the buffer sizes, capture packet events (add a module for this), and rate-limit a link (also needs a new module) to experiment with buffer sizing.  They add modules for a rate limiter and event capturer. Then they use the Advanced Router GUI script to activate the rate limiter and event capturer to log the packet drops. The generated output is the “waveform” of the TCP window size against time (as packets are received).
VIDEO 6: WHERE TO GET STARTED
                Mentions resources available online as well as a hands-on teaching session available biannually at Stanford or Cambridge, for prospective users to be trained on FPGA and perform a project.
PROJECT VIDEO 1: BUFFER SIZING IN INTERNET ROUTERS
                Review of purposes of buffers. Common buffer size of a router with 10G link is 1 million packets. The rule of thumb is that Buffer size = RTT*C.
RTT = (average two-way delay between traffic sender and receiver)
C = (output link bandwidth)
                Larger buffers will be good for reducing the number of packets dropped, but oversized buffers are undesirable because of the higher complexity, more queuing delay, cost, and power consumption associated with it.
                More than 90% of internet traffic is TCP, which has a closed-loop congestion control mechanism. TCP controls transmission rate by modifying “window size”. If there are a larger number of TCP flows, the buffer size required becomes smaller. If the number of flows is great enough, the buffer size can be reduced by a factor of the square root of the number of flows without damaging throughput. With 10,000 flows, the required buffer size could be reduced to 10,000.
                This could be reduced even more on fast backbone networks that are connected to lower speed networks. The buffer size in this case could be lowered to the order of log(W) where W is the window size. It does not vary with number of flows.  In this example, 20-50 packets would be enough for 90% throughput, rising to nearly 100% by 10,000 as before.
                NetFPGA’s buffers can be changed with extreme precision (1 byte at a time, if desired). The lecturer goes on to demonstrate the event capture software by showing how one can manually tune the buffer size and the number of TCP flows over a network, and have the system automatically create data points for the 99% throughput rate for a given flow number and buffer size. In the case of their example, with 200 flows, just 20 packets of buffer space is required.
PROJECT VIDEO 2: OPENPIPES- HARDWARE SYSTEM DESIGN WITH OPENFLOW
                OpenPipes is a tool that will distribute complex designs among several subsystems, for example FPGAs and CPUs. OpenFlow is a tool that gives the user control over routing traffic through the network. A controller for the switches could be implemented in an FPGA, ASIC, or even CPU.
                OpenPipes is capable of testing assistance, by simultaneously testing the implementation of a software and hardware design, and feed the results into a comparison module that verifies the results are the same.
                In an example, the lecturer shows how OpenPipes allows the user to modify a running system by changing the flow tables inside the system. OpenPipes has a GUI that can display all the available hosts and switches on the network. From one location (say, Stanford) one could download hardware modules from the local host to the locations in Houston and LA. This software enables hardware on different physical machines to be utilized at the same time.
                In summary, the OpenPipes platform can perform the following functions:
1.       Partition a design across resources
2.       Modify a running system
3.       Utilize a mix of different resources
4.       Assist in the testing and verification process

                

Wind Turbine Research, Day 1

An initial look at braking systems and blade design on wind turbines
1/18/2012

Summary

                It is theoretically possible to power a small office using 3 small wind turbines and a storage battery. The battery should be fairly large to guard against long bouts of windless weather; at this time I think something like a 130 Ah, Group 30 Trojan deep cycle battery should be suitable, for under $200. As for braking, I haven’t yet seen an ideal breaking solution, but comparing dynamic and frictional braking techniques, I think a dynamic braking resistor would be helpful. I have seen examples of software used to design ideal aerodynamic surfaces (like HyperSizer for very large turbines), but not yet come up with an idea to improve the blade design.

Problem

                A wind generator will produce power continuously, but demand is not necessarily continuous, so a storage battery is desirable to accumulate charge. The SolAir wind generator we are using can provide 12 V or 24 V. We have chosen to use a 12 V to 120 V inverter (producing AC from DC) so we should get a 12 V battery which is capable of being heavily charged and discharged.
                I found that the braking system on a wind turbine is crucial for all but the most trivial applications. Large wind turbines have extremely long blades (perhaps 50 m diameter) and although the rotational velocity might be small (20 rpm) the tip speed at the edge of the blade might be 200 mph. A small wind turbine (like the SolAir generator that we are using) has blades about 2 ft (61 cm) in length, the potential rotational velocity is much higher (manufacturer says that in high winds, it could exceed 1000 rpm, although this might be exaggeration). Furthermore, the blade is made of aluminum and has a very flat edge. When this blade is at speed, it is very capable of cutting off children’s limbs or killing birds that fly into it.
                Although the behavior of birds is hard to predict, it is desirable that even a small wind turbine have braking capability, even if mounted high above where children can reach it, if only so that when the turbine must be serviced, it can be done safely.
                Most large wind turbines achieve maximum efficiency at higher windspeeds; 33 mph (15 m/s) is common.  Most wind power stations cap the speed allowed at 45 mph to stop the blades moving so fast that they overcharge the battery.
                Because 33 mph is a pretty stiff wind, it is probable that the wind turbine will operate mostly at less than max power output. The blade design should not be a weak point. It should catch as much productive wind as possible.

Theoretical Limits

                 The theoretical maximum efficiency of a wind turbine is 59.3% as calculated by Albert Betz in 1919. That is, 59.3% of the kinetic energy of the wind can be turned into kinetic energy of a plane incident to it (the spinning blades). Since the electric generator is very efficient (over 90%) the max real efficiency is still over 50%, which would be enormous. The finality of the Betz limit (59.3%) casts doubt on the company's claim that this device is capable of converting up to 70% of the wind’s energy to electricity. But perhaps that figure includes the energy provided by the supplemental photovoltaic cells.
                Unfortunately, the wind is constantly changing direction and magnitude, so it’s extremely difficult to find the actual kinetic energy present in a quantity of air. What is more often done is list the capacity factor, which is a metric normally reserved for power plants to describe what percentage of their namesake power (say, a 1000 MW power plant) is actually produced in a given period of time. For baseload power plants, the percentage is generally above 90% as the demand for their power is continuous and predictable. For wind power plants, the capacity is generally much lower, at 25%, owing to the fickleness of the wind. So a wind generator which lists a possible 2 MW could only produce in the neighborhood of 250 kW in sustained operation.
                If we take 25% as a reasonable benchmark, then three 800W solar generators produce a net 600W continuous output. The demands of our office (one desktop computer, one server, fluorescent lighting, and perhaps other rarely-used testing equipment) will not be static, but vary throughout the day. Theoretically, if the server and computer were both at max power (400W apiece, say) they would be consuming more power than the wind generator could deliver. But unless engaged in heavy computing, they would not be using anywhere near that amount of power. For moments of peak demand, the battery would simply discharge slightly until demand once again was reduced. Assuming that the electric generator on the turbine and the inverter to get AC power from the battery are both very efficient, (>90% efficiency) the wind turbines would theoretically be able to power the office.
                 
Possible Solutions

                Car batteries are generally “starting” batteries, with very high cranking amps but very low tolerance for discharge. They are a poor choice for storage and are suitable only when continuously kept at >80% charge.
                A better option is “deep cycle” batteries, which are designed to be discharged more completely. They do have less cranking amps than a starting battery, and are costlier, but they are a decent choice for energy storage. A popular measure for storage capacity is “reserve capacity”, which states how long the battery can be discharged at a certain current drain. A more general one is “amp-hours”, which states the product of current and time for which the battery can discharge. Deep cycle batteries with 25-50 Ah are available for less than $100. On balance, I think going for a bigger battery would be better than building up from smaller batteries if the need increases. A 130 Ah Group 30 deep cycle battery from a maker called Trojan is available for less than $200.
                There exist many methods of causing the blades to stop. They can broadly be defined as frictional braking and dynamic braking.
Physical braking is possible by including a disc (or rotor) rotating with the rotor shaft of the blades, which would be stopped by friction surfaces pressed into it by hydraulic cylinders. This is exactly the principle of what stops a car. Low-cost off-the-shelf small disc assemblies are available by many tool and hardware companies for under $100 but most are designed for trailers, and are relatively heavy. The best option here would be mechanical disc brakes, designed for very light vehicles such as power chairs and scooters. I note that there are such calipers (with pads already in place) for about $25 on websites. The rotors themselves are sold separately for as little as $36.50, meaning that a complete braking solution could cost $60 per turbine. The provided mounting hardware might not be suitable for fitting to a wind turbine, as these were meant for wheels, but if needed we could fabricate a mount from bolts and plates available at any local hardware store for little cost. Although I have not yet done any calculations to the effect, I believe that if these little brakes can stop a scooter with a 150-lb occupant, they can stop an all-aluminum turbine.
                If it is found to be cheaper to use drum brakes than discs, these could also be mounted on the shaft in the same way, and achieve braking in the same way using a wheel cylinder. But unlike in passenger cars (where drum brakes are sometimes still used because they are cheaper), it seems that drums are not any cheaper. In my experience (I worked in a brake shop for four months), drum brakes are also significantly more difficult to service.
                I have some worries about using physical brakes, since any additional weight on the shaft could cause imbalance and would increase the inertia of the spinning shaft, making the precious little energy available from the wind become harder to catch. Although we would mount the caliper on a stationary bracket, the disc would have to be spinning with the shaft. The same issue would creep up for drum brakes as well. An issue with all mechanical brakes is that they need to be physically engaged by a user, which might not be feasible from a distance. A hydraulic brake could achieve the action at a distance by pressing a button or pedal of some kind, but if a hydraulic caliper is needed, it will be even heavier and yet more expensive.
                Dynamic braking is based on electrical principles. Freak gusts can cause the blades to easily spin too quickly for the generator to allow. To slow down the turbine when the battery is full, the power can be redirected to a dynamic braking resistor which will absorb the electricity being produced by the kinetic energy of the blades as heat. This is a safe way to restrict speed and is widely used in the industry. In order to bring a small wind turbine to a sudden halt, it is possible to simply disconnect the battery and short the terminals of the generator, permitting no voltage between them and bringing the shaft to a big halt. I have read mixed reports on the success of this. Some say that it is perfectly safe for small wind turbines, but some say it is always damaging to the generator and should never be attempted.  Microlog Technologies produces an “electric brake panel” that does exactly this kind of braking. Dynamic braking has been described as more reliable than frictional braking, which has moving parts that can fail and need to be replaced.

Some helpful links:
http://www.gokartsupply.com/discbr.htm                         Disc brake assemblies
http://www.micromediaplus.com/microlog_wind_brake.html                 Microlog Technologies: electric brake panel
http://www.windmission.dk/workshop/BonusTurbine.pdf        Very broad article on wind turbine operation and construction
http://www.reo.co.uk/files/dynamic_braking_resistors_02-08_engl.pdf                             REO dynamic braking resistors



Getting back on track

I've looked back on all these blog postings and it just occurs to me that for having intended this to generally focus on technology, I've really mostly just talked about cars and political things. Shame on me! Those things interest me during my free time, but as this new semester (and my last year of undergrad, hopefully) commences, I really need to stay on topic more than ever. Hopefully my blog can help me do this.

So most of the coming posts for the next few months will concern engineering, computers, electrical theory, and all that fun stuff. They will be tagged "Research"; every article with the label "Research" will simply be the product of my research for Dr. Aslan and my own passion for knowledge. I will post everything here. The projects we have on our plate are not totally specific yet, as he seems to have just given me a lab and free time (for which I will be in the employment of Texas State University) but I'm nailing down our main two goals as best I can.

1. Assembly and placement of three small 800W wind generators (with onboard photovoltaics) and an inverter and power storage system. The inverter and wind generators are already bought and with little assembly required. My unique design contribution will be the power storage system and braking system. He has said his ultimate goal is to take our lab off-the-grid and power it just by wind. Pretty specific goal.

2. Implementation of a server with NetFPGA chip for performing networking experiments of some kind. Very unspecific goal at this time, but it should be fun when we get it running.