Promise SanLink2

[Chris Duffy]

Try building/changing the file called
/etc/sysctl.conf
Put the following lines it in and reboot….
then re-test:

net.inet.tcp.doautorcvbuf=0
net.inet.tcp.doautosndbuf=0
kern.ipc.maxsockbuf=8388608
net.inet.tcp.sendspace=4194304
net.inet.tcp.recvspace=4194304
net.inet.tcp.maxseg_unacked=32
net.inet.tcp.delayed_ack=2
net.inet.tcp.win_scale_factor=7

Use an editor like “vi” or textedit to build it….
you have to be admin/root to do it.

[Luc Vleugels]

Thanks Chris, I created /etc/sysctl.conf, but still no luck…

[Chris Duffy]

🙂
Easier and faster if I can just screen-share with you on your mac to
help……. let me know…. we use teamviewer for screen-sharing but
you may have another program you use?

[Luc Vleugels]

That would be great Chris. Teamviewer is up. How can I contact you?

[Kieran Steele]

I’m also running 10.9.4 with a 10gbe sanlink 2, and can confirm you still cannot set the MTU above 1500. Good to know it sounds like a fix might be on the way.

Awesome to hear the drivers are produced by small tree! I’ve been using their 10gbe cards on the mac pro I’m replacing, and not only have they been rock solid, but updated every time apple does, and it seems apple is often poking things in there.

I am getting fantastic write speeds to my qnap 1279 on this new mac pro 6,1. . Around 390MB/s measured with aja with the same settings as those on this thread, but my read speeds are behaving very strangely. Write goes up to around top speed straight away, read starts at nothing, takes about 5-10 seconds to build up to 230 slowly, then drops down, 190, 160, then back up to 200. Seems to really stutter for fractions of seconds as well.

I was running 1.3.12 driver from promise, now 1.3.14. (there is no uninstall, so I guess it just goes fine over the top)? Seems to be no release notes I can find other than click install.

I’ve tried the tcp tweaks here. I also still have the existing mac pro running 10.7.4 and a small tree card going to the same nas. There is no switch, they are going straight to the two ports on the qnap. Swapping cables made no difference (have two runs). The existing mac pro is running 350 write, 278 read, but its consistent and from the get go.

I cannot try the sanlink2 on the old mac pro, as they don’t have tb.

Anyone think of anything else I can try? I’m not so worried about a minor speed drop on read when its running at full speed (though on some times I test and it stays around 80), but more the stuttering and consistency.

The only other thing I can think of is that between 10.7.4 and 10.9.4 there may have been plenty of tweaks to AFP which I’m using (and either the processor speed of the new mac pro, or improvements to afp have boosted the write speed), but I wouldn’t think they would have severely broken read. Seems much more like a driver issue, but then here I can see people are getting good results, so doesn’t seem universal issue with the driver.

I suppose I could upgrade the old mac pro to 10.9.4 to see if its the os that broke read stability, but then again its using a small tree card and different driver, so not a good comparison.

I’ve just tried the sanlink 2 on a mbpr 15 on 10.9.2 using 1.3.14 and I got 480-500 write, 380-450 read.

So I’m thinking either apple pooched afp between 10.9.2 and 10.9.4, or the promise/smalltree driver got fixed with no release notes from promise between 1.3.12 and 1.3.14 but having no uninstaller, maybe it did not go on well over the top. How can I make sure the new driver is being used?

Ill now take the mbpr15 to 10.9.3 then 10.9.4 and retest in meantime. Won’t fix the mac pro though. If it is an osx issue, I’ll have to get full 10.9.2 from somewhere and do a complete rebuild (i have a backup at 10.9.4 minus 40 apps I just installed, but that won’t help), I recall 10.9.3 broke adobe and d700 gpu combo. If its the smalltree/promise driver though needing updating again after apple pooched something, I can probably wait.

Kieran

[Kieran Steele]

Ah. new here. Thought my reply in the middle would somehow reference that post. So my new post is halfway up. Not sure if I should delete and repost here.

Anyway, just tried with 10.9.4 on an mbpr15 that worked fine on 10.9.2.

Same issue, slow to build to full speed, unreliable/jumpy read using the current smalltree/promise sanlink2 driver. I also went from 10.9.2 to 10.9.3 on the way through and tested. Did not happen with 10.9.3. But since that has the adobe d700 gpu bug, I’ll have to go back to 10.9.2 unless I know its likely to be addressed in the next small tree firmware since apple probably changed something again.

Still open to other theories/suggestions, or if anyone else is proper consistent reads above say 300MB/s using sanlink2 on 10.9.4. Otherwise might be another one to watch out for.

[Steve Modica]

