برچسب: بنچمارک

مقایسه‌ی سه هارد ssd

در این مطلب سه هارد ssd مدل اینتل VK0480GEYJR (تحت برند HPE) و سامسونگ مدل MZ7KM480 و SSD 960 PRO 512GB رو مقایسه می‌کنیم.

دو مدل اول به ریدکنترلر متصل هستند و برای دیدن نتایج واقعی cahce ریدکنترلر خاموش است. مدل سوم روی pci express سرور سوار است و فقط os اون رو می‌بینه.

دو تست روی هاردهای ssd انجام می‌دیم.در تست اول برای کاری که تخصص دارند و اون نوشتن و خواندن Random هست و دیگری حالت Sequential که برای دیسک‌های معمولی هم کار راحتی و معمولا حیف برای اینجور کارها بخوایم از ssd استفاده کنیم.

هارد ssd اینتل

fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4k –iodepth=64 –size=4G –readwrite=randrw –rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [m(1)] [100.0% done] [188.4MB/64520KB/0KB /s] [48.3K/16.2K/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=14143: Sun Aug  6 15:16:46 2017
  read : io=3071.7MB, bw=192038KB/s, iops=48009, runt= 16379msec
  write: io=1024.4MB, bw=64040KB/s, iops=16010, runt= 16379msec
  cpu          : usr=8.89%, sys=45.45%, ctx=361045, majf=0, minf=605
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=3071.7MB, aggrb=192037KB/s, minb=192037KB/s, maxb=192037KB/s, mint=16379msec, maxt=16379msec
  WRITE: io=1024.4MB, aggrb=64040KB/s, minb=64040KB/s, maxb=64040KB/s, mint=16379msec, maxt=16379msec

Disk stats (read/write):
  sdc: ios=773774/258385, merge=1358/173, ticks=794948/222572, in_queue=1017672, util=99.46%

fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=test —filename=test —bs=4k —iodepth=64 —size=4G —readwrite=randrw —rwmixread=75

test: (g=0): rw=randrw, bs=4K–4K/4K–4K/4K–4K, ioengine=libaio, iodepth=64

fio–2.2.10

Starting 1 process

Jobs: 1 (f=1): [m(1)] [100.0% done] [188.4MB/64520KB/0KB /s] [48.3K/16.2K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=14143: Sun Aug 6 15:16:46 2017

read : io=3071.7MB, bw=192038KB/s, iops=48009, runt= 16379msec

write: io=1024.4MB, bw=64040KB/s, iops=16010, runt= 16379msec

cpu : usr=8.89%, sys=45.45%, ctx=361045, majf=0, minf=605

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0

latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):

READ: io=3071.7MB, aggrb=192037KB/s, minb=192037KB/s, maxb=192037KB/s, mint=16379msec, maxt=16379msec

WRITE: io=1024.4MB, aggrb=64040KB/s, minb=64040KB/s, maxb=64040KB/s, mint=16379msec, maxt=16379msec

Disk stats (read/write):

sdc: ios=773774/258385, merge=1358/173, ticks=794948/222572, in_queue=1017672, util=99.46%

نکته اول اینکه با fio سعی کردیم حالت واقعی سرور رو شبیه‌سازی کنیم 75 درصد read و 25 درصد write. مهمترین بخش هم iops هست.

iops=48009 برای read و iops=16010 برای رایت.

برای تست دوم از dd استفاده میکنیم. نکته مهم اینه که oflag=dsync به ازای هر تیکه‌ای که میخواد روی هارد بنویسه (۵۱۲ بار می‌پرسه) تاییدیه از os میگره. اما conv=fdatasync تنها یکبار در انتهای نوشتن و هنگام خروج از dd تاییدیه از os گرفته میشه.

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.96172 s, 274 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.45621 s, 369 MB/s

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync

512+0 records in

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 1.96172 s, 274 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync

512+0 records in

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 1.45621 s, 369 MB/s

هارد ssd سامسونگ مدل MZ7KM480

fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4k –iodepth=64 –size=4G –readwrite=randrw –rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [m(1)] [100.0% done] [266.7MB/90880KB/0KB /s] [68.3K/22.8K/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=14225: Sun Aug  6 15:24:17 2017
  read : io=3071.7MB, bw=271248KB/s, iops=67811, runt= 11596msec
  write: io=1024.4MB, bw=90455KB/s, iops=22613, runt= 11596msec
  cpu          : usr=14.08%, sys=52.78%, ctx=768554, majf=0, minf=605
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=3071.7MB, aggrb=271247KB/s, minb=271247KB/s, maxb=271247KB/s, mint=11596msec, maxt=11596msec
  WRITE: io=1024.4MB, aggrb=90454KB/s, minb=90454KB/s, maxb=90454KB/s, mint=11596msec, maxt=11596msec

Disk stats (read/write):
  sdb: ios=771941/257788, merge=1231/167, ticks=552804/164876, in_queue=722248, util=99.45%

fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=test —filename=test —bs=4k —iodepth=64 —size=4G —readwrite=randrw —rwmixread=75

test: (g=0): rw=randrw, bs=4K–4K/4K–4K/4K–4K, ioengine=libaio, iodepth=64

fio–2.2.10

Starting 1 process

Jobs: 1 (f=1): [m(1)] [100.0% done] [266.7MB/90880KB/0KB /s] [68.3K/22.8K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=14225: Sun Aug 6 15:24:17 2017

read : io=3071.7MB, bw=271248KB/s, iops=67811, runt= 11596msec

write: io=1024.4MB, bw=90455KB/s, iops=22613, runt= 11596msec

cpu : usr=14.08%, sys=52.78%, ctx=768554, majf=0, minf=605

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0

latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):

READ: io=3071.7MB, aggrb=271247KB/s, minb=271247KB/s, maxb=271247KB/s, mint=11596msec, maxt=11596msec

WRITE: io=1024.4MB, aggrb=90454KB/s, minb=90454KB/s, maxb=90454KB/s, mint=11596msec, maxt=11596msec

Disk stats (read/write):

sdb: ios=771941/257788, merge=1231/167, ticks=552804/164876, in_queue=722248, util=99.45%

iops=67811 برای read و iops=22613 برای رایت. که نشون میده در میون هاردهای ssd سرور سامسونگ از مدل اینتل پیشی گرفته.

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.86999 s, 287 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync
512+0 records in
512+0 records out

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync

512+0 records in

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 1.86999 s, 287 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync

512+0 records in

512+0 records out

در این تست هم سامسونگ برنده شده.

و اما مدل دیگه سامسونگ pro 960 که از پیش حدس می‌زنیم سرعت خیلی بالاتری داشته باشه.

سامسونگ pro 960

fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4k –iodepth=64 –size=4G –readwrite=randrw –rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.2.10
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [m(1)] [75.0% done] [719.6MB/240.2MB/0KB /s] [184K/61.5K/0 iops] [eta 00m:01s]

Jobs: 1 (f=1): [m(1)] [100.0% done] [690.4MB/229.5MB/0KB /s] [177K/58.8K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=14313: Sun Aug  6 15:33:11 2017
  read : io=3071.7MB, bw=705402KB/s, iops=176350, runt=  4459msec
  write: io=1024.4MB, bw=235236KB/s, iops=58808, runt=  4459msec
  cpu          : usr=19.47%, sys=70.17%, ctx=27594, majf=0, minf=367
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=3071.7MB, aggrb=705402KB/s, minb=705402KB/s, maxb=705402KB/s, mint=4459msec, maxt=4459msec
  WRITE: io=1024.4MB, aggrb=235235KB/s, minb=235235KB/s, maxb=235235KB/s, mint=4459msec, maxt=4459msec

Disk stats (read/write):
  nvme0n1: ios=766260/255818, merge=0/0, ticks=182612/2688, in_queue=185564, util=97.90%

fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=test —filename=test —bs=4k —iodepth=64 —size=4G —readwrite=randrw —rwmixread=75

test: (g=0): rw=randrw, bs=4K–4K/4K–4K/4K–4K, ioengine=libaio, iodepth=64

fio–2.2.10

Starting 1 process

test: Laying out IO file(s) (1 file(s) / 4096MB)

Jobs: 1 (f=1): [m(1)] [75.0% done] [719.6MB/240.2MB/0KB /s] [184K/61.5K/0 iops] [eta 00m:01s]

Jobs: 1 (f=1): [m(1)] [100.0% done] [690.4MB/229.5MB/0KB /s] [177K/58.8K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=14313: Sun Aug 6 15:33:11 2017

read : io=3071.7MB, bw=705402KB/s, iops=176350, runt= 4459msec

write: io=1024.4MB, bw=235236KB/s, iops=58808, runt= 4459msec

cpu : usr=19.47%, sys=70.17%, ctx=27594, majf=0, minf=367

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0

latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):

READ: io=3071.7MB, aggrb=705402KB/s, minb=705402KB/s, maxb=705402KB/s, mint=4459msec, maxt=4459msec

WRITE: io=1024.4MB, aggrb=235235KB/s, minb=235235KB/s, maxb=235235KB/s, mint=4459msec, maxt=4459msec

Disk stats (read/write):

nvme0n1: ios=766260/255818, merge=0/0, ticks=182612/2688, in_queue=185564, util=97.90%

این هارد خوب iops=176350 برای read و iops=58808 رو برای نوشتن به ما میده که البته فاصله خیلی زیادی با اعدادی داره که سامسونگ ادعا میکنه :)‌

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 3.57902 s, 150 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0.635125 s, 845 MB/s

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync

512+0 records in

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 3.57902 s, 150 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync

512+0 records in

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 0.635125 s, 845 MB/s

و در کمال تعجب میشه دید که این ssd در حالت sequential خیلی هم خوب کار نمیکنه :)

6 آگوست 2017

مقایسه زمان پاسخ‌دهی دی‌ان‌اس در شرایط مختلف

دی‌ان‌اس کارکرد اصلیش تبدیل آدرس دامین به ip سرور هست، وقتی وارد سایتی می‌شید و اسم اون رو تایپ می‌کنید، در پشت صحنه این آدرس باید تبدیل شه به آی‌پی و این بسته به دی‌ان‌اس سروری که دارید ازش استفاده می‌کنید و همینطور کشوری که درونش هستید زمانی رو می‌بره. هر چه این زمان کوتاه تر باشه یعنی دستکاری کمتره و سرعت بیشتر و کار با اینترنت دلچسپ‌تره.برای مقایسه، روی سروری که دستم بود یک دی‌ان‌اس سرور نصب کردم با برنامه ساده‌ی dnsmasq که فایل کانفیگش دو تا خط هم لازم نداره :)

