显卡信息检测利器,GPU Caps Viewer介绍

怎么知道我的显示是不是支持OpenCL?GPU Caps Viewer可以告诉你答案。

 
GPU Caps Viewer是一款让监控你的显卡工作情况的好工具。
 
比如,如果你是一个骨灰级游戏玩家,或一个WEB开发者,需要一款图形显示卡方面的应用软件,那么GPU Caps Viewer是你的最佳选择。
 
GPU Caps Viewer的操作界面非常直观。你可以方便地查看你的GPU的各种信息,包括:光影核心(Shader Core),BIOS,设备ID号,次设备ID号,GPU的温度,当前和最大时钟,GPU的负载,显卡的驱动程序,OpenGL, OpenCL,CUDA,PhySX,并且支持多GPU。
 
你还可以启动一个OpenGL或者OpenCL的演示程序,查看OpenGL的版本号和它的扩展链表,CUDA设备的数目,核心数据 — 如名字,计算力,光影时钟,多处理器,变形和网格尺寸(warp and grid size)等等。
 
还可以查看更多的内容。你可以查看到显卡的OpenCL信息,如版本号,CL设备的数目,CL设备的类型,计算单元,时钟,驱动程序,全局和局部内存,2D和3D图象的尺寸,工作项目的尺寸(work item size),常量缓冲区,最大采样器,扩展,工作组的尺寸,等等。
 
另外,还能查看到系统信息。如CPU的名字,CPU的型号,CPU的核心,使用了什么操作系统,内存的信息,显示模式等等。界面上有各种链接导向相应的网页以供查看更详细的信息。界面上的大部分信息可以被导出到txt或者xml文件。
 
需要注意的是,GPU Caps Viewer运行时使用非常多的系统资源,而且软件作者也没有提供一个帮助文档。面对满界面的专业术语,GPU Caps Viewer软件的定位应该是高级用户。该软件可以在各大下载论坛下载到。
 
本文一开始的问题“如何知道显卡是否支持OpenCL”则可以在OpenCL标签项中得到答案。如果显示卡不支持OpenCL,则不会有关于这块显卡OpenCL方面的信息,当然也不能运行OpenCL的演示程序(Demo)。
 
copyright ykyi.net

 

 

ThreadX简介

 

ThreadX是由在美国加利费尼亚州,圣地亚戈的Express Logic有限责任公司开发并注册商标。它是一个实时操作系统,类似于VxWorks, Nucleus RTOS, OSE, QNX, LynxOS这些实时操作系统。ThreadX的作者是William Lamie,它是Express Logic有限公司的董事长兼CEO。
 
为什么ThreadX取这样一个名字呢?ThreadX的这个名字缘于线程(Thread)是被操作系统调度的单位,字母X就表示切换线程。ThreadX可以被看成是SystemC的QThreads的抢先式实现。
 
与大多数实时操作系统一样,ThreadX的内核是多任务抢先式内核,支持快速响应中断,内存管理,线程通讯,互斥,事件,线程同步等特性。
 
ThreadX的一些独有的特性有:优先级继承,抢先阀值,高效定时器,pico内核设计,事件链,高速软定时器,以及精致的内核尺寸。ThreadX是开源发布的,并且使用ThreadX不需要任何授权费用。
 
ThreadX常常被使用在实时嵌入式操作系统中,特别是嵌入程度很大的嵌入式系统(Deeply embedded system)。ThreadX的开发通常都在运行Linux或者windows操作系统的机器上用交叉编译环境开发。交叉编译工具可以生成在目标平台上运行的二进制代码。已经有很多可以用来开发ThreadX的开发工具,比如:Wind River Workbench, ARM RealView, Green Hills Software's MULTI, Metrowerks CodeWarrior, IAR C-SPY,Lauterbach TRACE32, 和visionCLICK
 