I’m also running 10.9.4 with a 10gbe sanlink 2, and can confirm you still cannot set the MTU above 1500. Good to know it sounds like a fix might be on the way.

The bug is only in the GUI. You can set the MTU to 9000. It’s just that in Mavericks, the GUI won’t show 9000 as an option (or accept it) when a 10Gb media type is selected. In the “speed” section under “Hardware” just pick Auto and it’ll let you set 9000. You can also do it in the terminal with the networksetup command.

Steve Modica
CTO, Small Tree Communications

[Kieran Steele]

Ahhrg. There is no way back to 10.9.2 without time machine. I did not back it up bare shipped before i put all the apps, no data on it, as I figured two point releases should be fine, and I knew I had to skip 10.9.3. All the recovery methods get 10.9.4. Only way is if I could find a bare Mac Pro 6,1 with 10.9.2 on it to clone. Genius Bar and AppleCare said same thing 🙁

So pushing forward, even though 10.9.2/3 worked fine on sanlink2 and 10.9.4 did not. It turns out the device on the other end (qnap) was somehow picky about dealing with Afp exactly on 10.9.4. Upgraded the qnap fw (which I hadn’t for 6 months as they kept breaking things with 4.x). Booyah. Reliable reads again.

Interestingly it now supports and defaults to smb2.0, so I did some side by side with smb1 cifs:// and 2 and AFP. Read speed same with smb1/2. Write speed 10pc faster with smb2, write speed Afp similar. Read speed AFP about double. Wtf!? Not expecting that, that normal?

[Steve Modica]

Small Tree’s been working with the netatalk guys to improve AFP a lot.
There were improvements to the IO performance and some changes to how AFP responds to requests. All of this is in the 3.1.3 code I think.

All these changes are in our TitaniumZ systems, but they are also rolling out into Linux based boxes too.

Steve Modica
CTO, Small Tree Communications

[Boris Tsipenyuk]

Hello all, I just got one of these am testing from a macmini6,2 running 10.9.4 – – AFP and SMB – and what I have seen
the final setup will almost certainly be different in some way (probably the file server piece)

netgear switch
Server: vsphere 5.5 server with a windows 2012 r2 virtual machine (native file share for SMB, ExtremeIP for AFP)
10 gigabit equalogic 6000 san array with 16 x 7200 RPM sata running raid 6 – I will be testing further in raid 50 and with faster drives to make sure that’s not the bottleneck

I’ve been using blackmagic design’s disk benchmark from the app store as well as AJA recommended on this thread (other suggestions welcome)

I wanted to ping this group because what’s clear in my testing is that the sysctl settings are absolute key (as long as being on 10.9 vs. 10.8)
the best results I’ve gotten are as posted by Chris Duffy Earlier in the thread)

sudo sysctl -w net.inet.tcp.doautorcvbuf=0
sudo sysctl -w net.inet.tcp.doautosndbuf=0
sudo sysctl -w ern.ipc.maxsockbuf=8388608
sudo sysctl -w net.inet.tcp.sendspace=4194304
sudo sysctl -w net.inet.tcp.recvspace=4194304
sudo sysctl -w net.inet.tcp.maxseg_unacked=32
sudo sysctl -w net.inet.tcp.delayed_ack=2
sudo sysctl -w net.inet.tcp.win_scale_factor=7

so far I have managed sustained 450 MB/Sec write and about 615 MB/Sec Read using SMB volumes via blackmagic

when using AJA I get even wackier results and generating ton of file write errors in the console log (this is for a 16 gig file test)

8/3/14 4:39:07.754 PM AJA System Test[331]: Disk write error: fd = 7, tried to write 12746752 bytes, stopped at 18446744073709551615
8/3/14 4:39:07.000 PM kernel[0]: smb2_smb_read_write_async: smb_rq_reply failed 22
8/3/14 4:39:07.756 PM AJA System Test[331]: Disk write error: fd = 7, tried to write 12746752 bytes, stopped at 18446744073709551615

8/3/14 4:39:34.668 PM AJA System Test[331]: Average read rate = 682.95
8/3/14 4:39:34.668 PM AJA System Test[331]: Average write rate = 5762.20

for an 8 gig file test:

8/3/14 4:40:40.920 PM AJA System Test[331]: Average read rate = 677.26
8/3/14 4:40:40.920 PM AJA System Test[331]: Average write rate = 5978.89

so obviously something is out of whack (and yes system buffers are disabled on aja)

and finally here are my sweep file results from aja:

128.0 703.1 3467.3
256.0 700.5 2897.4
512.0 681.5 3447.9
1024.0 693.6 3931.2
2048.0 698.0 2926.8
4096.0 671.2 3322.4
8192.0 634.0 5222.6

(and also the same disk write errors on console log)

thanks