Networking

So it happens.

As the website states, it works by:

• Sending your page requests through Google machines dedicated to handling Google Web Accelerator traffic.
• Storing copies of frequently looked at pages to make them quickly accessible.
  Downloading only the updates if a web page has changed slightly since you last viewed it.
• Prefetching certain pages onto your computer in advance.
• Managing your Internet connection to reduce delays.
• Compressing data before sending it to your computer.

看来配IP的时候真是得小心。原本希望两块网卡互为备份，结果配的一个0xffffff00，一个0xffffffff，00的那个松了，就彻底败了……

历史，永远会嘲笑那些嘲笑历史的人们。永远不要嘲笑任何表面上看来很白痴的东西，因为那样想的人可能很多。

你觉得阻断互联是互联网历史的重大倒退吗？错了，因为事实上，不互联才是真正的发展趋势。

Someone has disclosed that he is implementing iSCSI on FreeBSD, at scsi@. iSCSI is essential technology that is highly scalable and looks quite promising.

An excerpt from the mail server log:

Feb 6 13:40:27 beastie amavis[81393]: (81393-03) Passed CLEAN, [3ffe:401d:203a:41:a00:2bff:fe86:af46] bounces-tech-net-owner-delphij=frontfree.net@NetBSD.org -> delphij@frontfree.net, Message-ID: oqfz0aqmaz.fsf@castrovalva.Ivy.NET, Hits: -2.599, 15863 ms

And seems that they have re-implemented it… Why netcat… I can’t understand it…

So, it’s in security category.

With ntpdate time-a.nist.gov I got “No server suitable…”.

And then I have asked my network administrator.

Then I got a point that there’s some rules in filter.

But ntpdate -d works.

Then I tried ntpdate -u.

Then, it works…

Today NetApplience folks has told me that Linux performance is twice better than FreeBSD when using em(4) driver, and they pointed out that the driver FreeBSD is using does not do a good job at this time. I have tried to tune some certain part of the kernel however the result is still not so good at the time I am writing.

Today, JINMEI Tatuya / 神明達哉 has submitted a patch against sys/kern/uipc_socket2.c, which is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Index: src/sys/kern/uipc_socket2.c
diff -u src/sys/kern/uipc_socket2.c:1.138 src/sys/kern/uipc_socket2.c:1.139
--- src/sys/kern/uipc_socket2.c:1.138	Tue Oct 19 15:13:30 2004
+++ src/sys/kern/uipc_socket2.c	Wed Oct 27 05:37:58 2004
@@ -1253,7 +1253,7 @@
 
 	if (CMSG_SPACE((u_int)size) > MCLBYTES)
 		return ((struct mbuf *) NULL);
-	if (CMSG_SPACE((u_int)size > MLEN))
+	if (CMSG_SPACE((u_int)size) > MLEN)
 		m = m_getcl(M_DONTWAIT, MT_CONTROL, 0);
 	else
 		m = m_get(M_DONTWAIT, MT_CONTROL);

To quote his “I would recommend against per-thread caches. Instead, make the per-cpu caches actually *be* per-cpu (that is, not require a mutex).”

Then, he has pointed out that there is potential problems in FreeBSD’s SLAB allocator which is different from DragonFly’s. (Not too surprisingly, he is again advertising his IPI message approach).