最近,Hewlett-Packard已经被授权可以使用ThreadX开发喷墨打印机,激光打印机,一体化设备。早些时候,开发多功能激光打印机使用lynxOS操作系统,目前仍然有很多打印机设备设用lynOS。如今,ThreadX已经被广泛使用在很多消费电子设备,医疗设备,datanetworking applications,还有SoC的开发。

红帽的云计算机解决方案

 

Red Hat Cloud
未来的云计算一定是开放的
 
对于一个公司负责IT的领导层来讲,选择一个正确的云计算机架构是一件极为重要的战略决策。这将影响到你的企业在这个十年的竞争力和灵活性。所以,务必谨慎选择。
 
如果这个事做正确了,云计算将帮助你从过去的简单控制资源的配额过渡到真正的革命性变化。但是,只有一个开放的云计算解决方案可以做到。
 
只有红帽提供了一个真正的开放云计算解决方案
 
红帽作为开源软件业的引领者,为你提供了构建一个开放去计算解决方案所需要的一切。拥抱全面开放的云计算吧,你的企业才真正认识到什么是云。
 
 
1. 让数据在云之间自由迁移。
2. 全面利用已有的IT投资和基础设施。
3. 跨越物理服务器,多种虚拟化平台,以及运行着各种各样不同技术栈的公共云。
4. 使企业平滑过渡到云时代,在每一个步骤都能获得持续的收益。
5. 你对选用什么技术有真正的话语权。
 
更多的选择:
 
红帽拥用最有活力的生态系统,一大批认证的云计算提供商,硬件提供商,Paas(Platform-as-a-service)中间件的提供商。毫无疑问,红帽是能够给你提供最多最自由选择的云计算平台。
 
红帽的开放云让IT公司或者企业的IT部门在经济上容易承受,并使用开放的应用程序编程接口(API),充许用户自由的迁移到其它的云,使你能够控制和领导你的IT愿景(Let you control and lead your IT vision).
We can strengthen your open cloud by drawing on more than a decade of experience and technology powering mission-critical infrastructures and applications for the world's most demanding organizations—including top public clouds. All while providing the Red Hat service levels and control our customers expect.
 
 

flexcoin全世界第一家Bitcoin銀行

Bitcoin是互聯網上一種虛擬貨幣,欲知更多自己搜索下,已經有很多文章介紹了。

 
Flexcoin.com是網路上第一家基於於Bitcoin的銀行。Flexcoin使你可以在全世界所以可以連接到互聯網的地方使用Bitcoin。
 
如果你把Bitcoin存到flexcoin.com,你就有了一個賬戶可以轉出以及收款。另外,如果在每月月底你的賬戶中有正數值的余額的話,flexcoin還會給你一部分利息。
 
換言之,就如同真實世界中的銀行一樣,只是這裏使用的是Bitcoin,而不是任何政府發行的貨幣。
 
Flexcon是整個Bitcoin體系中一個非常重要的部分。我們的技術使我們可以為用戶做到通過用戶名快速轉賬到一個用戶名下,而不是一串奇怪的數字標志的用戶名。如下:
Before Flexcoin: 1555hjPG7pRwTHVMfukPvjXexQMHFE3qu6 
After Flexcoin: coffeeshop
 
Flexcoin解決了Bitcoin貨幣體系中一個很大的問題。
 
Flexcoin出現前,當別人給你發來Bitcoin,你只有從你初次接收它的設備上操作它。你不能夠,至少不能輕易地通過你的手持設備或者其他什麼設備使用它。一般地講,只有在你初化接收和發送Bitcoin的機器上才能操作Bitcoin。通過使用Flexcoin,你甚至可以把Bitcoin發送到一個電郵地址。Flexcoin的設計使即使不怎麼懂技術的用戶也能夠使用。
 
Flexcoin做的工作看起來很簡單,他提供了一個集中的處理你所有Bitcoin財產的地方。Flexcoin就是全世界第一家Bitcoin銀行。你可以通過任何可以使用Web的設備用一個賬號來管理所以屬於你的Bitcoin。
 
這樣就使你可以在各種場合各個時間段也能夠發送和接收Bitcoin。只要你有一臺可以用Web方式登錄到Flexcon.com的設備。
 
Flexcoin也是整個Bitcoin界的安全引領者。比如,Flexcoin是第一個實現了在電郵件絕不放置URL的機構。從Flexcoin發出的電郵絕對不會有鏈接或者圖象。如果你收到一封違反剛才聲明的電郵,那一定是欺詐郵件。
 
Bitcoin的官方網站是 www.bitcoin.com
 
copyright ykyi.net

MediaWiki入门教程

 

MediaWiki是这个世界上使用人数最多的百科建站系统。全球最著名的Wikipedia.com就是用MediaWiki建立的。另外,MediaWiki是在GPL协议下免费开源工程,这意味着你可以免费使用它。下面将介绍如何使用MediaWiki.
 

如何安装MediaWiki?

从官网下载到MediaWiki的安装包,解压到服务器的根目录下面。然后用你的域名访问网站,就会提示你一步一步安装了。注意最后一个步骤会生成一个LocalSettings.php文件,你需要把这个文件上传到网站的根目录。如果没有把生成的LocalSettings.php放到根目录,下次输入域名访问网站会提示找不到LocalSettings.php。其实整个安装都超级简单!
 

怎么使MediaWiki只能够被私人使用?

在安装阶段有这个选项配置MediaWiki会被如何使用。如果错过了,可以删除根目录下的LocalSettings.php,再输入域名访问网站重新生成LocalSetting.php。这样有点麻烦,也可以直接编辑LocalSettings。比如:
# 禁止未登录用户编辑内容.
$wgGroupPermissions[‘*’][‘edit’] = false;
# 禁止用户注册,除非系统管理员创建用户。
$wgGroupPermissions[‘*’][‘createaccount’] = false;
 

怎么创建一个页面?

在这个例子中,我们会教你创建一个页面。页面的内容就是'如何创建一个页面'。
在网站的右上角上点击:登录。 然后用你的管理员账号登录。
在MediaWiki中创建一个页面的方法有点特殊。首先,你在搜索框中输入你将要编辑的词条名字,然后点击搜索。如果词条不存在的话,就会显示一个页面告诉你没有这个词条。在这个页面上会有一个选项提示你创建这个词条。点击“创建词条”。
输入以下内容:
 
 == Create a page ==
* 把词条输入搜索框,然后搜索。
* 搜索结果显示没有匹配到任何页面,这时有一个选项让你创建一个页面。
* MediaWiki标志语言(MediaKiki Markup Language也常被称为:wikitext)可以在 http://www.mediawiki.org/wiki/Markup_spec 找到。
* 各种编辑页面的例子可以在 http://meta.wikimedia.org/wiki/Help:Editing and http://meta.wikimedia.org/wiki/Help:Wikitext_examples 找到。
点击"预览"按钮,可以看到页面的预览效果。点击"保存页面",则这个页面被编辑完成了。
 

怎么改名一个页面?

有时候你想要把一个页面改名。MediaWiki处理改名的逻辑实际上是把这个页面使用新的名字移动到一个新的位置,MediaWiki会记住旧的名字,还会建立一个到新页面的引用。
在页面的上部找到"移动"标签页,点击!
填好新的页面名字,点击"移动页面"按钮。
系统会让你确认一次,然后改名就完成了。
 

怎么改变MediaWiki的Logo呢?

常常有人问如何把网站左上方的网站Logo换掉。
首先你创建一个宽135象素,长135-150象素的logo图象文件。把logo上传到服务器某个位置。默认是放在/skins/common/images/wiki.png。
编辑LocalSetting.php文件,修改 $wgLogo变量。
刷新页面,现在你可以看到新的Logo了。
 

怎么在页面中建立内部链接(Internal Links)?