listen-address=0.0.0.0
bind-interfaces

کافیه پورت ۵۳ رو باز بذارید و برنامه رو اجرا کنید و بعد هم سمت کلاینت (اگر لینوکس هستید) فایل resolv.conf رو تغییر بدید به آی‌پی سروری که در اختیار دارید داخل سرور هم میتونید دی‌ان‌اس رو به 127.0.0.1 تغییر بدید تا خود سرور هم از دی‌ان‌اس سرور خودش استفاده کنه.

برای انجام این تست از برنامه ترمینالی dig استفاده میکنیم، بهتره ادرس سایتی رو وارد کنید که قبلا وارد نشدید تا مطمئن باشید سیستم از کش استفاده نمی‌کنه.

اگه از این ابزار بدون هیچ آرگومانی استفاده کنید،‌ به صورت خودکار از dns اصلی سیستم که اون رو در فایل resolv وارد کرده باشید استفاده میکنه و از این جهت آزمایش خیلی خوبیه برای اینکه مطمئن باشید دی‌ان‌اس که دارید استفاده می‌کنید همونی هست که مد نظرتونه.

dig archlinux.org
;; Query time: 197 msec
;; SERVER: server’s ip#53(server’s ip)
;; WHEN: Thu Apr 4 19:29:43 2013
;; MSG SIZE rcvd: 31

