lör 2006-03-11 klockan 13:46 -0800 skrev Mike Leong: > I get 100mbps speed if I scp a large file from server -> > client. Definitely not cabling/nic issues. Best test it with netperf in bidirectional mode just to be sure.. In my unscientific tests using httperf hitting a single 20KByte object on A 1GHz PIII laptop with e100 mini-pci nic with one request per connection (no keep-alive): concurrency replies/s responsetime bandwidth memory: 20 485 10,6/23,1 9,8 MByte/s 100 561 62,2/92,2 11,5 MByte/s 400 556 209,3/412,0 11,4 Mbyte/s 1000 546 629,9/848,5 11,1 Mbyte/s ufs: 20 478 11,4/23,6 9,6 MByte/s 400 530 238,7/425,4 11,0 MByte/s 1000 509 727,9/947,1 10,5 MByte/s aufs: 20 442 13,3/27,2 9,0 MByte/s 400 545 228,9/409,3 11,4 MByte/s 1000 530 690,1/759,4 11,0 MByte/s bandwidth measured at the packet level, counting the number of octets in each ethernet frame received. response time is in milliseconds, with the first number being the time until httperf had received the response header and the second the complete transfer time. As long as the dataset fits in memory numbers should be pretty much constant no matter how many objects is involved. Note: I have no explanation to why the aufs numbers is slightly better than ufs in the above tests. Did seriously expect the opposite as aufs by it's async design adds a bit of CPU and latency overhead compared to ufs and should not be faster on hot objects.. (hot == already in the OS maintained filesystem buffer/cache) The station running httperf is a Athlon 64 4200+ if anyone wonders. Regards Henrik
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