不像标准的HTML语法,在编辑MediaWiki的页面时建立指向内部页面的链接是非常容易的。比如你要建立一个到词条名为“我爱香港”的内部链接,则在编辑页面时在词条名前加井号。
如: #我爱香港
MediaWiki的内部链接的颜色有两种,一种是红色,一种是绿色。当内部链接的颜色是红色时,表示还没有收录这个词条,如果你点击的话,会提示你建立新词条。如果是绿色,则相反。
 

如何改变MediaWiki的导航菜单?

比如我想要把我的wiki站点上所有的category都列在导航条上,那我就需要修改导航条。
在搜索框中输入: Mediawiki:Sidebar。搜索结果会给出导航条的页面。
选择“编辑”。
增加一行以**起头,|符号前面的字符表示导航项将要显示的名字,|后表示页面的名字。
最后选择保存页面,完成!
copyright ykyi.net
 

It’s a mistake to include Xen in a Linux distro

As the title show, it's a mistake to include Xen in a linux distro. Why?

Somebody would argue that Xen is a very useful technology. Xen does the virtualization work very well and many projects are using Xen which prove Xen is so great.

I'm not mean Xen is not good. However, just because Xen is a hypervisor that is based on another microkernel that is not Linux kernel itself. Linux distros that ship Xen today actually are running an entirely different Operating System kernel that most users even don't notice that. Xen should be a separate, purpose-built kernel, so it should never be a part of the Linux kernel. Isn't it strange that you think you are running a linux OS, but this 'linux' has a kernel that is not linux, which is another kernel. You take away the Linux kernel, how could you say the OS is Linux.

Just before the born of the Linux native virtualization KVM, the distros shipped Xen because there exist no other choices. Many Linux developers at that time know little about virtualization. Xen seemed a pretty easy and pretty good choise. So the Linux community made the hasty decision to ship Xen instend of investing in makeing Linux's own hypervisor. But now KVM has come for more than five years(since kernel 2.6.20 in Feb, 2007. KVM actually has a longer history. It was out there before being merged into mainline kernel code.) and KVM has proven itself to be completent to replace Xen. The most important thing is that KVM as a part of the linux kernel leverages the features of kernel like memory management, process scheduling and so on, making the kernel a perfect hypervisor. So, there is no reasons to ship Xen in Linux distros any more.

COPYRIGHT WWW.DOGEYE.NET

traceroute failed.Specify protocal traceroute used manually to fix it.

Today, I ran the traceroute program on a machine running FreeBSD. It failed once and again.

Traceroute complained:

traceroute: sendto: Permission denied.

So I tried to ping. Ping failed, too. I then checked out the configuration of the firewall, which actually denied the pass through of ICMP packet. So I set it to allow ICMP pacakges to pass through the firewall. Ping worked as I expected. But traceroute still failed.

I was very confused, I tried to run the tcpdump to find out why. Tcpdump showed that traceroute was sending UDP packet. Oh, my gosh. I had always thought traceroute was implemented on ICMP. After I read the tcpdump manpage. I found traceroute default on using udp protocal, but user can switch to use icmp by indicating the -M icmp or -I(The capitalized i). Alternatively, you can also command traceroute to use raw packet of specified protocol for tracerouting by specifying -P(beware P is capitalized). When you use raw packet, the default protocol is 253 (rfc3692). So, I ran traceroute using the command as: traceroute -P ICMP www.the_host.com, everything worked fine.

COPYRIGHT WWW.DOGEYE.NET

如何正确地提交内核补丁包

原文:https://lwn.net/Articles/500443/

翻译:ykyi.net 

Greg Kroah-Hartman(又Greg KH)在执行一个了不起的作务:减少内核开发者,尤其是维护者的暴躁情绪。他在日本横滨举行的全球Linux大会上的讲演呼吁公众理解内核维护者的工作,内核贡献者的什么样的行为会导致内核维护者变得暴戾。但是,如果内核贡献者们能够遵守一些约束,他代表他自己做了许多承诺。

