Re: vblade-22-rc1 is first release candidate for version 22

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So I do find it interesting to have a configuration to limit the size of the read/write request but it seems like it would be useful to understand the side affects on why someone would want to do this. Catalin suggested that reducing the size of the jumbo frames decreases latency and improves boot-times and said that the system "feels more response". This is were I have a problem though because something "feeling" more responsive is not very satisfying. It would be better to have some hard numbers behind what this change does. 

AoE using normal Ethernet frames end up having a protocol efficiency of only 89.82% which on a 1Gb Ethernet would give you a theoretical maximum throughput of ~112 MB/s. Going up to a 9000 byte frame bumps the efficiency to 98.68% and a theoretical max throughput of ~123 MB/s. Something interesting about jumbo frames though is that it ends up being able to request 17 sectors of data per request. 

Why is this interesting? Because on some Linux systems, a page size is 4096 or 8 sectors so the 17 sectors works out to 2 full pages plus touching into another page. If you are not using direct IO but instead letting Linux manage the underlying file system then it would seem like you will end up making unaligned IO requests of the system causing additional I/Os to be issued. This might be the reason for the latency affects and it would be interesting to get the numbers that Catalin may have in his tests... I wouldn't mind seeing results for 17, 16, 8 sector count requests. 

But what I don't understand is that if the throughput is 80 MB/s and drops to 60 MB/s as Catalin suggests then I don't get how a 20 MB/s drop in throughput would make the system be more responsive ... I also don't understand what the test setup would be to even measure the affects of latency, throughput and having it correlate to responsiveness?

David
------------------------------------------------------------------------------
_______________________________________________
Aoetools-discuss mailing list
Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/aoetools-discuss

[Index of Archives]     [Linux ARM Kernel]     [Linux SCSI]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux