為什麼有人會比你成功10倍

From owner-freebsd-ia64 Sun Mar 2 19:55:39 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2709337B401 for ; Sun, 2 Mar 2003 19:55:38 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-52.dsl.lsan03.pacbell.net [63.207.60.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A8A43F85 for ; Sun, 2 Mar 2003 19:55:37 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 2E24066B2C for ; Sun, 2 Mar 2003 19:55:37 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 07C86E60; Sun, 2 Mar 2003 19:55:37 -0800 (PST) Date: Sun, 2 Mar 2003 19:55:36 -0800 From: Kris Kennaway To: ia64@FreeBSD.org Subject: openldap broken ("Illegal instruction (core dumped)") Message-ID: <20030303035536.GA34594@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline http://bento.freebsd.org/errorlogs/ia64-5-latest/openldap12-1.2.13.log This may warrant investigation. Kris --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+YtI4Wry0BWjoQKURAqmpAKCXV26bwEC/HRYCWL3+iJ6K+n0IFQCggozv gL5x5NtlGHvcS2vJgQeulbQ= =gKGd -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Mar 3 8:36:50 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0090937B401 for ; Mon, 3 Mar 2003 08:36:48 -0800 (PST) Received: from sinamail.com (61-221-29-145.HINET-IP.hinet.net [61.221.29.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FA0443FDD for ; Mon, 3 Mar 2003 08:36:44 -0800 (PST) (envelope-from suppergeorge@sinamail.com) From: star@yahoo.com.tw To: freebsd-ia64@FreeBSD.org Subject: =?ISO-8859-1?B?prO+97d8p0HEQLdOpWi5wbjVttw/Pw==?= Reply-To: suppergeorge@sinamail.com Date: 04 Mar 2003 00:41:50 +0800 MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: <20030303163644.2FA0443FDD@mx1.FreeBSD.org> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 為什麼有人會比你成功10倍
主旨: 這或許是您正在尋找的機會喔

這或許是您正在找的機會哦！

對不起！打擾了，如果因此造成您的困擾，請直接刪除本信及點選下方「不想再收信」，我們會將您的資料刪除！

為什麼有人會比你成功10倍，收入多100倍、甚至多1000倍，難道他有比你多聰明這麼多嗎？

答案肯定不是的！

想一想！那些收入比我們高很多，生活比我們好很多的人！

他們到底做了什麼是我們所不知道的事？

而我們到底做錯了什麼、又錯過了什麼？

想不想知道人家怎麼做倒的！

你相信「時間＝金錢」、還是「時間＞金錢」

舉例：

我們一天工作8小時，一年工作365天，一輩子工作30年！那我們一輩子的總工作時數？

８小時＊３６５天＊３０年＝８７,６００小時

如果你的時薪100元，你一輩子賺876萬元！

如果你的時薪150元，你一輩子賺1314萬元！

如果你的時薪200元，你一輩子賺1752萬元！

看起來好像很多，看清楚！一年工作365天，要工作30年！而且不吃不喝！

這樣的收入，足夠三餐溫飽；買車子、房子勉強夠用；別忘了，還有子女的教育費、自己的養老金、還有『夢想』等待實現！

這樣的一輩子，你甘心嗎？

身為員工的你，每天辛苦為的是什麼？家庭、小孩？你有沒有想過，你上班一輩子，將來你的小孩能承接你的職位繼續做下去嗎？（除非你自己是老闆）

想不想改變自己及下一代的一生？

不想再收信(Unsubscribe)

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Mar 3 17:31:46 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49C2C37B405 for ; Mon, 3 Mar 2003 17:31:44 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E1EB43FD7 for ; Mon, 3 Mar 2003 17:31:43 -0800 (PST) (envelope-from rick_jones2@hp.com) Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 95F391C0130F for ; Mon, 3 Mar 2003 17:31:42 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id RAA04967 for ; Mon, 3 Mar 2003 17:31:41 -0800 (PST) Message-ID: <3E6401FD.E2B384E3@hp.com> Date: Mon, 03 Mar 2003 17:31:41 -0800 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: ia64@freebsd.org Subject: initial netperf tests on rx2600 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Folks - Thank's to Marcel's fixing of the EFI trap problem, and his installing bits for me :) I was able to run a first pass at netperf aggregate TCP_RR perf under FreeBSD 5.0 on the rx2600 There are something like four OSes one can boot on IPF/Itanium2 at the moment - HP-UX, Linux, FreeBSD and Windows (OpenVMS is probably not toooo far behind, but those four are the ones "shipping" today). I am able to include figures for three of the four here. Aggregate, single-byte, netperf TCP_RR results Truncated to the Nearest 100 Transactions per Second Using Core GbE (rx2600) Two-CPUs present, One Enabled Concurrent System sut220 sut220 sut220 Streams rx2600 rx2600 rx2600 HP-UX 11.22 RH AW 2.1 FreeBSD 5.0 -------------------------------------------------------------------- 1 | 10900 7600 6700 2 | 20900 11900 13500 4 | 38300 19400 20800 8 | 41800 32600 27300 16 | 44800 37800 48300 32 | 45100 83200 48100 40 | 45000 83000 48400 48 | 80500 The "load generators" here were a pair of HP rp2470's, each with 2, 750 MHz PA-8700 CPUs, and using an add-on GbE NIC based on the tg3 core. The tests ultimately take the SUT (System Under Test) to 100% CPU utilization. All NIC settings are at their defaults. I know how to tweak coalescing parms under UX, but not FreeBSD or Linux :) It seems clear that both Linux and FreeBSD have some sort of heuristic that kicks-in to alter some settings as load increases. happy benchmarking, rick jones BTW, what would be the "best" way for netperf to obtain programatic CPU utilization figures. At present, it measures CPU util by taking "idle rates" before a test and comparing them with during a test. What api might netperf call to retrieve that sort of data? -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 11:41:34 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7745F37B401 for ; Tue, 4 Mar 2003 11:41:24 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21E6D43FB1 for ; Tue, 4 Mar 2003 11:41:22 -0800 (PST) (envelope-from rick_jones2@hp.com) Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 97E461C01F1B for ; Tue, 4 Mar 2003 11:41:21 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA21338 for ; Tue, 4 Mar 2003 11:41:21 -0800 (PST) Message-ID: <3E650160.18B891D6@hp.com> Date: Tue, 04 Mar 2003 11:41:21 -0800 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: ia64@FreeBSD.ORG Subject: Re: initial netperf tests on rx2600 References: <3E6401FD.E2B384E3@hp.com> Content-Type: multipart/mixed; boundary="------------10B7BF6B577D00E216820906" Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------10B7BF6B577D00E216820906 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > BTW, what would be the "best" way for netperf to obtain programatic > CPU utilization figures. At present, it measures CPU util by taking > "idle rates" before a test and comparing them with during a test. > What api might netperf call to retrieve that sort of data? attached is a run of the "packet_byte_script" which I use to try to estimate per-packet and per-byte costs for stacks. the "L" in the CPU util column means that the "looper processes" (aka soaker) was used to measure CPU util during the test. You can see that the tests did not often hit the desired confidence intervals (having asked for a 5% interval with 99% confidence). I'm thinking that the use of a looper process was related to this, hence my desire to find something else - but not statistical - to take its place. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... --------------10B7BF6B577D00E216820906 Content-Type: text/plain; charset=us-ascii; name="rx2601_1GHz_fbsd5.0_core_to_rp2472_750MHz_cpu0_tg3.pab" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rx2601_1GHz_fbsd5.0_core_to_rp2472_750MHz_cpu0_tg3.pab" ------------------------------------------------------ Testing with the following command line: ./netperf -l 20 -H 192.168.1.67 -t TCP_RR -c 617730 -C 7.47812e+08 -i 10,3 -I 99,5 -- -s 0 -S 0 and these settings for send sizes 1 16 32 64 128 256 512 1024 1460 1461 2920 2921 4380 4381 TCP REQUEST/RESPONSE TEST to 192.168.1.67 : +/-2.5% @ 99% conf. !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 12.8% !!! Remote CPU util : 1.5% Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % L % I us/Tr us/Tr 32768 65536 1 1 20.02 6779.48 19.73 8.82 29.109 26.008 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 8.9% !!! Remote CPU util : 1.4% 32768 65536 16 1 20.02 6780.05 19.47 8.90 28.714 26.250 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 10.9% !!! Remote CPU util : 1.6% 32768 65536 32 1 20.02 6779.62 19.76 8.90 29.147 26.246 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 7.2% !!! Remote CPU util : 1.3% 32768 65536 64 1 20.02 6778.09 19.67 8.94 29.022 26.386 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 9.2% !!! Remote CPU util : 1.9% 32768 65536 128 1 20.02 6775.70 19.89 9.02 29.357 26.611 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 7.9% !!! Remote CPU util : 1.7% 32768 65536 256 1 20.02 6761.37 19.93 9.09 29.480 26.875 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 1.6% !!! Local CPU util : 20.0% !!! Remote CPU util : 4.0% 32768 65536 512 1 20.02 3381.74 12.32 4.75 36.434 28.077 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 1.0% !!! Local CPU util : 16.7% !!! Remote CPU util : 2.8% 32768 65536 1024 1 20.02 3384.02 11.81 4.86 34.906 28.740 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 31.0% !!! Remote CPU util : 6.7% 32768 65536 1460 1 20.02 2267.46 7.78 3.47 34.320 30.625 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 18.1% !!! Remote CPU util : 3.5% 32768 65536 1461 1 20.02 2267.38 9.16 4.01 40.420 35.385 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 16.0% !!! Remote CPU util : 3.0% 32768 65536 2920 1 20.02 2267.49 10.44 4.77 46.049 42.035 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 19.1% !!! Remote CPU util : 1.8% 32768 65536 2921 1 20.02 2267.63 11.12 5.39 49.039 47.538 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 27.6% !!! Remote CPU util : 2.4% 32768 65536 4380 1 20.02 2267.32 10.98 5.82 48.442 51.316 32768 32768 32768 65536 4381 1 20.02 2267.25 12.36 6.40 54.517 56.443 32768 32768 ------------------------------------------------------ Testing with the following command line: ./netperf -l 20 -H 192.168.1.67 -t TCP_RR -c 617730 -C 7.47812e+08 -i 10,3 -I 99,5 -- -s 0 -S 0 and these settings for response sizes 1 16 32 64 128 256 512 1024 1460 1461 2920 2921 4380 4381 TCP REQUEST/RESPONSE TEST to 192.168.1.67 : +/-2.5% @ 99% conf. !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 12.2% !!! Remote CPU util : 2.3% Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % L % I us/Tr us/Tr 32768 65536 1 1 20.02 6779.80 19.56 8.84 28.848 26.068 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 13.1% !!! Remote CPU util : 2.1% 32768 65536 1 16 20.02 6779.34 20.16 8.91 29.738 26.282 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 12.2% !!! Remote CPU util : 1.0% 32768 65536 1 32 20.02 6778.63 19.75 8.90 29.141 26.249 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 8.8% !!! Remote CPU util : 1.4% 32768 65536 1 64 20.02 6778.66 19.60 8.83 28.918 26.051 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 9.2% !!! Remote CPU util : 2.9% 32768 65536 1 128 20.02 6775.18 20.36 8.94 30.056 26.391 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.2% !!! Local CPU util : 5.1% !!! Remote CPU util : 1.6% 32768 65536 1 256 20.02 6764.86 19.72 8.92 29.146 26.386 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 1.6% !!! Local CPU util : 11.0% !!! Remote CPU util : 4.0% 32768 65536 1 512 20.02 3382.19 11.72 4.70 34.653 27.785 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 1.6% !!! Local CPU util : 18.4% !!! Remote CPU util : 3.3% 32768 65536 1 1024 20.02 3376.75 13.32 4.80 39.453 28.409 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 20.5% !!! Remote CPU util : 7.9% 32768 65536 1 1460 20.02 2267.61 8.90 3.45 39.260 30.449 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 20.9% !!! Remote CPU util : 2.0% 32768 65536 1 1461 20.02 2267.56 10.48 4.93 46.213 43.471 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 17.6% !!! Remote CPU util : 2.0% 32768 65536 1 2920 20.02 2267.37 14.23 6.16 62.744 54.326 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.0% !!! Local CPU util : 11.3% !!! Remote CPU util : 1.8% 32768 65536 1 2921 20.02 2267.23 14.97 6.91 66.024 60.963 32768 32768 32768 65536 1 4380 20.02 2267.16 15.49 7.21 68.317 63.619 32768 32768 !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 0.1% !!! Local CPU util : 8.7% !!! Remote CPU util : 1.2% 32768 65536 1 4381 20.02 2266.94 17.38 8.63 76.654 76.099 32768 32768 ------------------------------------------------------ Testing with the following command line: ./netperf -l 20 -H 192.168.1.67 -t TCP_STREAM -c 617730 -C 7.47812e+08 -i 10,3 -I 99,5 -- -s 0 -S 0 and these settings for response sizes 1 16 32 64 128 256 512 1024 1460 1461 2920 2921 4380 4381 TCP STREAM TEST to 192.168.1.67 : +/-2.5% @ 99% conf. : nodelay Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % L % I us/KB us/KB 32768 32768 1 20.02 0.62 78.65 48.03 10438.249 12746.943 32768 32768 16 20.02 9.36 76.02 47.06 665.169 823.589 32768 32768 32 20.02 18.41 74.27 46.11 330.449 410.291 32768 32768 64 20.04 35.24 71.44 44.17 166.096 205.359 32768 32768 128 20.02 68.50 74.40 43.40 88.977 103.819 32768 32768 256 20.02 122.86 70.02 40.25 46.689 53.675 32768 32768 512 20.03 229.41 67.64 39.22 24.156 28.013 32768 32768 1024 20.02 545.71 89.18 53.25 13.387 15.986 32768 32768 1460 20.02 524.13 51.96 37.13 8.121 11.606 32768 32768 1461 20.02 497.88 75.54 52.93 12.429 17.419 32768 32768 2920 20.02 524.01 49.54 35.45 7.745 11.085 32768 32768 2921 20.02 524.77 64.57 43.77 10.080 13.667 32768 32768 4380 20.02 523.93 48.57 32.78 7.594 10.252 32768 32768 4381 20.02 559.45 64.57 41.86 9.455 12.260 ------------------------------------------------------ ./netperf -l 120 -H 192.168.1.67 -t TCP_CRR -c 617730 -C 7.47812e+08 -i 10,3 -I 99,5 -- -s 0 -S 0 TCP Connect/Request/Response TEST to 192.168.1.67 : +/-2.5% @ 99% conf. Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % % us/Tr us/Tr 32768 65536 1 1 120.13 3382.71 36.19 23.95 106.984 70.808 32768 32768 # ./netperf -l 20 -H 192.168.1.67 -c 617730 -i 10,3 -I 99,5 -- -s 128K -S 128K -m 32K TCP STREAM TEST to 192.168.1.67 : +/-2.5% @ 99% conf. Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % L % U us/KB us/KB 131072 131072 32768 20.02 909.39 81.58 -1.00 7.349 -1.000 --------------10B7BF6B577D00E216820906-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 12:12:35 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDBE037B401 for ; Tue, 4 Mar 2003 12:12:34 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EE4343F3F for ; Tue, 4 Mar 2003 12:12:34 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.8/8.12.8) with ESMTP id h24KCSSd004680; Tue, 4 Mar 2003 12:12:28 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h24KCSxt000683; Tue, 4 Mar 2003 12:12:28 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h24KCSG1000682; Tue, 4 Mar 2003 12:12:28 -0800 (PST) (envelope-from marcel) Date: Tue, 4 Mar 2003 12:12:27 -0800 From: Marcel Moolenaar To: raj@cup.hp.com Cc: ia64@FreeBSD.ORG Subject: Re: initial netperf tests on rx2600 Message-ID: <20030304201227.GA523@athlon.pn.xcllnt.net> References: <3E6401FD.E2B384E3@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E6401FD.E2B384E3@hp.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 03, 2003 at 05:31:41PM -0800, Rick Jones wrote: > > BTW, what would be the "best" way for netperf to obtain programatic CPU > utilization figures. At present, it measures CPU util by taking "idle > rates" before a test and comparing them with during a test. What api > might netperf call to retrieve that sort of data? I think getloadavg(3) might be the one. I don't know anything about netperf though... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 13: 3:29 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E55DD37B40A for ; Tue, 4 Mar 2003 13:03:27 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EBED43FBF for ; Tue, 4 Mar 2003 13:03:27 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.8/8.12.8) with ESMTP id h24L3QSd004913 for ; Tue, 4 Mar 2003 13:03:26 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h24L3Qxt000874 for ; Tue, 4 Mar 2003 13:03:26 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h24L3Qdr000873 for ia64@freebsd.org; Tue, 4 Mar 2003 13:03:26 -0800 (PST) (envelope-from marcel) Date: Tue, 4 Mar 2003 13:03:26 -0800 From: Marcel Moolenaar To: ia64@freebsd.org Subject: CD image of development branch Message-ID: <20030304210326.GA818@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Gang, I'm now building a release based on the development branch and will make it available when it's ready. This may take a while (I expect it will take a week or so), because the machine on which I'm running the release is also heavily used by our ports building cluster. I don't feel a need to relocate the release build (or suspend the ports building), so I just let it run to completion or failure, whichever comes first... JFYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 13:18:21 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C9F437B401 for ; Tue, 4 Mar 2003 13:18:20 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id B500343F85 for ; Tue, 4 Mar 2003 13:18:17 -0800 (PST) (envelope-from rick_jones2@hp.com) Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 3E2DB1C02037 for ; Tue, 4 Mar 2003 13:18:17 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id NAA22883 for ; Tue, 4 Mar 2003 13:18:02 -0800 (PST) Message-ID: <3E65180A.8B39FA19@hp.com> Date: Tue, 04 Mar 2003 13:18:02 -0800 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: ia64@FreeBSD.ORG Subject: Re: initial netperf tests on rx2600 References: <3E6401FD.E2B384E3@hp.com> <20030304201227.GA523@athlon.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I think getloadavg(3) might be the one. I don't know anything about > netperf though... The manpage for getloadavg seems to return just that - the load average. While that is a measure of load, it isn't the same as the CPU util. On HP-UX I use pstat() calls, on Linux /proc/stat, on Solaris kstat(). rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 13:48:45 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A427737B401 for ; Tue, 4 Mar 2003 13:48:44 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C554243FBF for ; Tue, 4 Mar 2003 13:48:43 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.8/8.12.8) with ESMTP id h24LfAG1027488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 4 Mar 2003 16:41:10 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h24Lf5973455; Tue, 4 Mar 2003 16:41:05 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15973.7537.476710.330402@grasshopper.cs.duke.edu> Date: Tue, 4 Mar 2003 16:41:05 -0500 (EST) To: raj@cup.hp.com Cc: ia64@FreeBSD.ORG Subject: Re: initial netperf tests on rx2600 In-Reply-To: <3E65180A.8B39FA19@hp.com> References: <3E6401FD.E2B384E3@hp.com> <20030304201227.GA523@athlon.pn.xcllnt.net> <3E65180A.8B39FA19@hp.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Rick Jones writes: > > I think getloadavg(3) might be the one. I don't know anything about > > netperf though... > > The manpage for getloadavg seems to return just that - the load average. > While that is a measure of load, it isn't the same as the CPU util. On > HP-UX I use pstat() calls, on Linux /proc/stat, on Solaris kstat(). > I think you want the kern.cp_time sysctl. Look at sys/dkstat.h (or sys/resource.h if your source is new enough). And see the sysctl(3) man page. This provides a whole-system measurement, as taken from the kernel's statclock routine. I hacked an older version of netperf to use this on an older version of freebsd (where I had to grovel in /dev/kmem). Drew PS: I work for Myricom now. I have the (empty) bag of Famous Amos cookies you gave Feldy for the first netperf submission hanging in an honored spot in my office. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 14: 1:50 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50C6D37B401 for ; Tue, 4 Mar 2003 14:01:49 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id B414043FBD for ; Tue, 4 Mar 2003 14:01:48 -0800 (PST) (envelope-from rick_jones2@hp.com) Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 591F91C020B8 for ; Tue, 4 Mar 2003 14:01:48 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id OAA23582 for ; Tue, 4 Mar 2003 14:01:47 -0800 (PST) Message-ID: <3E65224B.1DE56ADF@hp.com> Date: Tue, 04 Mar 2003 14:01:47 -0800 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: ia64@FreeBSD.ORG Subject: Re: initial netperf tests on rx2600 References: <3E6401FD.E2B384E3@hp.com> <20030304201227.GA523@athlon.pn.xcllnt.net> <3E65180A.8B39FA19@hp.com> <15973.7537.476710.330402@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I think you want the kern.cp_time sysctl. > > Look at sys/dkstat.h (or sys/resource.h if your source is new enough). > And see the sysctl(3) man page. Looks like sys/resource.h will define the structure if I do a -D_KERNEL. I may "cheat" and copy the structure def into my own code. (btw, what predefine by the comiler should I be useing for FreeBSD? while I am at it I _may_ try to add BSD sendfile support for the TCP_SENDFILE test) the sysctl(3) manpage doesn't mention cp_time as being part of the CTL_KERN set - probably a manpage oversight? > This provides a whole-system measurement, as taken from the kernel's > statclock routine. I hacked an older version of netperf to use this > on an older version of freebsd (where I had to grovel in /dev/kmem). eeeew, /dev/kmem :) I try to avoid that now :) > PS: I work for Myricom now. I have the (empty) bag of Famous Amos > cookies you gave Feldy for the first netperf submission hanging in an > honored spot in my office. ah yes, the cookies - I'll have to get back to sending those out one of these days - probably after I manage to revamp the www.netperf.org site - which probably won't happen until my tribute to the second system effect and mythical manmonth - netperf4 - is ready :) rick -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 14:36:39 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 287C837B401 for ; Tue, 4 Mar 2003 14:36:36 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D87C43FBD for ; Tue, 4 Mar 2003 14:36:35 -0800 (PST) (envelope-from rick_jones2@hp.com) Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id EB9671C01D10 for ; Tue, 4 Mar 2003 14:36:34 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id OAA24193 for ; Tue, 4 Mar 2003 14:36:34 -0800 (PST) Message-ID: <3E652A72.98A4B99B@hp.com> Date: Tue, 04 Mar 2003 14:36:34 -0800 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: ia64@FreeBSD.ORG Subject: Re: initial netperf tests on rx2600 References: <3E6401FD.E2B384E3@hp.com> <20030304201227.GA523@athlon.pn.xcllnt.net> <3E65180A.8B39FA19@hp.com> <15973.7537.476710.330402@grasshopper.cs.duke.edu> <3E65224B.1DE56ADF@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Rick Jones wrote: > (btw, what predefine by the comiler should I be useing for FreeBSD? > while I am at it I _may_ try to add BSD sendfile support for the > TCP_SENDFILE test) I came across (after guesses :) __FreeBSD__ and now have sendfile() support that appears to work. # ./netperf -c 617730 -t TCP_STREAM -H 192.168.1.67 -l 20 -- -s 128K -S 128K -m 32K TCP STREAM TEST to 192.168.1.67 Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % L % U us/KB us/KB 131072 131072 32768 20.02 931.09 88.94 -1.00 7.825 -1.000 and then sendfile: # ./netperf -F ./netperf -c 617730 -t TCP_SENDFILE -H 192.168.1.67 -l 20 -- -s 128K -S 128K -m 32K TCP SENDFILE TEST to 192.168.1.67 Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % L % U us/KB us/KB 131072 131072 32768 20.02 948.42 53.19 -1.00 4.594 -1.000 this will be part of 2.2pl4. for those anxious to have it now, here are the diffs: $ diff -c netperf-2.2pl3/nettest_bsd.c nettest_bsd.c *** netperf-2.2pl3/nettest_bsd.c Fri Feb 14 15:32:44 2003 --- nettest_bsd.c Tue Mar 4 14:34:18 2003 *************** *** 3,9 **** #endif /* NEED_MAKEFILE_EDIT */ #ifndef lint char nettest_id[]="\ ! @(#)nettest_bsd.c (c) Copyright 1993-2003 Hewlett-Packard Co. Version 2.2pl3"; #else #define DIRTY #define HISTOGRAM --- 3,9 ---- #endif /* NEED_MAKEFILE_EDIT */ #ifndef lint char nettest_id[]="\ ! @(#)nettest_bsd.c (c) Copyright 1993-2003 Hewlett-Packard Co. Version 2.2pl3+"; #else #define DIRTY #define HISTOGRAM *************** *** 145,152 **** -m bytes Set the send size (TCP_STREAM, UDP_STREAM)\n\ -M bytes Set the recv size (TCP_STREAM, UDP_STREAM)\n\ -p min[,max] Set the min/max port numbers for TCP_CRR, TCP_TRR\n\ ! -r bytes Set request size (TCP_RR, UDP_RR)\n\ ! -R bytes Set response size (TCP_RR, UDP_RR)\n\ -s send[,recv] Set local socket send/recv buffer sizes\n\ -S send[,recv] Set remote socket send/recv buffer sizes\n\ \n\ --- 145,151 ---- -m bytes Set the send size (TCP_STREAM, UDP_STREAM)\n\ -M bytes Set the recv size (TCP_STREAM, UDP_STREAM)\n\ -p min[,max] Set the min/max port numbers for TCP_CRR, TCP_TRR\n\ ! -r req,[rsp] Set request/response sizes (TCP_RR, UDP_RR)\n\ -s send[,recv] Set local socket send/recv buffer sizes\n\ -S send[,recv] Set remote socket send/recv buffer sizes\n\ \n\ *************** *** 2579,2585 **** send_ring->fildes, &scratch_offset, /* modified after the call! */ send_ring->length)) != send_size) { ! #else /* original sendile HP-UX and then BSD */ if ((len=sendfile(send_socket, send_ring->fildes, send_ring->offset, --- 2578,2594 ---- send_ring->fildes, &scratch_offset, /* modified after the call! */ send_ring->length)) != send_size) { ! #elif defined(__FreeBSD__) ! /* so close to HP-UX and yet so far away... :) */ ! if ((sendfile(send_ring->fildes, ! send_socket, ! send_ring->offset, ! send_ring->length, ! NULL, ! (off_t *)&len, ! send_ring->flags) != 0) || ! (len != send_size)) { ! #else /* original sendile HP-UX */ if ((len=sendfile(send_socket, send_ring->fildes, send_ring->offset, $ -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Mar 4 20:47:50 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 017A537B401 for ; Tue, 4 Mar 2003 20:47:50 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB6B243FB1 for ; Tue, 4 Mar 2003 20:47:48 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.8/8.12.8) with ESMTP id h254lmSd006780; Tue, 4 Mar 2003 20:47:48 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h254lhxt042159; Tue, 4 Mar 2003 20:47:43 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h254lgk1042158; Tue, 4 Mar 2003 20:47:42 -0800 (PST) (envelope-from marcel) Date: Tue, 4 Mar 2003 20:47:42 -0800 From: Marcel Moolenaar To: Kris Kennaway Cc: ia64@FreeBSD.ORG Subject: Re: openldap broken ("Illegal instruction (core dumped)") Message-ID: <20030305044742.GA41640@athlon.pn.xcllnt.net> References: <20030303035536.GA34594@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030303035536.GA34594@rot13.obsecurity.org> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Mar 02, 2003 at 07:55:36PM -0800, Kris Kennaway wrote: > http://bento.freebsd.org/errorlogs/ia64-5-latest/openldap12-1.2.13.log > > This may warrant investigation. Fixed. We probably want to upgrade pluto1 and pluto2 now and include libc_r in the buildworld. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Thu Mar 6 5:58:28 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B9737B401 for ; Thu, 6 Mar 2003 05:58:27 -0800 (PST) Received: from uk.com (TC218-187-144-136.adsl.pl.apol.com.tw [218.187.144.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0F6F43F85 for ; Thu, 6 Mar 2003 05:58:22 -0800 (PST) (envelope-from dhes@uk.com) From: tyjnt5@ergfv4r.com Subject: =?ISO-8859-1?B?v/qw96XOISGnT8RGpEikRiEh?= Reply-To: 35yhw@nu6j.com Date: 06 Mar 2003 21:58:23 +0800 MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: <20030306135822.E0F6F43F85@mx1.FreeBSD.org> To: undisclosed-recipients: ; Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 十分之一的瀏覽者選擇進入

十分之一的瀏覽者　選擇進入

十之九的瀏覽者　選擇關閉視窗

然而　我們很滿意這樣的比例　

因為…

這裡的人　所擁有的非凡生活

多是在一種不凡思維下所引發的不凡決定後　偷偷開始的

enter

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Thu Mar 6 18:16:47 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61B2B37B405; Thu, 6 Mar 2003 18:16:42 -0800 (PST) Received: from hermes.sc.intel.com (fmr03.intel.com [143.183.121.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66FEA43F93; Thu, 6 Mar 2003 18:16:41 -0800 (PST) (envelope-from adsharma@unix-os.sc.intel.com) Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by hermes.sc.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h272E7O23398; Fri, 7 Mar 2003 02:14:07 GMT Received: from unix-os.sc.intel.com (unix-os.sc.intel.com [143.183.96.244]) by petasus.sc.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with ESMTP id h272Ffm15769; Fri, 7 Mar 2003 02:15:41 GMT Received: from unix-os.sc.intel.com.intel.com (adsharma-mobl3.sc.intel.com [143.183.130.51]) by unix-os.sc.intel.com (8.11.6/8.11.2) with ESMTP id h272Gev29185; Thu, 6 Mar 2003 18:16:40 -0800 Date: Thu, 6 Mar 2003 18:16:40 -0800 Message-Id: <200303070216.h272Gev29185@unix-os.sc.intel.com> To: freebsd-ia64@freebsd.org Cc: jdp@freebsd.org Subject: Review fix for ia64/48024 From: Arun Sharma Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following changes are proposed to: rtld-elf - factor out alloc_fptrs into a function of its own - update the fptrs array of the defining object rather than the referencing object - We use the same algorithm to index fptrs array now in make_function_pointer and reloc_non_plt_obj. Issues: - Is it possible to make an out of bounds access to the fptr array ? -Arun --- ia64/reloc.c- Fri Mar 7 02:06:30 2003 +++ ia64/reloc.c Fri Mar 7 02:06:16 2003 @@ -77,6 +77,31 @@ static struct fptr *next_fptr = &first_chunk.fptrs[0]; static struct fptr *last_fptr = &first_chunk.fptrs[FPTR_CHUNK_SIZE]; +static struct fptr ** +alloc_fptrs(const Obj_Entry *obj, Obj_Entry *obj_rtld) +{ + struct fptr **fptrs; + int fbytes = obj->nchains * sizeof(struct fptr *); + + /* + * When relocating rtld itself, we need to avoid using malloc. + */ + if (obj == obj_rtld) { + fptrs = mmap(NULL, fbytes, PROT_READ|PROT_WRITE, + MAP_ANON, -1, 0); + if (fptrs == MAP_FAILED) + fptrs = NULL; + } else { + fptrs = (struct fptr **) + malloc(obj->nchains * sizeof(struct fptr *)); + } + + if (fptrs != NULL) + memset(fptrs, 0, fbytes); + + return fptrs; +} + /* * We use static storage initially so that we don't have to call * malloc during init_rtld(). @@ -101,8 +126,9 @@ /* Relocate a non-PLT object with addend. */ static int reloc_non_plt_obj(Obj_Entry *obj_rtld, Obj_Entry *obj, const Elf_Rela *rela, - SymCache *cache, struct fptr **fptrs) + SymCache *cache) { + struct fptr **fptrs; Elf_Addr *where = (Elf_Addr *) (obj->relocbase + rela->r_offset); switch (ELF_R_TYPE(rela->r_info)) { @@ -135,9 +161,7 @@ /* * We have to make sure that all @fptr references to * the same function are identical so that code can - * compare function pointers. We actually only bother - * to ensure this within a single object. If the - * caller's alloca failed, we don't even ensure that. + * compare function pointers. */ const Elf_Sym *def; const Obj_Entry *defobj; @@ -150,18 +174,28 @@ return -1; if (def->st_shndx != SHN_UNDEF) { + int index; target = (Elf_Addr)(defobj->relocbase + def->st_value); gp = (Elf_Addr)defobj->pltgot; + fptrs = defobj->priv; + index = def - defobj->symtab; + + if (!fptrs) { + /* Need to allocate one */ + fptrs = alloc_fptrs(defobj, obj_rtld); + if (fptrs) + ((Obj_Entry*) defobj)->priv = fptrs; + } /* * Find the @fptr, using fptrs as a helper. */ if (fptrs) - fptr = fptrs[ELF_R_SYM(rela->r_info)]; + fptr = fptrs[index]; if (!fptr) { fptr = alloc_fptr(target, gp); if (fptrs) - fptrs[ELF_R_SYM(rela->r_info)] = fptr; + fptrs[index] = fptr; } } else fptr = NULL; @@ -221,7 +255,6 @@ SymCache *cache; struct fptr **fptrs; int bytes = obj->nchains * sizeof(SymCache); - int fbytes = obj->nchains * sizeof(struct fptr *); int r = -1; /* @@ -234,21 +267,9 @@ if (cache != NULL) memset(cache, 0, bytes); - /* - * When relocating rtld itself, we need to avoid using malloc. - */ - if (obj == obj_rtld) { - fptrs = mmap(NULL, fbytes, PROT_READ|PROT_WRITE, - MAP_ANON, -1, 0); - if (fptrs == MAP_FAILED) - fptrs = NULL; - } else { - fptrs = (struct fptr **) - malloc(obj->nchains * sizeof(struct fptr *)); - } + fptrs = alloc_fptrs(obj, obj_rtld); if (fptrs == NULL) goto done; - memset(fptrs, 0, fbytes); /* Perform relocations without addend if there are any: */ rellim = (const Elf_Rel *) ((caddr_t) obj->rel + obj->relsize); @@ -258,14 +279,14 @@ locrela.r_info = rel->r_info; locrela.r_offset = rel->r_offset; locrela.r_addend = 0; - if (reloc_non_plt_obj(obj_rtld, obj, &locrela, cache, fptrs)) + if (reloc_non_plt_obj(obj_rtld, obj, &locrela, cache)) goto done; } /* Perform relocations with addend if there are any: */ relalim = (const Elf_Rela *) ((caddr_t) obj->rela + obj->relasize); for (rela = obj->rela; obj->rela != NULL && rela < relalim; rela++) { - if (reloc_non_plt_obj(obj_rtld, obj, rela, cache, fptrs)) + if (reloc_non_plt_obj(obj_rtld, obj, rela, cache)) goto done; } @@ -290,10 +311,12 @@ if (cache) munmap(cache, bytes); if (fptrs) { - if (obj == obj_rtld) + if (obj == obj_rtld) { + int fbytes = obj->nchains * sizeof(struct fptr *); munmap(fptrs, fbytes); - else + } else { free(fptrs); + } } return (r); } @@ -449,9 +472,9 @@ * dlsym("dlopen"). Actually, I'm not sure it can ever * happen. */ - fptrs = (struct fptr **) - malloc(obj->nchains * sizeof(struct fptr *)); - memset(fptrs, 0, obj->nchains * sizeof(struct fptr *)); + + /* assume obj != obj_rtld */ + fptrs = alloc_fptrs((Obj_Entry *) obj, NULL); ((Obj_Entry*) obj)->priv = fptrs; } if (!fptrs[index]) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Thu Mar 6 19:40:30 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96EA737B401; Thu, 6 Mar 2003 19:40:29 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8507343FA3; Thu, 6 Mar 2003 19:40:28 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.8/8.12.8) with ESMTP id h273eSSd018599; Thu, 6 Mar 2003 19:40:28 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.8/8.12.8) with ESMTP id h273eRQh002022; Thu, 6 Mar 2003 19:40:27 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.8/8.12.8/Submit) id h273eRZ0002021; Thu, 6 Mar 2003 19:40:27 -0800 (PST) Date: Thu, 6 Mar 2003 19:40:27 -0800 From: Marcel Moolenaar To: Arun Sharma Cc: freebsd-ia64@FreeBSD.ORG, jdp@FreeBSD.ORG Subject: Re: Review fix for ia64/48024 Message-ID: <20030307034027.GA1962@athlon.pn.xcllnt.net> References: <200303070216.h272Gev29185@unix-os.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303070216.h272Gev29185@unix-os.sc.intel.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Mar 06, 2003 at 06:16:40PM -0800, Arun Sharma wrote: > > The following changes are proposed to: rtld-elf > > - factor out alloc_fptrs into a function of its own > - update the fptrs array of the defining object rather than the > referencing object > - We use the same algorithm to index fptrs array now in > make_function_pointer and reloc_non_plt_obj. > > Issues: > > - Is it possible to make an out of bounds access to the fptr array ? Yes. nchains depends on the number of symbols exposed to to the dynamic linker (ie the number of symbols that can be found though the hash table). This is generally less than the actual number of symbols in the symbol table and thus the index of the symbol in the symbol table of the defining load module. I'm also not sure if allocating an array of pointers is optimal, but that's a seperate issue. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Mar 7 8:38:57 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00B1737B401 for ; Fri, 7 Mar 2003 08:38:57 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6A8A43F85 for ; Fri, 7 Mar 2003 08:38:55 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h27GcqJL006757 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 Mar 2003 08:38:52 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.6/8.12.6/Submit) id h27GcpGs014116; Fri, 7 Mar 2003 08:38:51 -0800 (PST) (envelope-from jdp) Date: Fri, 7 Mar 2003 08:38:51 -0800 (PST) Message-Id: <200303071638.h27GcpGs014116@vashon.polstra.com> To: ia64@freebsd.org From: John Polstra Cc: arun.sharma@intel.com Subject: Re: Review fix for ia64/48024 In-Reply-To: <200303070216.h272Gev29185@unix-os.sc.intel.com> References: <200303070216.h272Gev29185@unix-os.sc.intel.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200303070216.h272Gev29185@unix-os.sc.intel.com>, Arun Sharma wrote: > > The following changes are proposed to: rtld-elf You should run this by Alexander Kabaev . He's been doing most of the work on the dynamic linker lately. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch鐷yam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Mar 7 10: 1:28 2003 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0470537B401 for ; Fri, 7 Mar 2003 10:01:26 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B52643FB1 for ; Fri, 7 Mar 2003 10:01:24 -0800 (PST) (envelope-from fenner+portsurvey@FreeBSD.org) Received: from freefall.freebsd.org (fenner@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h27I1ONS097124 for ; Fri, 7 Mar 2003 10:01:24 -0800 (PST) (envelope-from fenner+portsurvey@freefall.freebsd.org) Received: (from fenner@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h27I1OEv097123; Fri, 7 Mar 2003 10:01:24 -0800 (PST) Date: Fri, 7 Mar 2003 10:01:24 -0800 (PST) Message-Id: <200303071801.h27I1OEv097123@freefall.freebsd.org> From: fenner@freebsd.org (Bill "distfiles" Fenner) To: freebsd-ia64@freebsd.org Subject: FreeBSD ports: 1 unfetchable distfiles: emulators/ski Reply-To: ports@freebsd.org Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear freebsd-ia64@freebsd.org, You are listed as the FreeBSD port maintainer for 1 port whose distfiles [or main web pages] are not fetchable from their MASTER_SITES. Could you please visit http://people.freebsd.org/~fenner/portsurvey/freebsd-ia64@freebsd.org.html and correct the problems listed there? The individual port with a problem is emulators/ski. Note that the main port web page, as listed in the WWW: line of the pkg-descr, is checked just as though it was a port distfile. This is an unfortunate side effect of the architecture of the distfile survey reporting tool, but if you see a distfile being reported as not fetchable that's not actually a distfile, see if it's from the pkg-descr. If you have already corrected the problems and submitted a PR, please accept my thanks and apologies for the delay in getting the fixes into the tree. This reminder is created automatically and does not (yet) have a way to know if a PR fixing the problem has been submitted. Please do *NOT* send your response to me directly; I do not always have time to commit your fix; please instead submit a PR via 'send-pr' so it doesn't get lost. Problems are usually of two types: 1. The software package has been upgraded and the version in the port has been removed. The best solution to this problem is to upgrade the port to the most current version of the software package. If you are a FreeBSD committer, then you can just upgrade the port directly. If not, you should create the updated port on your own machine, test it (and maybe even run "portlint" on it), and then use "send-pr" to submit a "diff -uNr old-port updated-port". If you added or deleted any files, please make an explicit note of it. 2. The mirror site being used no longer contains the software package in question, or no longer exists. Solutions include: a) If there are other mirror sites, just remove the bad site from the list. (Make sure that what appears to be a bad site isn't actually a problem of type 1, upgrade) b) If the README or other support files in the software documentation mention where to get the software package, use one of those sites. c) Use ftpsearch (http://ftpsearch.ntnu.no/ftpsearch) or other search engines to find another place to get the original DISTFILES. Make sure that you don't pick a FreeBSD distfiles mirror -- if you can't find any other places where the file exists, it can be a LOCAL_PORT or you can simply comment out the MASTER_SITES= line, with a comment explaining why. Once you have a solution, use "send-pr" to submit a "diff -u" of the Makefile. Note that this isn't an urgent issue, as people who try to build the port now will just fall back to the FreeBSD distfiles mirror. Please just put it on your list to do and get to it when you have time. These messages will continue to arrive twice a month until the fix is committed, as a reminder. Thanks, Bill "distfiles" Fenner. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message