Greg Kroah Hartman把Linux内核称之为"有史以来最宏大的软件开发项目",而且它的开发速度也是“亘古未有”。从3.0到3.4,有373个公司的2833位开发者参于了Linux内核的开发。这一年,(2011年的5月到,2012年的5月),Linux内核在每个小时会有5.79处变动。而且这个开发速度仍然要加速,如果你看看3.4的开发过程,每小时共有7.21处变动。这里所说的变动仅仅指能够被合并到主干的补丁包,而那些被拒绝的补丁包没有被统计进来。

补丁包修改了哪些文件,内核开发者就把补丁包发给负责这些文件的维护者。所以的内核维护者,现在大概有700人。他们把改变应用到130个子系统的维护者那里。再从子系统的维护者到Linus的Linux内核代码分支。最后并必Linux内核的主干。如果提交的补丁包一路通过的话。

因此,来看看为什么一些补丁包不会被接受呢?Greg Kroah Hartman以刚过去的两个星期收到的补丁包为例,这两个星期刚好处于3.5版本的Merge Window时间。Merge Window是一个他确不应该接收到许多补丁包的时间段。他应该在Merge Window开始前收到所以有可能会在Merge Window其间被发往Linux Torvalds的补丁包。不过,他说他在这两个星期的时间里收到487个补丁包。其中的大多数都有很多问题,有些补丁包来自那些本应该对内核有更好理解的内核开发者们。

坏的补丁包

Greg KH举例说明了一些他收到的坏的补丁包。其中一个补丁包被命名为:patch 48/48(一个有48个补丁集的最后一个),但是其它的47个都没有。他还收到一堆补丁但没有写清楚先后顺序。如此,他要么猜测一个顺序,这毫无疑问会失败。另一个替代方案就是安全不管这个补丁了。另外还收到过有10个补丁的补丁集,但是2号补丁确丢失了。

另外有一个通过邮件发送来的补丁包被声明“机密”。Greg KH说他经常收到此类方式的补丁。对于此类补丁,你无能为力。因为Linux是在开放的生态中开发的,你不能够给邮件列表发送一个机密邮件偷偷就合并一个补丁。很明显,这种方式发来的补丁是因为在处理邮件阶段的模板造成的,但是'机密'必须被去掉。

还有不良排版的补丁包。比如所有的Tab符都被转成了空格,Microsoft Exchange常常这么做。如果对于你,开发环境是个问题的话,那可以像IBM,Microsoft或者还有其它公司那样,在角落里再放一台Linux机器给开发者用来发送邮件。有时候diff的输出的行前空格都被剥去了,或者diff的输出并不是unified格式(见另一篇博文,讲述如何用diff生成linux内核补丁包)。虽然久经考验的Linux开发者们可以熟练的编辑原始diff输出格式,但是diff的原始输出本身是件很令人恐怖的事情,他们本不应该被如此对待编辑它们。

有些补丁包是在错误的目录下被创建的,比如在一个驱动器目录下。有个补丁包在/usr/src/linux-2.6.32目录下被创建,但是这个补丁包里面有好些错误,包括源代码树的年龄,而且它隐含假设它是在root上构建。在root上构建是相当之危险,如果linux的构建过程中出现一个bug,就有可以把整个文件系统都删除。没有一个内核核心开发者留意到了这个情况,因为他们没有使用root。有建议说把这种bug留下来当成一种威慑力(原作者开玩笑),自然不会被采纳,不过那么极端的危险情况是真的有可能发生啊。

还有离谱的,有些补丁包是针对一个本来与这个补丁包毫无关系的代码树。Greg KH说他曾经收到一个补丁包针对SCSI代码树,实在想不通这个与SCSI毫无关系的补丁关怎么会针对SCSI代码树创建。

然后还有代码风格的问题。有些补丁包没有使用Linux内核的代码风格。提交补丁包的开发者也知晓这个问题,但是他们似乎在说“我不管,让我的代码通过吧!”Greg KH说,现有一些工具可以帮助定位到有这些问题的代码并修复它们。所以,没有任何借口发送不符合代码风格的补丁包。

