switch asic transistors

Broadcom Trident 2, 40nm, 4 billion, 104x10GE
Broadcom Trident, 40nm, 64x10GE
Cisco 3548, 412mm2, ??nm, 2.5 billion, 48x10GE
Intel Alta FM6000, ??, 65nm, 1.2 billion, 72x10GE

what asics do the switches use?

ASICs Used by Commerical Switches

Switch	Announce Time	ASIC	Port	Fwd Latency	Onchip Buffer	Mac	IPv4	ACL	Other Features
Cisco 3548	2012.09	Cisco Monticello	48x10G	190ns	18M	64K	16K LPM + 64K Host	4K	ECN, NAT
Arista 7150	2012.09	Intel Alta	64x10G	350ns	9.5M	64K	84K LPM + 64K Host	24K	NAT
Arista 7124FX	2012.03	Intel Bali + Stratix	24x10G	sub 500ns	2M	16K	16K LPM	2K
Arista 7050	2011.03	BCM Trident+	64x10G	800ns ~1200ns	9M	128K	16K LPM + 32K Host	3K	ECN
Arista 7124SX	2011.03	Intel Bali	24x10G	sub 500ns	2M	16K	16K LPM	2K

Broadcom pushes API for SDN interface

Broadcom pushes API for SDN interface

ubuntu remote desktop

when you want to do remote desktop from a window server to an ubuntu desktop, one way is to use vnc. You need to enable remote desktop access at ubuntu desktop and you want to install vnc client at your window client.

At ubuntu, you run  /usr/bin/vino-preferences. It is a X server application. So, if you want to run remotely, you need first install X-server environment at your window client. You can install xinit in cygwin. Then run xinit at cygwin. 

Second, you use 'DISPLAY=localhost:0.0 ssh -X ubuntu_ip', and run vino-preferences. Then you need restart the vino-server by following commands

you@machine-name:~$ export DISPLAY=:0.0

you@machine-name:~$ /usr/lib/vino/vino-server & 

On your ubuntu desktop you should see following by typing 'netstat -antp | grep vino-server'

tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN 6936/vino-server

Once you verify that the vino-server started as you want, you can run vnc to connect to your ubuntu desktop.

git cherry-pick

git cherry-pick allow you to reply a commit or several commits in local repository on a existing branch. The main argument for cherry-pick is a commit id. However, you need to make sure the commit id is in local.

In some cases, you can have several remotes. One of task is you get changes from one remote, and upload the changes to another remote. The procedure would be as follow
1. Fetch repros from remote A. (git fetch [remote])
2. Find out the commits you want to push to remote B. (git log --pretty=oneline)
3. Using cherry-pick to apply those commits to your local branch. (git cherry-pick commit1 commit2)
4. Commit to local repo
5. Push changes to remote (git push [remote] [branchname]

essential tools for cross-compiling linux

The goal here is to build a linux root filesystem on x86 for another architecture. In the very high level, you need following things:
1. a cross-compiler
2. bintuils, such as ld (linker), ar
3. However, in most of current open source packages, there is a 'configure' tool to determine the target system environment and build the actual Makefile. Many parameters are auto-detected based on the host system (like installed libraries and system configurations), through autotools "./configure" scripts. If you run the tool on x86 box, it will get the parameters of the x86 box, but not the targeted system. Therefore, you need some sort of sandbox to run the configure tool. Here, you need scratchbox which builds a cross-development environment. Scratchbox2 allows one to set up a "virtual" environment that will trick the autotools and executables into thinking that they are directly running on the embedded target with its configuration.
4. Even further, sometimes you need to run the binary in the built sysroot which means you need to run ppc binary on a x86 system, for example. In this case, you need qemu to run the binary in a chrooted environment. This has been described in my last post using dpkg as an example.

These are four essential tools you need to build a cross-compiled linux root filesystem. Once you have that, you can start downloading linux kernel sources as well as the other packages you need to start build your cross-compiled linux root filesystem.

Kernel Support for miscellaneous Binary Formats

In cross-development, sometimes you want to build a linux sysroot of different architecture on your filesystem. Then, you want to use Debain ways (dpkg) to build that root filesystem. Basiclly, you have a debian package, and you want to use "dpkg -i" to install that package in the root filesystem.

The problem here is that dpkg will call "chroot" to that sysroot and invoke some post install scripts. However, on that filesystem, /bin/bash is a binary of different architecture. Thus, chroot would not be successful.

The way to solve the problem is allow kernel automatically recognize the binary format and call certain emulation tool such as qemu to execute that binary. The way to do it is Kernel Support for miscellaneous Binary Formats. You need configure sysctl.conf and put qemu-ppc in sysroot/usr/bin/qemu-ppc-static

sysctl -a

fs.binfmt_misc.qemu-ppc64 = magic 7f454c4602020100000000000000000000020015
fs.binfmt_misc.qemu-ppc64 = mask fffffffffffffffffffffffffffffffffffeffff
fs.binfmt_misc.qemu-ppc = enabled
fs.binfmt_misc.qemu-ppc = interpreter /usr/bin/qemu-ppc-static
fs.binfmt_misc.qemu-ppc = flags:
fs.binfmt_misc.qemu-ppc = offset 0