Beware of QAFF CPU on X79 platform

This article is probably not very relevant anymore, considering the age of the platform and rarity of the CPU, but nevertheless, it can be useful for historical purposes or if someone happens to have the CPU mentioned below. Back in 2012 I bought X79-based Sandy Bridge-EP platform (based on ASRock X79 Extreme4-M motherboard) together with the engineering sample CPU having a QAFF S-Spec (supposedly 4-way Xeon E5 which doesn't have corresponding production item). Though the CPU was recognized by the motherboard and system initialized successfully, over time however, it proved to be quite unstable and stressful to use. Two main issues were:

• Initial system boot and even reboot process could randomly freeze with a different number of BIOS beeps or motherboard boot status codes (Extreme-4M has a specific LED indicator for them). Probably the most common final code before freeze was 0x67 - CPU DXE initialization (CPU module specific). I believe it could have been RAM detection/initialization issues. Unfortunately, I couldn't find any pattern to reproduce the failure consistently.
• PCI-E graphics cards with v3.0 specification (possibly v2.0 as well) lead to the failure of the OS boot process into graphical environment (Windows 7, Gnome on Manjaro Linux, etc). Reducing PCI-E mode to version 1 in BIOS settings was partially solving the issue by stabilizing the boot process. In this case however, the system had an occasional performance degradation and/or random lockouts. I was using Radeon RX460 graphics card, but I found a MSI forum thread confirming the similar issue with different graphics cards (including AMD and Nvidia models).

The first issue is hard to investigate because of its inconsistent behaviour, however, the system usually worked better with two RAM modules instead of four, in my experience. Shuffling RAM modules between slots occasionally was solving the issue, but temporarily only.

The second problem was easier to identify since the problems started soon after I replaced older Radeon 2400PRO based graphics card with more modern Radeon RX460 one. Windows boot process locked out immediately on first reboot after AMD drivers were installed. Linux boot process froze as well on loading display server (X.Org). In both cases, the only way to continue was to reset the system. By default, BIOS was selecting PCI-E v2 for the graphics card. Reducing PCI-E to version 1 helped to load the desktop environment in Linux but system performance was unstable up to complete system lock out. Windows was still crashing regardless of the PCI-E mode set in BIOS. Explicitly setting PCI-E v3.0 in BIOS was rendering system unbootable until CMOS was cleared. It seems v3 was either not supported by CPU at all or it didn't work in combination with my motherboard.

X79-based systems are already considered legacy since long ago and it is not very likely that someone will decide to build it these days, especially with a quite rare engineering sample CPU. In this case though, my recommendation is to avoid QAFF S-Spec CPU and choose many other options supported by the motherboard.

Network aggregation project on Jetway JNF76 motherboard

Prehistory

Since my NAS revival project last year, I already had in mind to try the link aggregation feature, which was supported by my router. Initially I expected simply to pair up integrated Realtek RTL8111C NIC controller with Intel PRO/1000 GT PCI adapter as I already had one in the pile of my parts. For this purpose I even bought an Akiwa GHP-PCI106H PCI riser card (I use their GHB-B05 case) which wasn't so trivial to find - it was available in several industrial PC online shops only and, because they communicate exclusively with the juridical entities I needed to go through an intermediate party to buy it. When everything was ready, I believed that it would be a relatively straight forward setup. However, it ended up in a quite longer story than expected.

Akiwa GHP-PCI106H PCI riser card

Initial plan failed

The aforementioned configuration failed immediately after I attached the PRO/1000 GT adapter. I hit an old JNF76 motherboard BIOS issue that expansion cards with their own firmware may clash with ADPE4S-PB SATA II daughterboard, rendering the system completely unbootable. Intel's card had one with PXE boot support. This limitation have never been fixed by Jetway, thus I have no knowledge of any solution to resolve the situation. Unfortunately, it was clear that this configuration was a no go.

Intel PRO/1000 GT PCI network adapter

Looking for new solutions

One hiccup didn't deter me from completing the project though. It pushed me to look for other possible options to go around the limitation. Most likely the simplest way would have been to find another NIC adapter which wouldn't clash with the daughterboard. That meant buying the card without PXE boot support. As a proof of that, I have successfully tested an old VIA based Fast Ethernet (100Mbps) PCI network adapter. Indeed, it didn't clash with ADPE4S-PB on BIOS POST process and it was perfectly working in the Linux environment. Although this option looked quite appealing initially, there were few Realtek based GbE adapters in the market, however their description tended to be vague at times and I felt that I may have ended up buying yet another incompatible card. More than that, the whole link aggregation idea was also a bit risky and it might have left me with the second GbE network adapter buried deep in the pile of old parts. Because of all of this, it made me rethink of the NAS configuration a bit, which would solve another outstanding issue.
 

ADPE4S-PB SATA II controller

Reasoning for ADPE4S-PB replacement

The main reason for the configuration change was the same ADPE4S-PB daughterboard. Besides those clashes with expansion cards and a bit of challenging configuration, I was also experiencing another very annoying issue with it. I used this controller to attach SSD with the host OS only. Relatively soon after I made it work and boot the system, I started to face unstable behavior during the Linux boot process. From time to time Arch Linux was failing to initialize the SSD, forcing me to the reset loop till the successful attempt. Few times I was spending up to an hour on clicking reset button... I haven't figured out the actual reason for this, but it could have been everything from the driver to the bad cable connection (my SSD's SATA plug is physically damaged) or improperly attached daughterboard. It led me to the decision to replace ADPE4S-PB board with the LAN expansion daughterboard instead. I chose an AD3INLANG-LF module which hosts three Intel 82541PI based network controllers, the same used by PRO/1000 GT adapter. It was readily available through amazon but I required some help from a friend in the US to deliver it to Europe. For an SSD drive I decided to use my old Delock PCI USB/SATA combo card.