Greg KH还着重说了编译不能通过的问题。他说,有些内核内核贡献者把不能通过编译的补丁包也发过来。或者有些补丁包集3/6失败了,在6/6修复了。我甚于收到过补丁包在5/8失败,但是作者附带了一个说明说作者在未来某个时候会发来改正方案。另外还有补丁包很明显没有正确的内核文档部分,因为在构建文档的时候会失败,很明显补丁包的创建者根本就没有运行过内核文档抽取工具。(不想译了,太多了…呜~~累死了.)

One of the patches he got "had nothing to do with me". It was an x86 core kernel patch, which is not an area of the kernel he has ever dealt with. But the patch was sent only to him. "I get odd patches" a lot, he said.

The last patch he mentioned was 450K in size, with 4500 lines added. Somebody suggested that it be broken up, but in the meantime several maintainers actually reviewed it, so the submitter didn't really learn from that mistake.

All of this occurred during a "calm two weeks", he said. These are examples of what maintainers deal with on a weekly basis and explains why they can be grumpy. That said, he did note that this is the "best job I've ever had", but that's not to say it couldn't be improved.

If someone sends him a patch and he accepts it, that means he may have to maintain it and fix bugs in it down the road. So it's in his self interest to ignore the patch, which is an interesting dynamic, he said. The way around that is to "give me no excuse to reject your patch"; it is as simple as that, really.

Rules

Kroah-Hartman then laid out the rules that contributors need to follow in order to avoid the kinds of problems he described. Use checkpatch.pl, he said, because he will run it on your patch and it is a waste of his time to have to forward the results back when it fails. Send the patch to the right people and there is even a script available (get_maintainer.pl) to list the proper people and mailing lists where a patch should be sent.

Send the patch with a proper subject that is "short, sweet, and descriptive" because it is going to be in the kernel changelog. It should not be something like "fix bugs in driver 1/10". In addition, the changelog comment should clearly say what the patch does, but also why it is needed.

Make small changes in patches. You don't replace the scheduler in one patch, he said, you do it over five years. Small patches make it easier for reviewers and easier for maintainers to accept. In a ten-patch series, he might accept the first three, which means that the submitter just needs to continue working on the last seven. The best thing to do is to make the patch "obviously correct", which makes it easy for a maintainer to accept it.

Echoing the problems he listed earlier, he said that patches should say what tree they are based on. In addition, the order of the patches is important, as is not breaking the build. The latter "seems like it would be obvious" but he has seen too many patches that fail that test. To the extent that you can, make sure that the patch works. It is fine to submit patches for hardware that you don't have access to, but you should test on any hardware that you do have.

Review comments should not be ignored, he said. It is simply common courtesy if he takes time to review the code that those comments should be acted upon or responded to. It's fine to disagree with review comments, but submitters need to say why they disagree. If a patch gets resent, it should be accompanied with a reason for doing so. When reviewer's comments are ignored, they are unlikely to review code the next time.

Maintainer's role

When you follow those rules there are certain things you can expect from him, Kroah-Hartman said, and that you should expect from the other maintainers as well. That statement may make other maintainers mad, he joked, but it is reasonable to expect certain things. For his part, he will review patches within one or two weeks. Other maintainers do an even better job than that, he said, specifically pointing to David Miller as one who often reviews code within 48 hours of its submission. If you don't get a response to a patch within a week, it is fine to ask him what the status is.

He can't promise that he will always give constructive criticism, but he will always give "semi-constructive criticism". Sometimes he is tired or grumpy, so he can't quite get to the full "constructive" level. He will also keep submitters informed of the status of their patch. He has scripts that will help him do so, and let the submitter know when the patch gets merged into his tree or accepted into the mainline. That is unlike some other maintainers, he said, where he has submitted patches that just drop into a "big black hole" before eventually popping up in the mainline three months later.