اما حالا فرض کنید می‌خوایم با دی‌ان‌اس سرور گوگل این تست رو انجام بدیم.

dig @8.8.8.8 archlinux.org
;; Query time: 270 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Apr 4 19:35:32 2013
;; MSG SIZE rcvd: 58

در تست اول از دی‌ان‌اس شخصی استفاده شده و برای همین ip رو مخفی کردم :) سرعت زیر ۲۰۰ میلی ثانیه بوده اما با استفاده از گوگل سرعت به ۲۷۰ میلی ثانیه رسیده و این نشون میده داخل ایران استفاده دی‌ان‌اس سرورهای شناخته شده فکر خوبی نیست.

اما همین کار رو می‌شه سمت سرور که توی کشور آزادیه هم انجام داد و نتایج رو مقایسه کرد با داخل ایران!

dig archlinux.org
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 4 15:09:57 2013
;; MSG SIZE rcvd: 31

فوق العاده‌ست :) وقتی از دی‌ان‌اس سرور داخلی استفاده میشه سمت سرور سرعت به صفر میلی ثانیه می‌رسه!‌

و با استفاده از گوگل هم این نتیجه رو خواهیم داشت.

dig @8.8.8.8 archlinux.org
;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Apr 4 15:12:11 2013
;; MSG SIZE rcvd: 47