AD3INLANG-LF daughterboard

Inserting AD3INLANG-LF daughterboard

Since I attached the SATA daughterboard many years ago, I already forgot how actually tricky is the process of inserting it to proprietary JWDB header. For some weird reason Jetway doesn't provide the manual and you can find that at least a few people are complaining about the attaching process in product reviews, blog items or forums, some taking even quite extreme measures to make it seat properly. If it's not, the daughterboard either will fail to work completely or it can even light up (for example, green light on LAN port if cable is attached) but non of the interfaces will be identified or initialized in the OS or BIOS. Nevertheless, the actual process shouldn't require much force, using the trial-error approach, I have managed to insert it properly by aligning inner pins (means the ones closer to CPU side) with the plug holes on the daughterboard in a 30-45 degree angle and sliding it in a circular motion and a slight force into the second row. You can actually feel a small resistance when it goes into the header. Once properly seated, you can even try to lift it up gently, it shouldn't move out of place or fall to any side from its own weight. Also, you can check pins under the daughterboard: they should be evenly aligned on both sides and almost touching the header's plastic.

JWDB connector on ADPE4S-PB daughterboard

Finally, you can enter BIOS setup and check if three new boot ROM options for LAN interfaces (Addon Intel Lan1 to Lan3) appeared in the Integrated Peripherals -> Onboard Device Function section (not sure if it appears for Realtek based daughterboard as well). In case of SATA daughterboard, it would show it's own BIOS screen for the RAID setup.

New entries in BIOS after inserting AD3INLANG-LF daughterboard

Delock PCI USB/SATA combo card

89140 Delock PCI card combo USB2.0/eSATA/ATA has 1xSATA, 1xESATA, 1xIDE and 4xUSB 2.0 ports. SATA/IDE is based on VIA VT6421A SATA RAID controller and USB 2.0 is managed by VIA Vectro VT6214L USB host controller. Similar to the Marvell controller on ADPE4S-PB daugtherboard, VIA VT6421A doesn't have a built-in support in Arch Linux and requires to load additional kernel module. Some resources were mentioning satavia name, however Arch Linux uses sata_via with the underscore. So I modified the /etc/mkinitcpio.conf file by adding sata_via module to MODULES=(sata_via) line and regenerated initramfs (mkinitcpio -g /boot/initramfs-linux.img). After the reboot, the controller was successfully recognized and it was now possible to boot the OS from it. The USB controller was recognized without any additional configuration though, but it doesn't support loading OS from it (at least, not on JNF76 motherboard). Although, it may seem as a drastic downgrade to already subpar SATA II controller but an SSD performance is still significantly faster than any USB 2.0 flash drive I have used before for the same purpose (it reaches ~80MB/s for writing and reading from my testing). Most importantly I haven't faced SSD initialization issues with it which saves lots of headache on system reboot process. Unfortunately, I can't make a comparison to ADPE4S-PB as I have never done or recorded performance tests for it and I realized that after finishing my current setup only. As mentioned in the previous chapter, reattaching modules is quite a complicated and time-consuming process, so I am not keen to do it just for testing purposes.

