meep Posted February 10, 2011 Share Posted February 10, 2011 Decided to do a quick comparison of AFP vs SMB in 5b4 Have a 120GB SATA drive as Cache in my server connected to MB. Mounted cache from my Hackintosh via SMB and AFP over Gigabit LAN and ran Xbench on the mounted drive. Results below Interestingly, AFP is significantly faster in 256K block sequential reads with SMB better in 4K block sequential writes. Everything else is pretty similar with a sligth edge to AFP across the board. Peter Link to comment
Stokkes Posted February 10, 2011 Share Posted February 10, 2011 I think this should be moved to AFP under the 5.0 boards.. I've noticed some good speeds as well (will run some tests this weekend when I get some extra time). One thing I did notice with AFP is that bringing up the share list when clicking on the server in the Finder takes significantly longer using AFP than with SMB. Choosing the "<name>-SMB" from the Finder shows the list almost instantly while choosing just the "<name>" results in a spinning cursor for about 20-30 seconds. Link to comment
meep Posted February 11, 2011 Author Share Posted February 11, 2011 Stokkes, I'm not seeing such a delay. I have 4 shares under AFP and 9 entities appear under SMB. There might be a slightly longer delay bringing up the AFP shares but only a second or two, not the 20-30 you note. Link to comment
Giraffeninja Posted February 27, 2011 Share Posted February 27, 2011 I see the same thing Stokkes. Connecting to the server using SMB populates the shares almost immediately, however connecting to the bonjour afp share takes 20-30 sec to populate the share list. I am running the cache script as well, it appears that script has no bearing on AFP as I can hear each drive spin up as it is waiting to populate the shares. Below are my results using Xbench: I have done some real world testing as well Test Setup: i3 iMac (10.6.6) -> 20 foot Ethernet -> Netgear Gigabit Switch -> 10 foot ethernet -> UnRaid 5b4 (i3 on Gigabyte H57M-USB3) Cache Samsung HD502HJ (7200rpm) all other drives Samsung HD154UI (5400rpm) 3 MKV files (10.81GB total) Here are the speeds I am getting: SMB No Cache SMB Cache AFP No Cache AFP Cache *All Data Disks and Parity are Samsung HD154UI (5400 rpm) Link to comment
Chris Pollard Posted March 8, 2011 Share Posted March 8, 2011 I guess AFP doesn't play nice with cache_dirs then. Link to comment
prostuff1 Posted March 8, 2011 Share Posted March 8, 2011 It is probably more a reflection of the way AFP works. I don't know the exact workings of AFP but I can only surmise that it is something along those lines. Link to comment
speedkills Posted March 8, 2011 Share Posted March 8, 2011 That's interesting. I wonder if AFP is requesting a file property that cache_dirs does not cache, and if so if it can be modified to cache that property? Between the improved speed and improved time machine support I would love to start using AFP once 5.0 is out of beta but having my disks spin up every time my media server scanned for updates might be enough to prevent me from taking advantage of the AFP support. Link to comment
btlupin Posted April 1, 2011 Share Posted April 1, 2011 My experience is the same as Stokkes - bringing up the shares list takes a long time using afp. I don't use cache_dirs. I have gone back to using just smb due to the long delay. Link to comment
Joe L. Posted April 1, 2011 Share Posted April 1, 2011 That's interesting. I wonder if AFP is requesting a file property that cache_dirs does not cache, and if so if it can be modified to cache that property? Between the improved speed and improved time machine support I would love to start using AFP once 5.0 is out of beta but having my disks spin up every time my media server scanned for updates might be enough to prevent me from taking advantage of the AFP support. It is probably reading files it puts in the directories. (all those with a leading "_" character it seems to litter the disks with) If you are curious, you can install the "inotify tools" package from within unMENU. Then, you can type: inotifywait -mr /mnt/user to see exactly what is being accessed. If it is specific files, then perhaps a change in the cache_dirs program can read them too so the disks do not need to be spun up. If you do not have unMENU installed, you can download the package from http://www.slackware.org.il/slackware/slackware-12.2/slackware/a/inotify-tools-3.13-i486-1.tgz move it to your flash drive. (do not un-compress it) install it with the following command: installlpkg /boot/inotify-tools-3.13-i486-1.tgz (assuming you moved it to the root directory of your flash drive, otherwise, modify the path to the .tgz file as needed) Joe L. Link to comment
speedkills Posted April 1, 2011 Share Posted April 1, 2011 It is probably reading files it puts in the directories. (all those with a leading "_" character it seems to litter the disks with) Seems unlikely but if someone else wants to test and confirm my results it can't hurt. I have OSX set to not create those files on my shares (which saves me having to run the cleanup script) and AFP is still far slower to initially browse for me, but once it pops up the intial finder window it browses quickly. My first two thoughts are that OSX probably wouldn't look for files it is set to not create, and second, if it was looking for those files (which it puts in every directory AFAIK) then it would be slow to browse every directory, but for me it's only the first directory that is slow to browse. Subsequent directories browse as quickly as SMB. Link to comment
smoldersonline Posted April 8, 2011 Share Posted April 8, 2011 One thing I did notice with AFP is that bringing up the share list when clicking on the server in the Finder takes significantly longer using AFP than with SMB. Choosing the "<name>-SMB" from the Finder shows the list almost instantly while choosing just the "<name>" results in a spinning cursor for about 20-30 seconds. I see the same behavior. I would hate to give up using AFP. Any chance on a fix for this? Link to comment
angang Posted April 13, 2011 Share Posted April 13, 2011 Same problem here... AFP is hardly usable... Also in 5b6 Link to comment
speeding_ant Posted April 13, 2011 Share Posted April 13, 2011 Funny - I'm not seeing this issue. I've got 6 shares across 5 drives, all appear without issue. There is a longer delay, but only a couple of seconds. Link to comment
Chris Pollard Posted April 14, 2011 Share Posted April 14, 2011 hmm, not encouraging. SMB isn't that responsive on my box, especially on the large directories which contain probably 1500 sub-directories. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.