He ended by putting up a quote from Torvalds ("Publicly making fun of people is half the fun of open source programming. …") that was made as a comment on one of Kroah-Hartman's Google+ postings. The post was a rant about a driver that had been submitted, which even contained comments suggesting that it should not be submitted upstream. He felt bad about publicly posting that at first, but Torvalds's comment made him rethink that.

Because kernel development is done in the open, we are taking "personal pride in the work we do". As the code comment indicated, the driver developer didn't think it should be submitted because they realized the code was not in the proper shape to do so. It is that pride in the work that "makes Linux the best engineering project ever", he said. Sometimes public mocking is part of the process and can actually help instill that pride more widely.

What is 802.11 and their friends.

WLAN(Wireless Lan) was invented in University of Hawaii, 1970, under the leadership of Professor Norman Abramson.The wireless network communicated using radios, without using phone lines making it easy to deploy over Hawaii islands.

Original WLAN hardware was used as an alternative to cabled network where cabling was impossible or difficult. The protocals of WLAN at that time was proprietary. Many companies and universities appealed to establish a set of protocals as industry protocals. In the end of the 1990s, IEEE 802.11(Wifi) came to satisfy the urgent need. Subsequent amendments such as 802.11a, 802.11b, 802.11g, 802.11n was published in the following years. Other proprietary protocals was then graduately replaced by 802.11 family.

The original 802.11 was ratified in 1997 specifies two raw data rates of 1 and 2 megabits persecond to be transmitted via radio.The frequency band was set at 2.4GHZ.

The 802.11a amendment was ratified in 1999 which uses the same core protocol as the 802.11 standard but the frequncy band is set at 5 GHz. The maximum raw data rate of 802.11a can achieve 54 Mbit/s.

The 802.11b amendment was ratified in 1999 also which has a maximum raw data rate of 11 Mbit/s and works at the frequence band of  2.4 GHz as same as the 802.11 legacy.

The 802.11g amendment was ratified in June 2003. This flavor uses the 2.4GHz band, too, but it can reach a maximum raw data rate of 54 Mbit/s. Because of its prominent performance, 802.11g standard swept the consumer world even before the standard was fully ratified.

The 802.11n amendment was ratified in 2009. The maximum raw data rate can achieve 300 Mbit/s, even 600 Mbit/s due to the intruction of MIMO(multiple-input multiple-output) technology.

Actually, when we say 802.11, it should be the base standard of 802.11 in1999. All subsequent released amendments are based on 802.11 in 1999. However, it is probably too academic to stick to this outside the working group that produces and developments the IEEE 802.11 family.

A very brief Introduction to Neural Network.

 

I have huge interests in the mysterious Artificial Intelligence. Because of the lack of time to devote into learning AI, I still barely know AI related theories. Tonight I read something about Neural Network, which plays a important role in the AI field.
 
So, what is A NEURAL NETWORK?
A neural network is a massively parallel distributed processor made up of simple processing units that has a natural propensity for storing experiential knowledge and making it available for use. It resemble the brain in two respects:
knowledge is acquired by the network from its environment through a learning process.
Interneuron connection strengths  known as synaptic weights, are used to store the acquired knowledge.
 
Let us take the human vision as an example to demonstrate why it is necessary to study neural network. Human vision is a very complex information processing task. It is the function of the visual system to provide a representation of the the environment around us and to supply the information we need to interact with the environment. The brain accomplishes recognition task at the same time. For instance, the brain can recognize a familiar face embedded in an unfamiliar scene in shorter than a blink of eye, actually 100-200ms, whereas tasks of much lesser complexity take a great deal longer on a very powerful computer.
 
What's the reason makes the biological brains so efficient? How to let our machines think and do reasoning like biological brains do. The course of Neural Network has been trying to answer these questions from the day the course was established.
A typical neural network has many useful properties and capacities. 1. Nonlinearity 2. Input-output Mapping 3. Adaptivity 4. Evidential Response 5. Contextual Information 6. Fault Tolerance 7. VLSI(Very Large Scale Integrated) Implementability. 8. Uniformity of Analysis and Design 9. Neurobiological Analogy.