بله زمان پاسخ دهی در ایران ۱۵ برابر بیشتره :) ۱۵ برابر زمان بیشتری رو از داخل ایران باید منتظر بمونید تا یک آدرس ساده به آی‌پی‌ تبدیل شه! هر پکتی که وارد ایران می‌شه باید از داخل هزارتوهای پیچ در پیچ فایروال و روترهای مختلف عبور کنه و توسط آدمای مختلف و سیستمای مختلف شنود بشه که یک وقتی شما وارد سایتی که به مذاق آقایون خوش نمیاد نشید.

اینم تمام نتایج در یک عکس

اینجا لیستی از دی‌ان‌اس سرورهای معروف و رایگان لیست شده که می‌تونید اونها رو خودتون تست کنید. فقط دقت کنید خیلی از این موارد در داخل ایران به کل فیلتر شده :)

4 آوریل 2013
زمان بوت اوبونتو ۱۰.۰۴

در پستی، به زمان بوت اپن‌سوزه با کرنل پیشفرض و کرنل کامپایل شده اشاره ای‌داشتم. زمان بوت با کرنل پیشفرض ، ۸۵ ثانیه و با کرنل کامپایل شده (سفارشی)، ۴۰ ثانیه بود. خیلی جالبه که زمان بوت اوبونتو ۱۰.۰۴ با کرنل پیشفرض، در حالی که کاربر به صورت خودکار لاگین نمی‌شه و مجبور به وارد کردن پسورد هستیم، از کرنل سفارشی اپن‌سوزه خیلی کمتره :)

زمان بوت ۲۸ ثانیه

پی‌نوشت۱: برای دیدن جزئیات روی تصویر کلیک کنید.
پی‌نوشت۲:‌ با SSD به زمان ۲۰ ثانیه هم می‌شه رسید.

سوال: با کرنل سفارشی شده به چند ثانیه می‌رسیم؟

19 آوریل 2010
مقایسه لینوکس با اسنو و سون

نمی‌دونم چرا هی بند کردم به این کرنل! شاید چون فک می کنم خیلی راحته و خیلیا از رفتن به سمت و سوش ترس دارن!

uname -a می‌گیرم تا مشخصات کرنل رو بهتون نشون بدم.

Linux linux-19gz 2.6.33-ck1 #1 SMP PREEMPT Mon Mar 1 16:21:28 IRST 2010 x86_64 x86_64 x86_64 GNU/Linux