Delock PCI USB/SATA combo card

AD3INLANG-LF speed test without link aggregation

As described previously AD3ILANG-LF daughterboard consists of three Intel 82451PI Ethernet controllers. It is a 32-bit 3.3V PCI 2.3 based controller, which supports 33MHz and 66 MHz speeds. Controllers were identified as GI version instead by Linux (the difference is the manufacturing stepping of the controller, where GI is manufactured in B1, PI in C0 stepping). lspci -v output for one of the controllers can be seen below:

04:04.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
      Subsystem: Intel Corporation PRO/1000 MT Network Connection
      Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18
      Memory at dfac0000 (32-bit, non-prefetchable) [size=128K]
      Memory at dfaa0000 (32-bit, non-prefetchable) [size=128K]
      I/O ports at 9c00 [size=64]
      [virtual] Expansion ROM at dfa00000 [disabled] [size=128K]
      Capabilities: [dc] Power Management version 2
      Capabilities: [e4] PCI-X non-bridge device
      Kernel driver in use: e1000
      Kernel modules: e1000

While my external Intel PRO/1000GT card uses a 33 MHz interface, all three controllers in the daughterboard are attached to the 66 MHz PCI. Many years ago I thought that Jetway proprietary interface is just a modified conventional PCI but apparently it is bridged to PCI-E interface which allows to combine few PCI interfaces under one connection.

I tested the speed of copying one 1.6 GB size file through samba 4.8 (Arch Linux to Manjaro Linux). My main computer was using 10-Gbit Tehuti 4010 PCI-e x4 rev2 based controller (Edimax EN-9320SFP+) connected to the same router as the NAS server (using 10G SFP+ DAC cable). The hard drive in use was portable Transcend Storejet 500 SSD drive connected to USB 3.0 port (internal reading speed 6.9 GB/s, writing 2 GB/s). On the NAS side TOSHIBA DT01ACA300 3TB hard drive was attached to native VX800 SATA II controller without any RAID setup (reading ~137MB/s, writing ~98.5 MB/s). Both systems were using ext4 filesystem:

Integrated (Realtek) interface: 53.8 MB/s

Inner (left) interface: 80.7 MB/s
Middle interface: 82 MB/s
Outer (right) interface: 80 MB/s

The left and right interfaces of the daughterboard were showing quite a similar constant ~80MB/s speed, while the middle interface was minimally faster at around 82 MB/s. Integrated RTL8111C interface was copying file at 53.8 MB/s speed.

Edimax EN-9320SFP+

Link aggregation

Finally it was the time to setup link aggregation. I enabled the 802.3ad link aggregation feature on my router and was ready to start NAS configuration. However, once I thought that the worse times were behind, I stumbled onto bonding driver configuration issues which led me to try link aggregation on the NetBSD first.

NetBSD

Since I wanted to confirm that my Linux configuration struggles were not caused by the router, I checked if NetBSD supports link aggregation. It appeared that it does and the setup process is relatively easy. As I always have installed NetBSD system on the WD Elements Portable (10A8) USB hard drive (NetBSD 8.0 at the time of testing), I just plugged it in to the system's USB port and booted from it. Thankfully, the system loaded without any issues, but was just relatively slow because of USB 2.0 speed limitations. I was following the official manual page and this article to setup link aggregation. There is no need to recompile the kernel, as the default (GENERIC) amd64 kernel already has enabled agr pseudo-device in its configuration. I literally repeated all the steps from the man page: 

/etc/rc.d/dhcpcd onestop #stop the DHCP client
ifconfig wm0 inet xxx.xxx.xxx.xxx delete
ifconfig wm0 inet6 fe80::xxxx:xxxx:xxxx:xxxx delete
ifconfig wm1 inet xxx.xxx.xxx.xxx delete
ifconfig wm1 inet6 fe80::xxxx:xxxx:xxxx:xxxx delete
ifconfig agr0 create
ifconfig agr0 agrport wm0
ifconfig agr0 agrport wm1 
/etc/rc.d/dhcpcd onestart #start the DHCP client

Once dhcpcd (DHCP client) service started, to my surprise aggregated interface was correctly configured, the router immediately changed aggregation status to enabled. Network was working properly, thus, I could access both my router and the Internet. There was no point to test copying speeds, because USB 2.0 interface was the major bottleneck, however I successfully managed to copy a few files to my main computer using scp protocol. This proved that I was doing something wrong in the Linux environment and that link aggregation actually works between NAS and router.

ifconfig agr0 output

Arch Linux

Arch Linux has a great documentation on many topics in their wiki page. Bonding is not an exception as well. Basically, configuration is not complicated at all: just copy /etc/netctl/examples/bonding file to /etc/netctl/bond0 and configure aggregated interface according to the example. The only difference is to check how your interfaces are called (for example: ip addr list) and replace them in the BindsToInterfaces section accordingly. To be sure that I was configuring the right interface, initially I connected the cable to each of them one by one, and checked which one was configured by DHCP. One additional change was bonding mode. By default Linux uses the round-robin policy instead of the 802.3ad. Therefore, Mode=802.3ad line needs to be added as well. The final configuration looked like this:

 Description="A bonded interface"

 Interface=bond0

 Connection=bond

 BindsToInterfaces=(enp4s6 enp4s4)

 IP=dhcp

 Mode=802.3ad

After that I used netctl enable bond0, netctl start bond0 commands. From the first glance everything seemed fine: new bond0 interface actually appeared, it was up and correct IP was assigned to it. However, pinging to the router was failing and aggregation status was still disabled. It took me two evenings to realize that the problem was dependent on the DHCP client. This article was great in providing additional information on bonding and gave me a hint on troubleshooting the issue. The cause of the failing network was old lease files in /var/lib/dhcpcd folder for aggregated interfaces. Because of this dhcp client was configuring not only bond0 interface but each aggregated interface separately as well. It confused the network and it was failing to route through the right interface. It was enough to delete all *.lease and run dhcpcd client manually for bond0 interface. Since it was properly and automatically configuring bond0 interface even after reboot. Finally network aggegration was working as intended! It can be recognized by the same MAC address between bond0 interface and aggregated ones, IP address assigned only to bond0 interface and "master bond0" on aggregated interface description (ip addr list):

2: enp4s4: mtu 1500 qdisc fq_codel master bond0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: enp4s6: mtu 1500 qdisc fq_codel master bond0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: bond0: mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::230:18ff:fec4:568c/64 scope link
       valid_lft forever preferred_lft forever

Link aggregation speed testing

I performed the same test for the aggregated interface as I did for each NIC controller separately by copying the same 1.6 GB file through samba. To my disappointment, network bonding actually added quite a big additional overhead and was way slower than each interface was performing independently. In general, copying speed was from 58 to 62.5 MB/s which is just about ~10-16% more than the integrated NIC controller and over 20% less than independently working 82541PI controller. Copying 2 files at the same time reduces the speed almost by half for each file so total speed is still basically the same (possibly it's already also a hard drive limitation). According to wikipedia, 802.3ad gives fault tolerance and load balancing, however it does that in expense of performance. If those features are more important than it's worth the hassle, however if speed matters possibly balance-tld or balance-alb modes should be investigated. Unfortunately I didn't have time to play with those modes yet as they need a bit of a different setup (router's link aggregation needs to be actually disabled). If I will do though, I will create a shorter article on that as well.

LEDs of aggregated NICs flashing at the same time

Conclusion

I started this project in my blind belief that bonding will give me bigger speeds, thus I didn't spend enough time on research. Like RAID setup, network aggregation also has different modes for different purposes. The 802.3ad standard is currently the one widely supported by routers. However, it is actually slower than individual interface and provides fault tolerance and load balancing instead, which may or may not be important for your setup. If you are looking to increase your transfer speeds, probably balance-tld mode should be tested. But even in this case, you shouldn't forget that most of the switches, computers and routers are still limited to 1Gbit Ethernet, so even doubling the speed can't actually saturate doubled speed link. Finally, if you are using a magnetic hard drive, they can be a bottleneck as well. Before network bonding setup, you could also possibly consider RAID1+0 setup. In general, the link aggregation feature is not for everyone and you could investigate if it's worth your time, money and hassle. For me, it was mainly an interesting experience and the good reason to fix my outstanding NAS issues. This journey wasn't easy but it gave me valuable information for future configurations and eased me from previous headaches I have suffered from.

Sandy Bridge-EP platform

While Intel's Ivy Bridge CPUs are on the horizon I happened to get Sandy Bridge-E sample on my hands. It is Sandy Bridge-EP 4S more precisely. This CPU will become a member of Xeon E5-4600 series when they will be released and they are primarily intended for 4-way servers. My sample is packed into 2011-land FC-LGA package and works on LGA 2011 socket.  Despite its intended purpose to be a server CPU it can be used on desktop perfectly too. My sample's s-spec is QAFF and its specifications are as follows:

•  3GHz frequency (30x multiplier), max 3.3 GHz on turbo boost
• 10 MB L3 cache
• 4 cores, 8 threads
• 32 nm 
• 130W TDP (not confirmed)
• support for AVX, SSE4.2 and other modern instructions and features like in most sandy bridge cpus.

So I would call it "low-end" or "mainstream" CPU on targeted platform and it is comparable to Core i7 3820 desktop CPU by specs but has much less frequency (3820 clocked at 3.6 GHz by default). CPU multiplier is locked. 

There is always a risk if you buy engineering sample CPU. Firstly, no motherboard will support it officially and you need to find at least some information on supported ones (mostly you need to know at least one supported motherboard from specific manufacturer and then compare their motherboard specifications, BIOS and CPU support to make decision if you are not satisfied this the one you found as compatible). In the worst case you probably will be able to sell incompatible motherboard for some little loss (of course, if you don't live in the small country like me). Secondly, you won't have any warranty. If CPU will die, nobody will replace it. Finally, you can't write a lot about it until official CPUs are released (Intel doesn't like leaked CPUs and can take actions on sellers and on even on bloggers). Nevertheless this CPU has more or less the same core as other Sandy Bridge-E(P) CPUs so you can always imagine performance by reading articles on similar items. When you consider all these factors and still decide to buy a CPU you should be ready to lost the money in the worst case. However, it is still aren't very risky decision in my experience. CPU is probably one of the most reliable parts compared to other computer parts. If you spend enough time to check motherboard compatibility and have enough sources to prove your decision this move becomes even less risky. On the bright side ES CPU can be purchased for less money than production chip (not applicable for first samples of new architecture or platform or very rare collectible old items).

Personally it is my second engineering sample CPU (used for actual computer, not for collection purposes). First one was Xeon E5540 ES Q1E2 Nehalem CPU. Unfortunately, X58 platform wasn't very satisfactory for my purposes and I replaced it with Athlon II X2 235E on AMD 780G platform. It was great platform until Jetway JNC81 motherboard died. Jetway replaced it with JNC84-E but it wasn't so friendly with NetBSD. What is more, I wanted more performance for compiling, folding and other tasks. Though, I still didn't plan to change computer initially in the near future but I bought Sandy Bridge-EP CPU at a reasonable price and decided build the platform on it.

I wanted to go as cheaply as possible because of this I bought relatively cheap ASRock Extreme4-M motherboard, Thermaltake Contac39 CPU cooler and reused some parts from retired mother's Phenom II X2 555 computer (like RAM and graphics card) and my computer (HDD). I plan to add two more RAM modules to make them work on 4 channel mode but currently system works on 2 channel mode. I also would like to get less powerful and more power efficient graphics card (GeForce GTS450 now) but it depends on how successfully I will sell my parts on second hand market. Nevertheless the platform still cost quite a lot as X79 motherboards are pricey and even the cheapest one cost about double of what I spent on one motherboard typically. Extreme-4M wasn't the cheapest one but Intel boards didn't have enough sources to prove compatibility (ironically) and Extreme-4M was more appealing for me than Extreme-3 which one was the cheapest solution from ASRock line.

So my current setup is:

• CPU: Intel QAFF Sandy Bridge-EP 4S 3GHz
• Moterboard: ASRock Extreme-4M
• RAM: 1xKingston KHX1600C9D3B1K2/8GX (2x is planned in the near future)
• HDD: Seagate Momentus 7200.4 250GB (ST9250410AS) (SATA2)
• CPU Cooler: Thermaltake Contac39
• DVD-RW: LG GH22NS40 (SATA)

System setup went without big problems. CPU was recognized as GenuineIntel 3GHz. It works on 1.2GHz on idle. Motherboard uses modern UEFI BIOS. I needed to set 1600 MHz for RAM manually as they worked as 1333MHz by default. No other big changes were needed. Fedora 16 booted without visible problems and worked perfectly. NetBSD wasn't so good. It booted better than on JNC84-E platform (it typically didn't load on first try and needed repeated boot command in the bootloader. This problem disappeared by surprise for me), but NIC (Broadcom BCM57781) didn't work correctly (as result no internet and network), GTS450 graphics card wasn't supported too (X.org failed to start). Keyboard needed reconnect on the first boot but problem didn't reoccur on other times.  So currently I need to solve these issues somehow. On the other hand I expected more worse situation as platform was relatively new. These two problems are quite small and solvable. Of course, USB3.0 is not supported on NetBSD but I don't have any devices anyway. The whole platform uses 86-92W on idle and ~160W on full CPU load (by folding@home). For comparison unlocked 4 core Phenom II X2 555 used around 200W and more with the same graphics card and RAM.

QAFF ES 3.0 GHz

Core i7 920 to Xeon E5540 ES

I have changed a processor on my main computer to Xeon E5540 ES (2.53 GHz). I have received it from USA for a quite low price (I sold my Core i7 920 for the same price). The main purpose to change it was some curiosity to have an engineering sample and a lower TDP (which is 80W instead of 130W on XEON). What is more Xeon is workstation/server CPU which suits me more. I has a little lower clock rate (2.53 instead of 2.66) but faster QPI than (5.86 GT/s instead of 4.8 GT/s). You can find two scans of it in my cpu collection.

Update (2012-05-08):
I removed images from cpu collection album in webpicasa as I don't have this CPU anymore.

Intel i860 in my collection

I was looking for a one Intel i860 CPU for a quite long time. Everytime I was unlucky to get it :D. Finally I got one recently but its surface was covered by an old glue. I removed it somehow with a knife :) and cpu looks quite normal now (there are some small scratches but it was inevitable probably). As always you can find photos in my CPU collection. I also added some new PA-RISC CPUs (two 8700 and one 8200) earlier.

Finally everything works

As you know I have bought new Intel Core i7 system. The first blog item about it was more than a month ago. However, the purchase didn't go very smoothly. System didn't boot and we found the reason only several days before the Christmas. It was a memory fault which hadn't been compatible with the motherboard. However, after I assembled the system with new RAM, it appeared that my PSUs are not enough for this system. My video card showed artifacts after several minutes. Because of this, until now I have used PCI video card which slowed down performance. I bought a new 600W PSU only yesterday. Everything went ok and finally I have my new computer in full configuration:
Intel Core i7 920
Gigabyte GA-EX58-DS4
3GB(KVR1066D3E7+KVR1066D3N7K2/2G) DDR3 1066 MHz Kingston RAM (triple channel)
MSI R4830-T2D512-OC graphics card (Radeon 4830 512 MB)
FORTRON EPSILON 600W (80PLUS) PSU
Codegen M601-CA ATX case.

HDDs and DVD-RW are from my earlier mini-itx system.

Reverse action

I ordered Intel Nehalem platform today. It will consist of Gigabyte GA-EX58-DS4 motherboard, Intel Core i7-920 CPU, PQI 3GB DDR3 1066 RAM and Radeon 4830 video card. The other parts will be taken from my current computer (hdds, dvd-rw). It is probably one of the cheapest solutions if you want to create computer with this new platform.

Intel finally released a cpu without FSB and I finally can jump into their platform once again. I considered to buy some new mini-itx solution or Phenom II, however, Intel showed that they could deliver their products fast. Just after an official release I was able to find their cpus and motherboard for sale in Lithuania. After some more time I could choose between five or six motherboards from different manufacturers. In contrast VIA released their VIA Nano long time ago, however, there is only one product announced by them recently (VB8001) which is based on it. And this mini-itx motherboard is still not in volume so it is difficult to buy (if it is possible at all). Phenom II looks quite promising is still several months away. I decided not to wait.

I think that I'll have parts in several days, maybe, even tomorrow. This platform should be main computer for 4-5 years (some updates during this time is possible).