Kieran Steele
Forum Replies Created
-
Boris,
I get the same results as you with aja, 10.9.4. First run after a boot ;again with cache off; real speeds, each test after that, some sort of super fast cache speeds. I too switched to black magic disk test when I encountered that issue. I’m not sure if my tcp tuning as above is having an effect. What was your before and after figures, and did you notice increased speed on 1gbe as well as 10gbe (presume not), and AFP as well as smb, or only smb. I presume it’s system wide and across all nics no matter how they are connected.
-
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?
-
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.
-
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