این یه خط چند تا نکته داره بهمون می‌گه. یکی اینکه پردازشگر ۶۴ بیتی هست و همینطور کرنل. دیگه اینکه شماره کرنل ۲.۶.۳۳ هست. اون ck1 پسوندی هست که نشون می‌ده با یه کرنل کامپایل شده از رو سورس سر و کار نداریم. بلکه ۱۳ تا وصله برای بالا بردن راندمان کرنل بهش اعمال کردیم. دیگه اینکه در تنظیمات کرنل، SMP و PREEMPT فعال هستند.

حالا ببینیم با این کرنل دستی کامپایل شده، لینوکس چه جایگاهی بین سیستم عاملای دیگه داره.

شرایط سخت‌افزاری در هر سه سیستم عامل برابر و یکسان بوده و هر سه سیستم عامل‌ها ۶۴ بیتی هستند. فرکانس کاری پردازشگر هم سه گیگاهرتز بوده (توجهی به فرکانسی که برای آی‌مک ثبت شده نکنید!)‌ . و اما بر اساس امتیازی که گیگ بنچ داده، اسنو لئوپارد اپل قوی ترین سیستم عامل و ویندوز سون ۶۴ بیتی با اختلاف کمی از لینوکس رتبه سوم رو به خودش اختصاص داده. لینوکس با کرنل سفارشی و دست ساز هم تونسته رتبه دوم رو به خودش اختصاص بده. اما باید ریز بشیم و ببینیم لینوکس کجاها داره نسبت به مک و یا احتمالا نسبت به ویندوز می‌لنگه.

برای بزرگ شدن تصویر کلیک کنید

برنامه گیگ بنج ۴ دسته امتیاز کلی رو برای همه سیستم عامل‌ها در نظر می گیره. هر دسته شامل تعدادی تست می شه.

این ۴ دسته عبارتند از integer، Floating point، memory، stream . جالب اینجاست که هر کدام از سیستم عامل‌ها در یک دسته اول شده‌اند. به جز اسنو اپل که در دو دسته مقام اول رو کسب کرده است.

برنده قسمت integer سون، برنده floating point و stream اسنو و دسته memory نیز لینوکس اول شده است.

یکی از قسمتایی که لینوکس عقب افتاده مربوط به تستای فشرده سازی نوشته‌ها و عکس (همینطور عمل عکسش) هست. حالا این ینی چی؟ببینید شما با چی نوشته ها رو فشرده می کنید؟جواب bzip2 است. من نگاه کردم دیدم آخرین نسخه این برنامه رو سوزه داره و بنابراین مشکل نسخه قدیمی برنامه نیست. پس مشکل کار کجاست؟

من تنها جایی که مشکل رو می بینم زمان خواندن و نوشتن اطلاعات بر روی پارتیشن هست! دوستان ببینید پارتیشن‌های من از نوع LVM هست و نوع آن هم ext4 هست. نمی دونم! اما یه جورایی احساس می کنم عملکرد پایین خیلی از نتایج در لینوکس همین موضوع می‌تونه باشه:)

شاید به همین دلیل است که لینوکس در دسته حافظه اول شده. چون دراین بخش، فایل سیستم معنایی ندارد پس بهترین راندمان را لینوکس در همین نقطه از خود نشان می‌دهد. اما در بقیه قسمت‌ها که به نوعی درگیر با هارد دیسک و فایل سیستم هستیم، عملکرد نسبت به اسنو اپل پایین تر است.

نکته مهم اینکه از ۲۱ تست، لینوکس فقط در ۴ تست Blowfish، mandlebrot، Read sequential و stdlib copy اول شده و اختلاف پیروزی در stdlib copy با ویندوز و مک به حدی بالاست که می‌شه گفت لینوکس داره تو خیلی از قسمتا ( رو سخت افزار من) ضعیف عمل می کنه وفقط به دلیل خوب کار کردن در یک بخش، ضعف در بقیه قسمتا رو به نوعی جبران می کنه:)

به نتایج که نگاه می‌کنیم، می‌بینیم، ویندوز تو خیلی از تستا اول هست ( ده تست از ۲۱) ! فقط چون تو چند تا تست مث blur image یا sharpen image سوتی های بدی داده، نتیجه رو حتی به لینوکس هم واگذار کرده:)

باز می‌گم، احتمال بالا خیلی از نتایج مربوط به این آزمایش، به خصوص آنهایی که با واحد گیگابایت در ثانیه اندازه گیری شده‌اند، با عوض شدن فایل سیستم می‌تونه بهبود پیدا کنه.

و اما سه نکته برای کامپایل کرنل ۲.۶.۳۳ .

اول اینکه شما می‌تونید ۱۳ پچ اقای کولیواس را یک جا به کرنل پچ کنید. یکی از این پچ‌ها BFS است. یکی دیگه از پچ‌های خیلی مهم مربوط به Timer frequency از زیر مجموعه Processor type and features هست. که بعد از پچ کردن کرنل، می‌شه مقدارش رو از هزار هرتز هم بالاتر برد. مقدار نهایی ده هزار هست!! این فرکانس از نقاط اختلاف بر انگیز بین علما هست. یک سری می‌گن این عدد هر چی بالاتر باشه بهتره. یه سری می‌گن اگه این عدد بالا باشه، برق بیشتری مصرف می شه. پس تو لب‌تابا باید این عدد رو کمتر از هزار هرتز انتخاب کرد. یه سری هم می‌گن خیلی بزرگ انتخاب کردن این عدد می‌تونه منجر به ناپایداری سیستم شه:)) یکی از وصله‌ها باعث می‌شه پسوند ck به انتهای شماره کرنل اضافه شه :-D . یکی هم باعث بهبود در عملکرد preempt لینوکس خواهد شد.

برای اعمال پچ هم کافیه، پچ و سورس کرنل در یک دایرکتوری قرار داشته باشن(بعد از خارج شدن از حالت فشرده) . با اعمال دستور زیر هر ۱۳ تا پچ به کرنل وصله خواهند شد.

patch < patch-2.6.33-ck1 -p1

بعد هم به صورت عادی می‌شه کرنل رو کانفیگ و کامپایل کرد(اضافه کردن زمانبندی فرکانس یادتون نره) .

اما نکته مهمتر در مورد کرنل ۲.۶.۳۳ اینکه شما همه کارا رو درست انجام دادید. کار تموم شده. نوبت می‌رسه به نصب درایور کارت گرافیکی انویدیا.

جالبه بدونید درایور رسمی انویدیا موقع نصب به شما پیغام خطا خواهد داد. برای حل این مشکل شما باید از یک پچ استفاده کنید. این پچ رو اینبار به درایور انویدیا وصله پینه می‌کنیم:)) و ربطی به کرنل نداره:دی

برای اینکار بسته به درایور انویدیایی که دارید یکی از دو پچ زیر را دانلود کنید.

nvidia-190.53-2.6.33.patch.txt
nvidia-195-2.6.33.patch.txt

بعد از اینکه مطمئن شدید که پچ و درایور رسمی انویدیا در یک دایرکتوری قرار دارند، با یکی از دو دستور زیر (بسته به نسخه درایور) پچ رو اعمال کنید. توجه کنید درایور رسمی انویدیا باید مجوز اجرا شدن را نیز داشته باشد(chmod 777 NVidia.run)

./NVIDIA-Linux-x86-190.53-pkg1.run –apply-patch nvidia-190.53-2.6.33.patch.txt
./NVIDIA-Linux-x86-195.30-pkg1.run –apply-patch nvidia-195-2.6.33.patch.txt

با اعمال دستور بالا درایور پچ شده انویدیا به صورت زیر در دایرکتوری جاری ساخته خواهند شد.

./NVIDIA-Linux-x86-190.53-pkg1-custom.run
./NVIDIA-Linux-x86-195.30-pkg1-custom.run

