This page "Under construction" - last edit 08:30, 29 June 2008.

Booting from CF card (and USB stick)

Changes since early 2002. 

Both HyperThreading and multi-core CPU's mean that Windows 98, which supports only a single CPU (and no HyperThreading, no multi-core), is no longer a 'good' choice for a Node operating system.

At the time of writing (mid 2008), the 'best' choice is Windows XP Professional. This o/s supports 2 physical CPU chips with whatever combination of cores and HyperThreading they support... in effect, this means just about any motherboard (available at a reasonable price) and any CPU is supported.  A Windows XP Pro licence can be had for as little as £10 (if purchased on eBay as part of a broken hardware package 'for spares').

Microsoft seems to have gone back on it's previous attempts to prevent Windows running from a RAM disk and now actively supports this (I assume this due to it's 'virtualisation' efforts). However there is still a 'learning curve' that has to be followed before a Windows XP o/s 'image' can be loaded from a 'server' network share into a Node RAM disk and be made to run.

At the same time, although the RAM requirements of Windows XP is significantly higher, the cost of that RAM has fallen to the point where it can still be afforded. Even so, swapping out the existing Windows 98se Nodes for more modern multi-core HyperThreaded alternatives is a slow and costly process that (in mid 2008) has still hardly started :-)

Changes required to the 'SETI Wall' to support SETI BOINC.

The major hurdle that has to be overcome is switching the Nodes from NetBUEI operation to TCP/IP. This was first achieved using the (single CPU supporting) Windows 98se (before changing over to any multi-core or Hyper Threading CPU's).

Background.

The use of TCP/IP has been forced upon us because of the way SETI BOINC hands out Work Units.

In SETI Classic, wu's were handed out to anyone and could be completed by anyone. This permitted one PC (in my case, the 'server') to fetch multiple wu's and then 'farm out' these wu's to other computers to process (in my case, the Nodes).

Berkley didn't really care what machine processed any individual wu, so long as they got back the results. Since wu's were sent out multiple times (at least 3 times) they expected the same result to be reported from different users - all they cared about was that the results 'agreed' with one-another. Each individual user that reported a completed result got a 'credit' for processing that wu.

Unfortunately this allowed some groups to take advantage of the 'scoring' system .. it was possible to 'part complete' (say to 99%) a wu on one machine and then copy the 'part result' to another .. this meant one person could part complete a unit and pass copies of the partial result to all their friends .. and everyone who then 'completed' the remaining 1% of the wu could report a valid result - and then each and every one of them would get a 'credit' (as if they had done all done 100% of the processing). Since Groups were competing with each other to "process the most wu's", groups (or sub-groups) adopting this 'cheat' were able to out-perform other groups ..

To prevent this type of 'cheating', BOINC identifies the individual computer to which it sends the wu, and each computer is only permitted to process it's 'own' wu's. As a result, it is no longer possible for a central 'server' to fetch wu's on behalf of other computer Nodes.

What is needed for each Node to fetch it's own wu.

The 'internal' Seti-wall network protocol has to be TCP/IP .. this is necessary so that a Node can connect to the Internet and thus fetch it's own wu.

This is only necessary after Windows launches (all the DOS operations can be done using NetBUEI, as at present). Thus, in effect, ALL that is required for the Node's is to change the Windows 'images' that are loaded by the DOS boot-up sequence.

HOWEVER using TCP/IP has implications for the Windows image size - TCP/IP drivers and protocols take up more space.

What is needed for the 'server' to allow each Node to fetch their own wu's.

The 'server' has to pass Node initiated web communication requests 'up stream' to the ISP (and hence the Internet). This requires the 'server' to act as a 'proxy server' ..  and although this is supported by most Windows operating systems, it has implications for TCP/IP addressing ..

Once Nodes are allowed to reach the Internet, plainly the Internet can reach the Nodes .. and thus security (Firewalls, anti-virus), which was previously irrelevant (there being no way for an Internet based threat to reach an internal Net BUEI connected Node), now becomes a concern. However the use of a 'server' proxy allows all Firewall concerns to be dealt with at the 'server' (and thus avoids the need for individual firewalls on each Node).

Changes required to the 'wall' to support multi-core / HyperThreading CPU's

Moving from Windows 98se to Windows XP Pro means that the whole DOS process has to be replaced.

Fortunately modern motherboards support a 'remote booting' process known as BOOTP .. this is intended for 'diskless workstations', and is thus ideal for our needs.

The main drawback is that supporting a BOOTP process is regarded by Microsoft as a "Server level" function - and (if we wish to stay legal) we are forced into buying a Server Operating System Licence. The 'cheapest' available (via eBay) comes as part of a broken PC package "for spares or repair" - - a package with Windows NT 4 Server is approx £15-20 and Windows 2000 Server approx £25-50 (as of June 2008) - the only drawback being that the number of simultaneously connected Node machines is limited by the number of 'Client Licences' purchased (the basic package comes with only 5).

Various 'flavours' of Open Source software also support BOOTP - and are even willing to act as Server 'hosts' for Windows XP Professional 'images', however the steep learning curve involved in understanding LINUX was something I (at least initially) decided against ..

What follows is a description of how to set up a BOOTP Node using a Windows 2000 Server (and then 'disconnecting' so that another Node can make use of the 'Client Licence').