که از این به بعد می‌شه با این درایور به صورت معمول کار کرد(sudo ./NVIDIA-Linux-x86_64-195.30-pkg2-custom.run).

و اما نکته آخر اینکه آخرین نسخه از درایور رسمی انویدیا ( NVIDIA-Linux-x86_64-195.36.08-pkg2.run ) به صورت رسمی منتشر شده! اما همچنان فک نکنم بشه رو کرنل ۲.۶.۳۳ نصبش کرد و باید منتظر پچ اصلاحیش باشیم:)

6 مارس 2010
قلب توزیعتون رو روغن کاری کنید

قلب هر توزیع، میشه کرنل لینوکس. توی پستی به نحوه کامپایل کرنل لینوکس تا حدودی اشاره کرده بودم. از اون موقع تا حالا تجربه خودم خیلی زیاد شده و اینکه تونستم به کرنلی برسم که حتی یک پیغام خطا تولید نمی‌کنه. اما اگه بهترین تنظیمات رو هم انجام بدید، امتیاز سیستم از حدی فراتر نمی‌ره. در اینجا یعنی به سقف و به بهترین کارایی که یک کرنل می‌تونه داشته باشه، رسیدین(بالاترین راندمان)! و تنها کاری که می‌شه از این به بعد کرد، انتظار برای نسخه جدید کرنل هست و دعا برای اینکه امتیاز سیستم بالاتر بره.

اما می‌توان پا را از این فراتر گذاشت و آن چیزی جز روغن کاری کرنل و به اصطلاح فنی پچ کردن کرنل نیست. توزیع‌های اصلی مث سوزه یا فدورا و اوبونتو از طریق پچ کردن تغییرات دلخواه و مطلوب خودشون رو بر روی کرنل اعمال می‌کنند.

یکی از بهترین پچ‌هایی که به صورت تصادفی با ان اشنا شدم، پچی موسوم به BFS هست که نباید آن را با فایل سیستم bfs اشتباه بگیرید! این پچ مناسب کاربران خانگی، یعنی کسانی که سیستم دسکتاب دارند، می‌باشد. تا سقف ۱۶ هسته، این پچ جادو می‌کند. یعنی اگر شما ۱۶ هسته داشته باشید و بخواهید استفاده شخصی از سیستم داشته باشید، این پچ یکی از بهترین‌های موجود در بازار است:)‌ این اسم را سازنده آن آقای کولیواس، برای آن انتخاب کرده و اعلام کرده مناسب ماشین‌های کوچک می‌باشد و نباید توقع داشته باشید بر روی ماشین‌های سرور خوب جواب دهد. BFS دقیقا در مقابل CFS کرنل قرار می‌گیرد و به جای آن می‌نشیند. cfs یعنی (Completely Fair Scheduler) تقسیم کار به صورت عادلانه در یک ماشین.

برای یک دسکتاب به دلیل تک کاربره بودن، باید حداکثر قدرت پردازشگر به کاری اختصاص داده شود، که کاربر قصد انجام آن را دارد. دقیقا برعکس یک ماشین مخصوص سرور که باید برای انجام هر کار بار کمتری به پردازشگر اعمال شود تا بتوان تعداد بیشتری از درخواست‌ها را مدیریت کرد. BFS به طعنه مخفف تقسیم کاری است که توسط یک مغز نابغه صورت می‌گیرد (Brain Fuck Scheduler). و اما مقایسه یک کرنل عادی (CFS)‌ با کرنل پچ شده (BFS) می‌تونه جالب باشه.

(بیشتر…)

27 فوریه 2010

برچسب: بنچمارک

مقایسه‌ی سه هارد ssd

هارد ssd اینتل

هارد ssd سامسونگ مدل MZ7KM480

سامسونگ pro 960

مقایسه زمان پاسخ‌دهی دی‌ان‌اس در شرایط مختلف

زمان بوت اوبونتو ۱۰.۰۴

مقایسه لینوکس با اسنو و سون

قلب توزیعتون رو روغن کاری کنید